Unreal needs a native "Event Physics Tick" blueprint node (framerate independent physics)

General Feedback & Requests
, , , , ,
1

FOR THE EPIC TEAM

On Blueprint projects, there is only the “Event Tick” node, which is framerate dependent. Physics calculations performed on this event are affected by framerate variations, making it unfeasible to create blueprints that require custom physics calculations.

This is a huge problem for physics based games, as framerate independent physics is the most important feature for this type of project.

I am aware that UE4 has “substepping” and UE5 has “Async Physics”, however, both are suboptimal solutions, as they only affect unreal native physics components and everything is handled internally.

These solutions does not work for user created blueprint classes. This can be solved, by the inclusion of a native “Event Physics Tick” blueprint node on a future version of UE5.

This Physics Tick event needs to run on a fixed timestep (fixed delta time) and support nodes as “ApplyForce”, “ApplyForceAtLocation”, etc…

Unity for example, has “Update” and “FixedUpdate” functions. To ensure framerate independent physics on a Unity project, it is only a matter of using the “FixedUpdate” for physics related code.

Now, I know it is possible to use c++ to implement a custom “Physics Tick” Event or use third party plugins that does that. However, framerate independent physics should be a native feature of the game engine, available “out of the box” for both c++ and blueprint projects.

FOR OTHER DEVELOPERS LOOKING FOR A SOLUTION

If you are a user strugling with this problem, here are some third party plugins that may help you:

UE 4

UE 5

I hope Epic releases this feature soon

2

I don’t see that being a feature that Epic is going to add to the mainline engine, especially as apparently it’s not too difficult to add in plugins there. I do wonder how they manage to do that, considering that blueprints run on the game thread. Smells like smoke and mirrors, IMO, but I’d love to hear an explanation.

4

Both “substepping” (UE4) and “Async Physics” (UE5 ) have physics tick events that runs on a separated thread on the background.

Basically, the feature is “already there”, but it is hidden from blueprint users by default. The plugins just expose those events to blueprints.

Yes, there are third party plugins, but framerate independet physics should be a native feature. The plugins only exist to workaround this limitation.

As long as EPIC doesn’t solve this issue, blueprint projects will continue be “flawed” by default, making it unfeasible to develop physics based games using 100% blueprint source code.

It is a huge flaw, that have a simple solution. I don’t see why EPIC would not wan’t to implement this.

4 Likes
5

yes. But as far as I’m aware, it’s not possible to call into blueprint outside of the game thread. I’d love to be wrong about that. That’s the part I’d like to hear an explanation for – how do you call into blueprint off the game thread without crashing everything

On the other hand, the amount of overhead that blueprint calls introduce makes it very, very unsuited for advanced things like that.

6

By definition, .NET events can run on any thread. So it is possible to have a event inside blueprints that is called outside of the main game thread.

The MMT and AsyncPhysics plugins are proof that is possible to do it on both UE4 and UE5 and still maintain good performance.

Regarding performance, this depends on the project, by following programing best praticies it is possible to develop performatic games using blueprints or c++.

C++ projets are only faster than blueprints, if the programmer knows what he is doing and follow best praticies.

And of course, on specific cases, it is also possible to refactor the entire project to c++. But only if needed.

The way thing are today, framerate independent physics math is only achievable on c++ projects. By adding this feature to blueprints, developers will have more control over their projects.

As long as they follow programming good praticies it won’t “crash everything”. But this is true for every type of project. Including c++ only projects.

Developers are not kids that needs the game engine to hold their hands to prevent them from breaking their toys. We are engineers, we need freedom to design stuff, if we break anything along the way, we just look back and figure it out what have we done wrong and fixed it.

So, there is no reason to not allow blueprint users to access a “physics tick” event.

7

Is it really that hard to just use some simple math based on deltaT? Like if you have some logic to make something move or rotate at 10 units per second, it’s just rate*deltaT… And that will give you exactly how much something needed to move in the time between frames. If it were 16.66ms, then it would be 0.166 units, if it were 150ms, then it would be 1.5 units, if it were 2ms, then it would be 0.02 units, and so on. If you’re already doing custom physics calcs, this type of scaling is about as simple as it can get.

8

While that tends to work with a lot of game type things, there are situations where that just doesn’t really net a good result. Particularly when you’re looking at very small things and/or very high velocities, but in general, the more steps you can get, the more accurate you are going to be with your simulation. I’m certainly not questioning the need for increased rate of physics ticking, I’m not convinced that blueprint is a good way to do it. And I’m still a bit mindblown regarding those plugins actually working, because afaik blueprint access is completely not thread safe.

9

That’s what substepping is for. For almost all normal circumstances, scaling off deltaT is going to be perfectly fine in 99.99% of use cases.

10

yes. and the request for this thread is to expose the substepping to blueprint

11

This does not work for continuous forces math, if you do this on the default “Event Tick” it will be framerate dependent. Meaning, the resulting force will be stronger or weaker based on framerate variations.

Nodes like “AddForce” or “AddForceAtLocation” already scale forces by delta time on the background by default. When substepping is enabled, these nodes will distributes the force along the substepping ticks on the background.

But this is not a perfect solution, as it does not work for continuous forces math (like spring forces for example).

On pratical terms, there is a huge diference between applying a small force on higher frequency and apply a large force on a lower frequency. Even, if the total force applied over time is equal on both situations.

In order for continuos forces to be stable, they need to be calculated on a higher frequency and a fixed time step.

The way other game engines solves this problem, is by separating the physics thread by default. For example, Unity has the “Fixed Update” event and the “FixedDeltaTime” property is exposed to be used for physics math. This ensure framerate independency.

On Unreal, both “substepping” and “async physics” use another thread to calculate physics. The issue is not allowing developers to access the physics thread on blueprints, as continuos forces needs to be scaled by the physics thread delta time and applied on the physics thread frequency to work properly.

12

That’s different though. Was talking more about people doing custom physics from scratch. Like using projectile motion equations and inputing your own custom forces and whatnot.

And for a good reason, they are async with each other. So you’ll either hold up the blueprint thread waiting on a physics update, or hold up the physics thread waiting on a blueprint update, or put in some maximum limit of missed updates before it stalls to wait for the other thread(which can lead to massive issues). If you exposed stuff to blueprints, it would likely just lead into more headaches than it’s worth; where people report a bunch of bugs that aren’t actually bugs, just improper design.

Best advice, just handle the continuous forces manually if you really need that much control. The math isn’t super hard to implement and even though a lot of it is technically calculus, you can just use the simplified algebraic equations. Chances are, if you need that type of control, the game is probably simplistic enough that the BP performance wouldn’t add up to much unless you’ve got hundreds of actors ticking the code. In normal games and under most normal circumstances, letting the physics do their own thing is the best path to take.

13

Just because Blueprints are currently limited to the main game thread, it doesn’t mean it has to be this way forever.

The whole point of the feature request is to allow users to access the async physics thread from blueprints.

This way users would be able to perform custom physics math on its own thread (like other game engines do)

As mentiontioned on my previous reply, this is not possible if you don’t have access to the physics thread.

Even on c++ projects, you need to perform a bunch of customizations to access the Substep thread on UE4 or the AsyncPhysics thread on UE5.

Accessing the physics thread should be easier for both c++ and blueprint projects.

As for improper design, there will always exist people that don’t follow programming best praticies. It doesn’t matter if the new feature is simple or complex, there will always be someone using it improperly.

This is not a reason to stop adding new features to improve the engine. Otherwise, there would never be new features again.

14

I don’t know, it just sounds like a massive headache that would likely lead to a race-condition hell, which can become one of the biggest headaches in threading and debugging. Maybe one day, but that day is definitely not today and likely not within the majority of UE5s lifespan. It would like require some serious refactoring of the entire engine, to become reliable enough for use with blueprints, without haveing a million “don’t do’s” to work around.

15

I can only disagree, Unity handles framerate independent physics this way and have only 1 do/don’t: Physics related code goes into the “FixedUpdate” event.

AsyncPhysics already separetes physics from the main game threat. So most of the refactoring needed is problably already done.

Since the AsyncPhysics feature just got included on UE5, and I can only assume is still being improved, this is the perfect timing to add this feature.

Otherwise, UE5 AsyncPhysics will continue to have the same issues Substepping had on UE4.

16

Again, you’re forgetting the BP side of things… BPs would likely need the refactoring. Unity doesn’t have BPs, so you’re comparing an apple to an orange.

They are making steps in the right direction, but I honestly think it will be another year or two before we even see better BP<>AsyncPhysics interactions, due to the way BPs are threaded. We can speculate all we want about X should be easy to implement, Y should work, Z shouldn’t work, etc etc, but we aren’t the engineers coding the millions of lines of code in UE. If it’s not in the engine right now, there’s probably a good reason for it.

17

Of course I’m aware of that, that fact is, even on C++ projects, there is no “Event Physics Tick” easily accessible for the user.

As mentioned before, even on c++ projects, it is necessary to perform customizations to achieve framerate independent physics.

This is not user friendly and frankly, framerate independent physics is a critical feature for any physics based games.

That’s the whole point of posting a sugestion. So developers can see them and add them in the future if they make sense.

Pleople on the forums can argue if it is a good idea or not, but at the end of the day, only the official developers can confirm that.

18

Also, Unity new Visual Scripting Solution, which is the equivalent of UE BP’s also has access to physics tick event. So no, I’m not comparing apples and oranges.

Unity supports framerate independent physics on both C# or Visual Scripting projects

So it make sense that Unreal would do the same for both C++ and Blueprint projects

19

Bolt is not equivalent to BPs… It’s an extremely stripped down version of BPs basically. With UE, you can create a 100% BP game that has actual complexity to it on par with AAA games and publish it. Last I messed with it, Bolt can’t come even remotely close to that. You can do a lot with it, but again, it’s a baby compared to BPs. Still apples and oranges.

I’m pretty positive they are aware of the situation and have been for quite some time. The issue lies in the demand for said features, which apparently isn’t high enough. And by demand, I mean actual productions that will net Epic non-trivial amounts of revenue, like AAA studios.

20

Unless you need framerate independent physics on your game. Then you can’t.
Which is the whole point of this feature request.

21

+1 for me. I’m making a 100% blueprint game and stuck with this problem too.