Update rates (App, Scene, Physics, etc)

About Monkey 2 Forums Monkey 2 Programming Help Update rates (App, Scene, Physics, etc)

This topic contains 14 replies, has 2 voices, and was last updated by  DruggedBunny 3 weeks, 5 days ago.

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
  • #14856


    How do update rates work in mojo3d?

    I’ve just done a quick VR hack of Bust! but movement is quite slow, whereas it’s ‘normal’ in non-VR.

    I think the VR headset sort of renders at its own rate, is that right, or is it based on Scene.Update? What controls the VR update rate?

    I’m not sure what exactly Scene.UpdateRate controls — is this controlling both the application update rate and the physics rate, or are they independent? (If independent, how do I separately change the physics rate?)

    (Are they separate to the window refresh rate as well?)

    Maybe I’m overthinking and confusing myself as usual, but I can’t figure out how to get physics movement in VR to run at the same rate as non-VR, and I’m not sure what refresh rate the VR is actually rendering at (thinking about the ‘correct’ 90fps it ‘should’ have)…

    I can set Scene.Update rate to a higher value, but that slows the game down overall, whereas lowering it (eg. 30) is surely going to make physics less accurate… and I don’t know what that’s then doing, if anything, to the VR update rate.

    Confused, obviously…


    Mark Sibly

    The Scene.UpdateRate and Scene.MaxSteps properties are only used by bullet when stepping the simulation – they are passed to this function:


    Thre first parameter of stepSimulation is computed by mojo3d and is simply the elapsed time since the last UpdateWorld.

    You should be able to determine HMD refreshrate by DrawText-ing App.FPS and looking at the app window with HMD removed, or even just by Print-ing it.

    On the Vive here, FPS is 90, but I seem to remember hezkore had to set SwapInterval=0 or he was getting 60?


    Mark Sibly

    I just had a quick hack with hingechain by enabling VR and it seems to behave eactly the same as without VR.

    I didn’t play with UpdateRate at all – it defaults to 60, but it’s the elapsed time parameter that really matters here. A quick way to test the effect of different update rates is to remove scene.Update from OnRender and use something like this in your ctor instead:

    This works (with hingechain physics anyway) with every update rate I throw at it until I start using values less than 60, the default UpdateRate. To fix this, I need to either reduce UpdateRate to 30 or increase MaxSubSteps to 2, ie: either use one update at 30hz or 2 at 60.

    What you may be having problems with is the impulse stuff as I think. I believe impulse is ‘instantaneous’ so may have to be scaled by time somehow, will look into it.



    Thanks, Mark, will mess about with this later and see what happens!


    Mark Sibly

    This is the only reference I can find relating to force/impulse:


    The way I read it, ApplyForce does not need to take any sort of duration into account but ApplyImpulse does, ie: impulse=force*time.

    So you’ll need to compensate for frame rate here. Easiest was is probably to scale your impulse ‘force’ by (App.FPS/1000.0) which hopefully means apply X force force for 1 frame. I think I’m sort of starting to get it…

    Another thing to try would be using ApplyForce instead of ApplyImpulse as this may do the time scaling stuff for you. You may have to use ClearForces() if thrust is NOT being held.



    Thanks, Mark, I did finally sort of grasp what you meant by the time aspect, so will experiment with that… it’s hard to tell what aspect of the overall system is going slow, but I think you’re right there.



    I think I need to dig into this a lot deeper… for some reason, the program runs at only 30-40 FPS in VR, yet full 60 in non-VR, as reported via App.FPS.

    However, basic VR test programs do run at 90 FPS, as expected.

    I don’t change the update rate anywhere, as far as I can tell, so something’s slowing it down in VR mode, but disabling various aspects has made no difference (eg. not updating the scene, not updating the player, not updating the HUD, etc, etc).

    Any ideas as to where I ought to be looking?!

    [EDIT: Source with VR and non-VR versions: http://www.hi-toro.com/monkey2/bust/thrusting.7z — could really do with a way to compile-time comment out VR-specific stuff, though, so I only have to work on one version. (eg. #If VR_MODE/#Else etc.) Is there currently a way to do this? I wasn’t able to get anything to work!]


    Mark Sibly

    Have you checked it isn’t just good old fashioned slow down? Don’t forget, you need to draw about twice as much in 2/3 the time…

    I would suggest turning everything off except the spaceship and see if it’s still slow. If not, keep adding stuff back in etc, comparing framerates as you go so you can see what takes how long etc…


    Mark Sibly

    Ok, lights in spacegem seems to be the main cause of slowdown here, if I disable these I can run at 90fps. Will investigate (eventually).



    Ah… doing:

    … immediately puts it to 90 FPS!

    That said, ground is kind of a key feature…

    Even cutting the camera range to 100 still leaves me at 40 FPS…

    Scaling the heightmap to 512 or 256 does get me up to around 60-70 FPS — will need adjusting for scale, as it looks weird — but at least I can see that this is having a significant impact.

    I suppose it’s a lot of vertices after all, 1024 x 1024 being 1.something million!

    [EDIT: Ignore VR/non-VR selection for now, might have just figured it out… ]



    Oh, weird, same here, with terrain back up to 1024 x 1024! I get 90 FPS with no SpaceGem lights.

    Did think they may be a bit much even in non-VR…

    EDIT: Bonus ball — figured out how to toggle VR/non-VR at compile time, so I can now more easily compare the boost scaling, which will be my next job…



    OK, all sorted! ApplyForce/ApplyTorque were the key, as you thought — I read up on force vs impulse at work today, and sort-of realised the difference, since force = mass x acceleration, where acceleration is a change in velocity over time; however, impulse = mass x ‘acceleration’ where ‘acceleration’ is an instant change in velocity, which is impossible in real life*.


    Key learning point: Should have used ApplyForce all along!

    I believe ApplyImpulse would be there to allow for (technically impossible) instant changes in velocity within the physics simulation.

    Anyway, it now runs the same in both non-VR (60 fps) and VR (90 fps) — you can now easily switch between them in superthrust.monkey2, the main file.

    *  I think with impulse, it’s like the usual “acceleration = (end_velocity – start_velocity) / time“, but where time = 0, so would cause a real-world “divide by zero”!

    Users who have liked this topic:

    • avatar


    Updated source in link above — stupid tab mixup with old import meant uploaded version was uncontrollably fast!



    Little feature request:

    Can we have no collision response option built into RigidBody?

    The above works perfectly, but isn’t exactly intuitive…

    I’m converting my SpaceGems to RigidBodies instead of the current (manually-rotated) non-physics entities, obviously don’t want my rocket bouncing off them when colliding, just want to detect the collision.

    I’m using ApplyTorqueImpulse (yup!) on gems when New’d to set their fixed rotation speed (so it’s instantly applied), removing their angular damping and applying inverse gravity to keep them suspended. (All working great so far!)

    EDIT: Spoke too soon — my gems appear in Debug but not Release, so guess they’ve shot off somewhere in Release for some reason! The detection certainly works in Debug…

    EDIT 2: This was due to Scene.Update being needed prior to applying forces — otherwise things don’t appear. Run into this before, didn’t realise it was only in Release mode though! Also, weirdly had to change inverse gravity to half inverse gravity when moving the gem update into SpaceGem from Game.Update. Dunno why, but it works…

    All working great now with no-response collisions!



    Updated source to new physics-controlled no-collision-response gems…


Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic.