Help CPU time-slice rope rendering/physics?

[TheMunk]

I'm constantly trying to optimize the 500-800 particle ropes in my experience on Oculus Quest. I've tried most of the suggestions regarding unity time steps, sub steps, etc.

Reading this https://thegamedev.guru/unity-performanc...g-secrets/, I was wondering if it would be possible to slice the simulation of my ropes in half by updating (both physics and mesh) at half the frame rate. Many of my ropes do not interact with each other so it wouldn't be a problem if they where updated on different frames. 

Is this even possible with Obi? How could i implement this? 
Can I just set up multiple solvers (one for each group of ropes) and enable/disable them for every other frame or will there be startup/cleanup tasks taking up performance?

[josemendez]

I'm constantly trying to optimize the 500-800 particle ropes in my experience on Oculus Quest. I've tried most of the suggestions regarding unity time steps, sub steps, etc.

Reading this https://thegamedev.guru/unity-performanc...g-secrets/, I was wondering if it would be possible to slice the simulation of my ropes in half by updating (both physics and mesh) at half the frame rate. Many of my ropes do not interact with each other so it wouldn't be a problem if they where updated on different frames. 

Is this even possible with Obi? How could i implement this? 
Can I just set up multiple solvers (one for each group of ropes) and enable/disable them for every other frame or will there be startup/cleanup tasks taking up performance?

Hi there,

I think you don't understand the concept of fixed timestepping: physics are entirely decoupled from the framerate, that's the whole point of having a separate physics update cycle!. Physics are 'sliced' by design. In fact, the same article you reference mentions this:

"But this is the key I realized back at that point: rendering at 72 FPS doesn't mean you must execute everything at 72 FPS. In fact, physics already execute at a different pace."

Most engines (Obi being no exception) even include a interpolation mechanism to achieve smooth transitions between physics states, during frames where the physics engine hasn't been updated. Simply updating the state some frames (enabling/disabling the engine every other frame) and reusing the same state until the next physics update would make the simulation to look like it is happening in "stop-motion", causing stuttering.

So the answer for your question would be: increase your fixed timestep. This will cause the physics engine to update less often. As result, the simulation will be lower-quality, though.

Note: rendering can't be sliced, because even if physics weren't updated during a frame, you still need to draw something to the screen.

[TheMunk]

Hi there,

I think you don't understand the concept of fixed timestepping: physics are entirely decoupled from the framerate, that's the whole point of having a separate physics update cycle!. Physics are 'sliced' by design. In fact, the same article you reference mentions this:

"But this is the key I realized back at that point: rendering at 72 FPS doesn't mean you must execute everything at 72 FPS. In fact, physics already execute at a different pace."

Most engines (Obi being no exception) even include a interpolation mechanism to achieve smooth transitions between physics states, during frames where the physics engine hasn't been updated. Simply updating the state some frames (enabling/disabling the engine every other frame) and reusing the same state until the next physics update would make the simulation to look like it is happening in "stop-motion", causing stuttering.

So the answer for your question would be: increase your fixed timestep. This will cause the physics engine to update less often. As result, the simulation will be lower-quality, though.

Note: rendering can't be sliced, because even if physics weren't updated during a frame, you still need to draw something to the screen.

Alright thanks - i surely have a lot to learn and understand regarding physics!