I didn't find any thread dealing with this exact question so here it is:
I managed to create multiple PhysicsSpaces inside the same World, not a problem. I just avoided creating a new World in every ODEPhysicsSpace instantiation. Worked… Fine… But here is the real deal:
In ODE is possible to disable collisions INSIDE the space but enable collisions between objects of different spaces (in the same world). And that didn't work with JMEPhysics2. That's useful to make a model, say of a car, and avoiding it's parts colliding with each other (like the wheels of a sports car very close to the car body). That's exactely what an ODE example does: Each car goes in it's own PhysicsSpace, with disabled collisions, but colliding with objects from the others spaces, like other cars or terrain. Dunno if collision groups (any chance of being implemented?) can do the same.
In my example, each space was updated and the simulation went fine, but the collisions between spaces were not tested (or solved), only inside each space.
Is there a way of doing this? Enabling collisions between spaces and disabling inside collisions? I checked ODEPhysicsSpace.java, ODEJava.java and didn't find any way of doing it.
Thanks in advance
A physics space in jME Physics 2 conceptually matches a world in ODE. It is not planned to change that. The idea is to introduce collision groups instead to match the concept of spaces in ODE. These are not yet implemented.
Besides the work on the Java side there is some work to do on the native side: Currently the dSpaceCollide2 method in ODEJava is near to nonsense. I'm currently trying to fix this, to be able to do picking with the physics geometries. The Java part (introduce collision groups) on the other hand is not on my todo list currently.
irrisor said:
he Java part (introduce collision groups) on the other hand is not on my todo list currently.
ah but that would be nice.
that way for example a spaceship could fire physics projectiles and the projectile wouldn't collide with the ship itself. (one of my problems right now :) )
@core-dump: You can do that already with the contact callback. But the spaces would optimize the performance for some things.
ah thanks, i will try it with those callbacks.
Thanks for the explanations Irrisor.
I'm currently happy with the way things are because my current car models don't suffer from that issue yet (wheels very close to the body). I'll keep my eye on any improvements made on JMEPhysics2.
do you happen to have a small example on how to use the contactCallbacks?
i'll happily write a wiki entry or even test once i know how to handle them.
i couldnt find much infos in the tests or forum.
Simply call
physicsSpace.getContactCallbacks().add( myCallBack );
where myCallBack is an object implementing ContactCallback and thus the method adjustContact( PendingContact contact ). In that method you can inspect the contact info (e.g. check if it's the bullet hitting the owner) and call contact.setIgnored( true ) on it in case (or whatever you want to adjust of the other contact stuff).
edit: removed 0 parameter
Works great, although its add(cb) not add(0, cb), because the callbacks are iterated from last to first.
I made a Wiki entry for ContactCallbacks, and updated PhysicsSpace.
Sorry for spelling oder grammar errors, my english is not very solid 
glad it works for you, and sorry for the wrong index
I'll have a look at the wiki later, thanks for contributing
fyi: I've added collision groups to the api now
That's nice to hear…
Is there an example?
And a comment would be nice.
Sorry that feature was implemented in a hurry (only had about an hour coding time). Currently it's used for improved performance with many static object only. Where do you meant a proper comment is missing?
Can someone help out with an example, who already knows what ODE's spaces are good for?
I'd suggest someone to get the AdvancedVehicle test and convert the car implementation to a PhysicsSpace, disbling collisions between the nodes of one individual space (one instance of a car). I can't do it right now because I'm very busy with my PhD and data driven game engine these days.
That's a good idea… uh, it would require nested groups, though - that's not supported yet 