Crossing zones.

Feel free to slug me with a cluebat if I missed something obvious.

I am planning to integrate PCZSM into my project shortly and I'm trying to figure out how to manage Bullet in that situation. Do you set up a dynamics world per zone and hand off the objects as they cross from one to the other? How would you do that and preserve momentum, etc.?

I also plan to add a paging terrain system. That has a related issue. To avoid precision errors, it has been recommended to me to make the origin float where it will periodically jump to stay within range of the player avatar. The difference here is that I am assuming that the dynamics world will be the same. Would it be better to create a new world and perform a hand-off like above?

Thanks.

I use Bullet in my app which heavily uses the PCZSM. Currently, I use one dynamics world for everything. It works fine for my needs. When I first integrated bullet, I wanted to have separate simulation zones for each pczone, but bullet did not support that at the time. It seems that with the new multisap, bullet does support it, but I have not tried integrating that particular feature in my app. I may try to do it at some future point though.

Chaster

Mmph... of course all zones in the world will occupy world relative coordinates so a physics sim per PCZSM zone is silly. It is rather much simpler to define large physics cells that manage active physics objects that are local to it.

I haven't quite wrapped my head around "multisap" yet, but it does seem intended for dealing with streamed terrains. I'm not entirely sure it can deal with what I have in mind though. The discussions on it on the Bullet forum suggest techniques that I can use to code up the intercell hand-off if necessary.

Mmph... of course all zones in the world will occupy world relative coordinates so a physics sim per PCZSM zone is silly. It is rather much simpler to define large physics cells that manage active physics objects that are local to it.


Well, the reason *I* wanted to use separate zones of simulation was to improve efficiency (eliminate collision checks between RB's which are in completely different areas). PCZones are an ideal candidate for doing this kind of high level sorting. It would *significantly* improve efficiency during the collision detection step - which is the most expensive step of any physics simulator.

Chaster

Well, the reason *I* wanted to use separate zones of simulation was to improve efficiency (eliminate collision checks between RB's which are in completely different areas). PCZones are an ideal candidate for doing this kind of high level sorting. It would *significantly* improve efficiency during the collision detection step - which is the most expensive step of any physics simulator.
Oh good point.

A bit of a strawman design so it could be silly, feel free to poke holes. Assuming that PCZSM sends a Zone visible/not visible event you consult whatever method you have to get all the entities owned by that Zone and put them to sleep or wake them up based on which event was received.

Sorry for the lapse in response. I'm pretty busy nowadays so I'm not too good about scanning the various forums for topics related to me...

I don't think you would want to put objects to sleep just because they're not visible. Things can still be moving even if they're out of sight..

Chaster

Sorry for the lapse in response. I'm pretty busy nowadays ...
no worries, I saw that.

Assuming that PCZSM sends a Zone visible/not visible event you consult whatever method you have to get all the entities owned by that Zone and put them to sleep or wake them up based on which event was received.
well that's just non-sensical. I wonder what I actually meant. Maybe when I get a chance to sit down with my code again I'll remember