How does the magic work (regarding time step)

Hi

I'm using NxOgre without frame listeners as per the Practical Application in the wiki, so I'm doing a custom game loop instead. I noticed there isn't a need to to update the time step, unlike OgreODE i.e, we don't call PhysX::NxScene::simulate in the game loop.

Looking at NxOgre sources, it seems to using frame listeners to call simulate function. Would that be a good design? How would I be able to control the physics timestep if I needed to?

Yep it uses it's own FrameListener.

In older NxOgre versions you could make it not use a FrameListener but in later ones (for some reason which I forgot) you no longer can't. If you want to, it's just commenting out the adding and removing frameListener lines in world.

But I can't see much of a point really, unless you want to control the simulation state or not, but that is handled via mWorld->pause and mWorld->resume.


p.s. Nice nickname, is your first name Robin by any chance?

What isfsomeone wanted to decouple the NxOgre and Ogre update rates? I know there no support for this now, but the basic version would involve placing a thread safe message queue in between Ogre and NxOgre, and calling step whenever you want. In a single threaded game you might also want to update the physics at a higher rate than graphics to maintain the stability of the simulation.

Technically you can now; if you don't "autostart" the World, and call the simulate function by hand.

However;

a) Some variables are null'ed or set to zero in world::start(), not making setting them up will make somethings act bizzare but it won't impact onto the PhysX simulation though.

b) I can't see calling extra time into the simulate function per second will do anything to PhysX, it has a very good integrator to handle small/average timesteps to the quite large. Calling such small time steps may even have a negative effect on it all.

Yes, my first name is Robin. Pleased to meet you, how did you figure that out?

I see the need to decouple physics update in network game, especially if the game update is done in lockstep.

Yes, my first name is Robin. Pleased to meet you, how did you figure that out?


Because it's mine too, and there aren't many of us around

I see the need to decouple physics update in network game, especially if the game update is done in lockstep.

I haven't tried PhysX out in a network simulation, but it should work. Just make the changes above and see how it goes.

Because it's mine too, and there aren't many of us around

That's a little creepy, and a little magical

I remember reading on Ageia website an article about using fixed time step and of course this

http://www.gaffer.org/game-physics/fix-your-timestep/

I request that you put ability to specify time step feature back, though I can't see why you chose to remove it

Way ahead of you, I've been experimenting with slow-motion so I changed world to allow me to do this.

So far, I've written:

mWorld->simulate(deltaTime, updateOgre)

Allowing you to simulate x seconds of time. The updateOgre flags allows you to turn on/off for that simulation communication with the Ogre Scene, allowing you to work in separate threads, and only moving the nodes when it is the correct time to do so:

What I will add is:

Extending the scene blueprints; To allow fix time steps of n iterations a second.

Very handy for FXScene when they can run say at 30, and the main scene runs like a bat out of hell

All right! Great to hear that!

There you go, and it doesn't need a blueprint.

Slow-mo:
mScene->setTiming(scene::FIXED, 0.00001f, 8);


Manually advancing the simulation
mWorld = new world(mRoot, false);
...
mWorld->simulate(1.0f / 60.0f, true);