i am trying to simulate inertia on an actor without the need of physics.
When the player moves the mouse, the rotation should accelerate smoothly.
When the player stops moving the mouse or releases Q/E, the rotation should gradually slow down instead of stopping immediately.
The effect should feel fluid and natural, like a spaceship in zero gravity.
I attempted using Physics Thrusters, but they are too heavy for performance. Instead, I want to apply a simple math-based approach that uses inertia without actual physics simulation.
Any example Blueprints would be greatly appreciated!
There are many ways to implement the above and more script will be needed to make it a system ofc; but that’s the gist. We provide a desired target, and interpolate every frame to reach it.
This works quite well in principle, but the actor should continue rotating in a certain direction as long as the mouse is moving or the key is held down. It should only gradually slow down once the input is released.
This works quite well in principle, but the actor should continue rotating in a certain direction as long as the mouse is moving or the key is held down. It should only gradually slow down once the input is released.
That’s pretty much how the above works, though. Any additional behaviour will need to be scripted, ofc - holding a key would add to a target (clamped) rotator.
Another way it to simply Add Rotation in the desired direction. There really are numerous way to approach this.
However, if you’re making a spaceship flying game, want to keep it simple and avoid using physics explicitly, consider looking into the Floating Pawn Movement component. It also works well with physics (optional), and understands player movement input.
How did you arrive at this conclusion? Are we talking about 100s / 1000s of those components? Is mobile the target platform?
Note that by using all the extra nodes, you may end up with a solution that is less performant than straight physics implementation… This runs in separate thread on a fixed interval:
The main problem is that the **physics-based approach fluctuates heavily with mouse sensitivity, and the thrusters should not rotate with the object but remain fixed in place. Sometimes it works smoothly, but often it feels very jittery.
I thought that with a non-physics approach, I would have more control.
Again, thank you very much for your detailed response! I’m not a programming expert (as you can probably tell ^^), but in your latest approach, the system immediately switches from one state to another—the “inertia” is not carried over.
For example, if I press the Q key and then move the mouse upward, both inertia effects do not blend together.
Ofc! This has so be scripted. I even left a note on the node about additional interpolation. You would slowly move the value from -1 to 1 and vice versa.
You are trying to mimic what the physics engine is already very capable of, and something that it does exceedingly efficiently. At this point you’re writing the physics engine yourself. Physics is just math after-all. Note that even using built-in physics is often not enough - and it becomes apparent when trying to tackle inertia in 3d space while giving the user some kind of control over it - usually with one or more PIDs.
My advice is to use existing physics for 3d movement in space. Ideally combine it with a floating pawn movement component - it will act a bit like a controller. You can get a sensible result pretty quickly, especially if true physical simulation is not paramount.
I’ve gone as far as researching NASA papers on the matter only to find out that only half of their controls are clever equations, the other half is error-correction math… and a lot of manual user input.
I sense user error. You’d need to provide smoothed values over a fixed timer period. You can often get away by simply multiply it by delta time Tick produces.
I found the solution for the jittery movement: I solved it by lowering the sleep value to 0.5.
I will go with my physics approach. Currently, I keep the thrusters in their position by using Event Tick and Set World Transform. Is there a better solution to keep the thrusters in position while the object moves independently?
This runs in separate thread on a fixed interval:
