Limitations

I've recently been experimenting with jme physics to see if it is fit for my purposes. it's an impressive piece of work and i very much like its design. however, currently i can only seem to get 50 dynamic nodes (spheres) and 1 static node (randomly generated terrain) before the whole thing just crashes due to stack size, despite all the spheres being really quite far apart.



this was a bit disheartening. i am probably just overestimating the abilities of physics engines in general, but is 50 spheres really all they can handle? this really doesn't seem like a not, especially as sphere collisions are relatively simple, and i wouldn't really expect any "bound" as such. this makes me think its a problem at my end in some way, but i can't think what?



two further questions:



is there anyway to predict when i'm about to surpass the limit of objects. it'd be nice to be able to avoid the crash in a clean way.



secondly, i was thinking about having multiple physics spaces and using an agglomerative clustering method on the dynamic nodes in order to sensibly assign them to smaller spaces. would this improve performance in any way? i'm guessing not because surely the ode implementation already takes into account raw distance before doing collisions etc.



many thanks for any help

50+ sphere should be fine. You get in trouble when you need hundreds, though. What could be the problem in your case is, that a single sphere generates many contact points with your trimesh. Try using a physical trimesh with a lower poly count.


iae said:

is there anyway to predict when i'm about to surpass the limit of objects. it'd be nice to be able to avoid the crash in a clean way.

Unfortunately I could not find such a method yet, no. But you can increase the stack size to some megs to avoid the crashes, as the performance gets very bad for high contact counts as well, you need to minimze contact count anyways.

Multiple ODE spaces are supported via PhysicsGroups in a single PhysicsSpace. But you cannot nest them yet. And, like yourself, I suspect it would not increase performance to use them for spatial separation.
irrisor said:

50+ sphere should be fine. You get in trouble when you need hundreds, though. What could be the problem in your case is, that a single sphere generates many contact points with your trimesh. Try using a physical trimesh with a lower poly count.

iae said:

is there anyway to predict when i'm about to surpass the limit of objects. it'd be nice to be able to avoid the crash in a clean way.

Unfortunately I could not find such a method yet, no. But you can increase the stack size to some megs to avoid the crashes, as the performance gets very bad for high contact counts as well, you need to minimze contact count anyways.

Multiple ODE spaces are supported via PhysicsGroups in a single PhysicsSpace. But you cannot nest them yet. And, like yourself, I suspect it would not increase performance to use them for spatial separation.


i had tried changing the stack size but i've just realised i need to get everything going in a new thread, which will explain why i didn't notice any difference.

another quick but mostly unrelated question about generatePhysicsGeometry.

The wiki states:

"The generatePhysicsGeometry method simply draws a PhysicsBox (or alternative) around the node it's called against. But what if you want to generate physics geometry for every singe triangle? For example your terrain, it isn't enough to simply draw a PhysicsBox around it. You'll have to pass an argument to generatePhysicsGeometry"

However, I just realised I called it for my terrain without supplying the boolean true value as a parameter, and yet it has still generated the geometry for every single triangle. Is this correct? If so, when would I expect to have to use generatePhysicsGeometry(true)

Thanks!
iae said:

The wiki states:

"The generatePhysicsGeometry method simply draws a PhysicsBox (or alternative) around the node it's called against. But what if you want to generate physics geometry for every singe triangle? For example your terrain, it isn't enough to simply draw a PhysicsBox around it. You'll have to pass an argument to generatePhysicsGeometry"

uh, at least without the context from the wiki this sounds quite wrong... generatePhysicsGeometry decides about the physical geometry it generates with respect to the visual type of geom. If you think this is generally unclear in the wiki, please correct it. iirc, for a TerrainPage or TerrainBlock it uses triangle accuracy all the time.

OK, that's what i thought. I'll make the wiki a bit clearer. It was in the tutorials.