irrisor said:
I investigated a bit:
- you can increase the native stack size (e.g. -Xss1M and remember to spawn a new thread), then it works, but performance is really bad (10 fps here)
ahh, i forgot about the new thread thing ..
ahh, i forgot about the new thread thing ..
I somehow found an hour for jME Physics coding (yay :D) and implemented those collision groups. Please test if this breaks anything… it at least speeds up your testcase a lot, hobstad 
edit: uh, have some probs committing - stay tuned
ok, commit succeeded
well hobstad's example works now fine… but
my stress-test app with a lot of dynamic boxes has a bit poorer performance.
Before the change, i could build a wall with 150 boxes (with -Xss1024) without too much problems.
When i try it now, it builds the wall fine, but then performance decreases very fast and after a few seconds i get only 1 fps.
Performance gets better when the wall has collapsed. (less collisions i guess)
Dynamic-dynamic collisions were computed twice - that should have been the problem. Please check if the problem persists, Core-Dump. If yes, can you post a testcase?
yup, performance is much better now, about same as before as far as i can tell.
what i noticed is that between the head revision and the tag v2_1_0rc1 the mass is computed differently.
Rubber Sphere size 0.2 has a computed mass of 1.256 in the old version and 0.0335 in the head version.
But thats probably completely unrelated to this thread i guess
There was a bug with mass computation, which should be fixed now, yes. And it's also true, that this does not belong here
darkfrog said:
Core-Dump or hobstad...my original question was to see if by increasing the stack size to any level if it would run? Can you test and validate this on your machine and output what you had to put in before it would work? It may be a reasonable increase, or it may be something that will happen no matter what you set the stack size to.
Setting the native stack to 384 KB (-Xss384k) solved this. With 256k the problem occurs. I don't feel easy with the native stack so won't say anything about this result whether it's much or not :evil:
In the meantime my "framework that create nodes as you approach their theorical position" seems to work, but it needs cleaning, etc before being broadcast :p
wow oops didn't see the second page as I replied
Ok nice just updated from CVS, the problem is solved and the framerate is much better - thanks for that!
Question please,
irrisor said:
(...) if collision groups (islands) are large (...)
What are these groups? The fact of juxtaposing many separate physics node like in this example, or it can apply to a large, very large one single element as well ("island" makes me wonder) ?
Thanks again...
With "large island" I was referring to a high number of separate physics objects which are all (at least indirectly) connected via joints or contacts. Single large elements (geoms) are not a problem. Though it does not matter if you put many object into a single static node or create separate nodes for them, as on ODE side all geoms are separate objects anyway.