June 17, 2018 at 8:55 pm #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…June 17, 2018 at 11:27 pm #14858
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?June 18, 2018 at 12:02 am #14859
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:
Monkey1234New Timer( 120,Lambda()_scene.Update()End )
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.June 18, 2018 at 7:14 am #14862
Thanks, Mark, will mess about with this later and see what happens!June 18, 2018 at 7:52 am #14863
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.June 18, 2018 at 12:21 pm #14865
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.June 19, 2018 at 9:40 pm #14874
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!]June 19, 2018 at 10:08 pm #14875
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…June 19, 2018 at 10:19 pm #14876
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).June 19, 2018 at 10:45 pm #14877
Monkey1ground.Visible = False
… 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… ]June 19, 2018 at 10:49 pm #14878
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…June 21, 2018 at 4:46 am #14883
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”!June 21, 2018 at 11:07 am #14886
Updated source in link above — stupid tab mixup with old import meant uploaded version was uncontrollably fast!June 21, 2018 at 2:55 pm #14887
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!June 21, 2018 at 3:42 pm #14888
Updated source to new physics-controlled no-collision-response gems…
You must be logged in to reply to this topic.