People have been wanting custom gravity since the beginning of the engine. There are a ton of problems with the current implementation of gravity, namely:
>Can’t customize the direction
>Terminal velocity is just a clamp on the maximum acceleration. True terminal velocity is a mathematical limit. IE. the acceleration eases into the terminal velocity
>Can’t account for drag forces (have the gravity adjust to a parachute vs a boulder)
>Have to do some hackery to get gravity to work with water
The solution is simple: Physics volumes that work like post processing volumes.
Instead of setting up gravity in the project settings, you would create an unbound gravity volume in your level and set the parameters there.
The idea is that devs could create their own custom volumes that do whatever they want. If you are unsatisfied with the current gravity formula and want to do something like custom planetary gravity, just create your own volume. It makes things like buoyancy or wind easier as well.
I guess this feature should be called a “Force Volume” to distinguish it from a Physics Volume. A Force Volume would apply a vector force to all simulated scene components within the area (or alternatively to the entire level if it was set to unbound).
As it stands, custom gravity is only complex because
>The direction is hardcoded
>There is no easy way to affect all simulated components at once
Force Volumes would turn the complicated topic of custom gravity into a simple one: Just create your own unbound Force Volume and write some simple physics logic to create your custom gravity.
Physics volumes don’t appear to have gravity. Pain causing volumes are an extension of physics volumes that commit pain. It would be odd to see them apply gravity… It’s already odd to see them apply physics! I assume pain causing volumes exist as a tutorial aid instead of a core engine feature.
Force volumes or gravity volumes would be interesting, though you would expect specific behaviors to exist for gravity that might not apply to other forces, such as character orientation or object buoyancy.
I always wondered why this is so complex. I searched for gravityZ in the source code and “only” had 100 affected lines and 29 matching files. There was a guy who made a pull request and afaik it “worked”. From another thread I also read this needs to be done in PhysX and not in the engine code, but PhysX in general is not limited to gravity in Z direction. I assume all movement components might have some tricks when using a single float for gravity which makes rewritting the code painful, but I never read a statement from an engine dev. Also we are not even talking about custom gravity on custom shapes, just simple world wide gravity in 1 direction.
Most likely the problem would come from the next step which is that the movement capsule assumes 0,0,-1 gravity and 0,0,1 orientation. So even if you have gravity direction you\ll get screwed on anything other than sphere collision. And that change would probably ripple a lot further. But yeah, spherical terrain, double precision, gravity volumes etc. would all be great. But since Epic doesn’t need it…
Here’s what the Force Volume would look like. It makes custom gravity, drag, bouyancy, etc… very simple to create.
A game engine is supposed to be a framework for game design. Unreal Engine’s gravity is a implementation of a force, and not a framework for forces, which is why it is so difficult to work with. Idealy, the hardcoded gravity implementation would be removed altogether and replaced with a force volume that can be dragged into the level.
In any case, while arbitrary gravity may be easy, if you’re limited to global parallel gravity then it’s not going to add that much utility. Localized arbitrary gravity and a general solution for force-applying and physics zones would be much more useful, but also needs to be implemented from scratch and then hooked up to PhysX, the particle system, and perhaps many more things. Not to mention brush-based ‘volumes’ are on the list of things that need to be deprecated.