Predict Projectile Path - is there a way to have it incorporate Linear Damping?

I’m working on a golf game (blueprints only at the moment) and want to show the projected path of the ball before the player swings. Predict Projectile Path works beautifully for this… or it would, if only it could take into account not just gravity and launch velocity, but linear damping as well.

My projected path would always go much further than the real path. After some head scratching I figured out that If I set the linear damping on my ball to zero, then the predicted path matches the final path perfectly (after the ball has actually been launched). But there has to be some linear damping on the ball, otherwise its trajectory is completely unrealistic as it doesn’t lose any forward velocity until it’s on the ground.

Does anyone know if there’s some way for me to predict the path with linear damping as well as gravity? Seems like maybe it would only be possible in C++, but hopefully not?

I’ve read that the linear damping is calculated as (damping * velocity * mass), and so I’ve found a way to approximate it by getting the projected path, then taking all the projected points and progressively reducing the XY movement from point to point by a greater and greater amount (so the XY distance travelled gets progressively smaller). But obviously it would be much better to get UE to calculate it properly.

Thanks very much for anyone’s insight!

So, predict projectile path draws a line via primitives which is probably more performant than what I’m suggesting.

However for gameplay purposes the result is usually not good enough.

To customize this you can use splines.
In essence you only need the starting point and the end point in 3d space. Then you can bend the spline via the tangent values.

As far as calculating the end point value you have the right idea. A simple math formula to calculate the end point - the start point and tangent is always known.

What I’m not 100% sure on is how you’d be able to tell if something is in the way.
Predict projectile path does that for you. A custom spline would not by default.

What you could do though, is to run several actors along the spline over time to check for collisions and affect the result.
It may actually be more beneficial… it’s just a lot more going on than just using the node.
Maybe you can find some marketplace pre-baked solutions for this…

Alternatively you could implement via C++
FPrimitiveDrawInterface* PDI to kinda copy/adjust the native function.
In fact you can probably just steal it’s code and re-purpose it a lot easier if you are willing to depart from BPs…

Thanks for the detailed reply!

Using splines sounds good. When you suggest bending the spline via the tangent values, how would I go about doing this?

Sorry, it’s a little over my head, but if I use a simple math formula to calculate the end point, rather than using Predict Projectile Path, then I won’t have the tangent values that Predict Projectile Path (Advanced) can output for each point. So are you saying that I’d calculate the tangent at various points (arbitrary points?) along the path that my “simple math formula” generates?

A spline works fine with just 2 points and 2 tangents, one for each point.

I may be wrong on this, because the engine does whatever it wants most of the time when it comes to splines, but…
The way I would envision it is that the initial point has a tangent, let’s say 45deg forward vector. The end point is just there, and visually the initial tangent should be enough to cause the spline to draw in a arc shape.
I don’t think the final arc point needs a tangent value unless you need to create some sort of an S shape. Possibly for a bounce, you’d have to re-calculate that.
To aid with it, you could turn the spline point generation into a recursive function that just loops and adds an end point, if you need to account for bounce. Golfball Can bounce on concrete. you could implement that by checking the physmat type. Would actually be kinda cool.

Should the end point need a value, I would probably just use something fixed like the end point with a Z value around half the max height of arc.

The formulas for basic projectile motion have been the same for ages. I’d stick to those.
With one possible observation. the apex is always at half of the overall flight distance in a “perfect” world.

If you want to be more precise you should probably look up any external ballistics documentation. While rifle twist and other gun-related things won’t apply to the golf ball, other like wind sheer could.
Out of all the docs, for rather obvious reasons, the USMC ones are the most accurate :wink:

Lots to chew on there, so thanks again for your thoughtful replies! I’ll see what I can do, and if I get some positive results I’ll try to post them in this thread.