However when I see any other - or make any physics in HAVOC - even the official documentation, I see physics objects that are not interpolated in the render:
It creates jerky movement when rigidbodies moves fast.
Having worked many years with various engines, my eyes tells me that “hey, these rigidbodies are not set to interpolate”… Hints to interpolate, anyone? Thanks
There is no interpolation with physics.
I tried to repro the jitter in FF but I didn’t see anything particular.
Can you record this jitter?
In the PG, the size of the world and forces are set to show the PhysicsHelper. In the demo, they are set for fast action in a small world. So, in the PG, it may look like action is happening on the moon, not in the demo.
I’m sorry for answering late, but this keeps popping up.
Physics runs at it’s own speed, frames runs at their own speed. Frames are not steady, physics tick is.
That’s why you need interpolation: if you just show what the physics engine spit out on every frame, you get jerky motion.
What good is 100’s of FPS, if for example 3 frames shows the same position, then the next frame there’s movement? This is why one needs interpolation, and that’s how it is done in all modern game engines. (before the extra step of motion blur)
If you have a setup of 2 monitors to ensure your computer has something to do, then run this:
you will notice that the ball is not dropping silky smooth, despite possibly hundreds of FPS.
Yes, I can, and have recorded it, but the argument would just be “that’s because of the video capture” as it will often get extremely jerky on capture due to even more FPS variants injected…
It’s really not a matter of showing but knowing that Physics need to be inter- or extrapolated (or extremely over sampled which is a poor solution) to be represented smoothly. And Babylon.js w Havok has no way of doing this?
Correct me if I’m wrong @Evgeni_Popov and @sebavan but I think physics update is done for every rendered frame. So, if the physics update is using fixed delta time then physics will appear to run faster on fast refresh screens. If it’s using delta time update, then there is no limit in physics update.
Yes, the Scene.animate method is called each time Scene.render is called, and this is the method responsible to advance the animations / the physics engine:
I’m still new to Babylon, am more an artist than programmer, and I still cannot get the smooth physics animations / across varying FPS that I can get in other engines using out of the box “Interpolate” functions on rigidbodies.
Are you guys saying that I’m wrong or that’s how it is, or trying to tell me something I don’t get on how to achieve smooth physics in Babylon?
I’m not noticing the “unsmooth” behavior either in the PG.
In my understanding (I’m no expert at Physics!), reading the code I linked to:
by default, physics (and regular animations) run at the same rate than the rendering, so there’s no need for interpolation
if you enable deterministic lockstep (through an option parameter when creating the engine), physics (and regular animations) may run at a lower rate than the rendering. For eg, physics could be updated only every two frames.
In the second case, there won’t be any interpolation between the physics objects in the frames in-between. I think this is the point from @Frits_Lyneborg and I don’t think it’s on our current plans to implement it? cc @Cedric and @carolhmj.
It’s not specific to Havok, though, it should be the same thing whatever the physics engine you choose, as it is not related to the physics engine itself.
When running physics in fixed timesteps and rendering in variable timesteps, you will indeed experience a bit of stuttering, especially with fast movement and small objects. So if you initiate Havok with, let’s say, a 16ms fixed delta between steps, you’ll need to interpolate between the previous and current state of the body, taking the remaining time in the accumulator into account. At least that’s what I do
I’ve added a substep mecanism for Ammo (and Cannon I think) to have fixed time substeps. This is particularly needed for accuracy when framerate is low. For example, it allows to compute physics at 60Hz while having rendering framerate at 20Hz, so each rendering frame, physics will be ticked 3 times.
The accuracy issue was notable because of fast objects not blocked by thin walls for example. This said, if your framerate varies a lot, physics with a delta time will not be smooth. But it should be the same for everything animated in the scene. Even camera rotation.
Now, to be able to improve that, we’ll need a PG to evaluate, fix and compare animation.
Is it possible @Frits_Lyneborg to create a PG that shows clearly (something exagerated would be perfect) the non smooth physics? ideally compared with a simple animated box or a procedural animation.
I’m not sure on how to fix the issue without a PG.
That’s where the issue is then: Not seeing it I do not mean to be rude, but I have experienced this: showing jitter to people and they cannot see it.
And when this base premise is not there, it’s only getting so much harder to talk physics abstraction layers, which is why I’d rather try and work around that.
Argh, I’m unable to provide better documentation. ALl I can say is that I have colleagues who also run this who all shout “There” at the same time when they see what’s almost resembling as tearing, it’s unsteady motion. If you cannot see it, it’s of course possible that it’s not sowing on your system, but unfortunately games needs to run other computers, again sorry if I sound rude
And this is as simple as I can get the examples at this point in time, even without introducing physics…
