search

Schroedingers-Hat / jsphys

Libraries for physics simulation on javascript canvas
GNU Affero General Public License v3.0
11 stars 1 forks source link

Massive reduction in computation needed (no change in memory) #36

Closed Schroedingers-Hat closed 12 years ago

Schroedingers-Hat commented 13 years ago

We don't actually need to call updateX0 for anything for which position is a function every frame, no information is lost by not doing this. It's fairly trivial to calculate the centre of mass, and radius of (or even a box containing) an arbitrary number of inertial bodies. We can use this information to decide whether or not we're drawing a cluster (or cluster of clusters, or........) and if not, don't call updateX0, calcPast, or interact with it at all. Additionally we can sort the objects in the cluster by their luminosities, if (r_furthestPoint-r_closestPoint)/r_middle is small enough we work through them until we decide not to draw one then ignore the rest. Calculate stuff in front first in hope of getting a nice large light normalization factor, so then we can ignore most of the red-shifted stuff. This will change our algorithm from N computations to kN where k is the fraction of the universe which is visible, and large enough to make out.

This instantly changes our limiting factor for something about as sparse as a galaxy from CPU to memory, or possibly even the number of objects we can cram down the intartubes to the player. HDD storage of objects becomes a possibility.

If bandwidth becomes a significant limit, procedural generation becomes an option and as such a Minecraft style infinite universe, with a reasonable number of things in it. The only problem I can see with this is that giving people powerful telescopes will not really be an option.

Schroedingers-Hat commented 13 years ago

NB: for 2D we'd need to limit zoom/gamma.

Schroedingers-Hat commented 13 years ago

Not quite N/k, rather N/k+log N, but k will be a function of the density of objects, zoom and number of objects, as such which term is bigger will be variable and sometimes log N will dominate.

Schroedingers-Hat commented 13 years ago

I do believe this will be easier/more effective in 3D than 2D. Who'd a thunk, 3D will be more efficient/less computation. ^_____^ On top of this I think I can use all the cheating methods I described to have a few interesting/close, lit objects, and many, many distant objects. We can cheat and already know which things light it up with because we know it's close if we need to render the 3D mesh. but lighting and non-monotone-splodge can wait (actually with measureDisplacementTo written, lighting won't be too hard).

capnrefsmmat commented 13 years ago

We can use this information to decide whether or not we're drawing a cluster (or cluster of clusters, or........) and if not, don't call updateX0, calcPast, or interact with it at all.

By "cluster," do you mean a closely-packed group of inertial bodies? If so, why would we not want to interact with it?

Schroedingers-Hat commented 13 years ago

Well, if we're not looking at it, we don't care. Not updating it to the present time this frame doesn't make it any harder to update it to the present time next frame. So we know when to start caring we can make an invisible object in the middle which keeps track of how big the cluster is, and where its centre is. Keeping track of this one object will tell us when we have to care about the rest of the cluster.

We can also take into account this size value, as well as position, if it's too small we just draw and update one object which has the combined luminosity rather than however many are in the cluster.

This optimization interacts poorly with interactive things (real gravity, electromag etc), so I shall leave the option to turn it off.

Schroedingers-Hat commented 12 years ago

with isInteresting this is mostly implemented