Runge-Kutta 4 E2 (Gravity Simulator)

[SystemsLock]

I think you're being misleading about how many objects it can account for. Generally speaking it hits the conventional limit on servers at around 6 objects but why would you run physics simulations on a server? I can run about 10 of those chips with "wire_expression2_unlimited 1" before I start to notice the lag. I understand that doesn't meant 60 objects (as the calculations go up exponentially) but it does mean you can account for far more then 6.

[Divran]

I think you're being misleading about how many objects it can account for. Generally speaking it hits the conventional limit on servers at around 6 objects but why would you run physics simulations on a server? I can run about 10 of those chips with "wire_expression2_unlimited 1" before I start to notice the lag. I understand that doesn't meant 60 objects (as the calculations go up exponentially) but it does mean you can account for far more then 6.

than*

What you're saying is, make the user able to spawn multiple chips, and have the chips communicate with wires, or signals and gvars, to control a few objects each and have them interact.

[Fizyk]

Divran: Basically what he's saying is, if you turn off the quota limits, you can get far more out of this E2, still without a noticeable lag.

SystemsLock: Yeah, you're probably right, but if you for example want to show your simulation to someone on a server, you will have to obey the quota limits, and then it's only 6 bodies (though you can have more by increasing Skip, but the simulation is less precise then).

[Divran]

Now that I read it again I don't know what I was thinking. But then the idea I had isn't a bad one

[Pyr]

Yeah Divran, I actually thought of that too for my water simulator. Where the multiple chips communicate so that its similar to having one big processor.
This gravity simulator is great, good job. :3

[Beer]

Instead of making it skip a static amount of ticks between calculations, why not make it do calculations of one body per tick in sequence based on the number of bodies in your system. Seems to be a possibly better, and more dynamic solution. Should allow for more bodies as well.

[Syranide]

Instead of making it skip a static amount of ticks between calculations, why not make it do calculations of one body per tick in sequence based on the number of bodies in your system. Seems to be a possibly better, and more dynamic solution. Should allow for more bodies as well.

Unless he stores the initial state of all bodies and uses that a complete "round", this will probably make the simulation more inaccurate (probably not noticeable, but could add/remove energy from the system which would be very noticeable over time). But the result is the same, he would not be able to perform more calculations at the same "simulation speed"... the ops-cost is already amortized.

[tuusita]

If this was converted to use WireCPU, how many bodies would it be able to handle? :scratches chin in thought:
... not that I'm the one doing the conversion.

Interesting project, I remember toying with something like this using PhysX back when it wasn't yet acquired by nVidia...

[Fizyk]

Instead of making it skip a static amount of ticks between calculations, why not make it do calculations of one body per tick in sequence based on the number of bodies in your system. Seems to be a possibly better, and more dynamic solution. Should allow for more bodies as well.

Like Syranide said, I can't simulate this body-by-body without precission loss. Every step needs to be performed on all bodies at once to achieve best results.

If this was converted to use WireCPU, how many bodies would it be able to handle?

I don't think it would be more. E2 is way more efficient than CPU in doing arithmetic calculations, and that's what this simulation is all about. The CPU is meant more for things like computers, where you don't need to go through the whole code as fast as possible, but just have a continuous execution flow.