ProjectileMovement physics are framerate dependent

I found out today that the ProjectileMovement physics we can add to our blueprints have an effect that are dependent on the framerate; On low end computers object falls very close while on high end the projectiles fly very far. Definitely not what you want for projectiles. (visible for example with x velocity of 2500)

I really like that component and obviousely its really convenient but its not usable for most situations because of that. Is there a solution to this problem?

Make custom BP, that calculates position from 1/2gt*t, store it in graph at construction time then play.

Your problem worries me about rest of physics, if its framerate dependent, imagine something like off road car either driving, not moving or just bouncing depending on framerate.

I was concerned about this so I set up a test case today and it worked fine for me. Can you give more detail about what you were doing?

My steps:

  • I made a BP based on Actor, with a sphere mesh and a projectile component. I set Velocity to 2500,0,0 and spawned it in the Level BP via a custom event/console command.
  • I launched my projectile (at 60hz) and it stuck on the ground.
  • I capped my framerate to 4hz with “t.maxFPS 4” at the console
  • I launched another projectile and it landed right on top of the first one.

Any more info you can give would be very helpful :slight_smile:

[FONT=Comic Sans MS]Woohoo!

Jeff Farris to the rescue!

:slight_smile:

Rama

Hello Jeff and thanks for the feedback.

Following your confirmation we digged into it further and found out that our projectiles initial location direction was wrong.

The reason why the physics where so framerate dependent is tricky;
Our projectiles are shot from canons;

.
The projectile start position initial transform rotation was wrong by 90 degrees. As a result the projectile bounced inside the canon but somehow managed to shoot out straight out of the barrel making us think everything was fine…

We rotated the transform and now the projectiles paths look similar on both low and high end computers.
Basically this confirms that physics are fine for projectiles, but don’t rely on bounces. This said if you need to make something bounce just a couple of times I suppose it should be fine.

Thank you, sorry for this, let me know if you want me to perform some tests for you.

Hey Rama how are you doing? Haven’t had time to answer you last PM, been crazy busy lately…

Have a good one!

I’m doing great!

Send me some pics/videos of your project when you get the chance!

:slight_smile:

Rama

Multiple bounces should still result in similar results independently of the framerate, but in the case of a very small constrained space with the likelihood of many repeated bounces I am not surprised they diverged. We cap the number of iterations of the simulation (so something doesn’t bounce around infinitely), and that is likely where you saw the difference.

Anyway I’m glad things are working! In the future it might be wise to set the projectile to ignore the collision of the owner, at least for a brief initial period of time. That would help you find such issues and also be less susceptible to initial collision conditions.