LineTrace different at 30 fps

Hello friends,

So my problem is this:
I have an anti gravity vehicle which hovers over the ground.
I made this by using a linetrace at the vehicle’s world position which points downwards to the ground.
Everything works great so far at 60 fps.
I can drive the vehicle through a looping with my desired speed and the distance from ground to vehicle stays the same.

But at 30 fps this doesn’t work so good anymore.
Due to the lower framerate, it seems the linetrace can’t keep the height correct when entering the looping.
Which results in the problem that the vehicle will be pushed into the ground of the looping, which will be pushed back when it collides with the ground. This repeats on and on until the curve ends and it gets flat again.

hope you guys know what i mean.
I attach a little picture for better understanding:

My question now is, how could i solve or get around this issue.
I tried alot already.

Thank you for reading and have a great day.

Are you adding velocity, adding an offset, or setting location.
Adding velocity and adding Location/Rotation are going to be framerate dependent since you apply x value every tick. The solution is to multiply the intended distance or velocity by deltaTime (or “getWorldDeltaSeconds”). DeltaTime will transform your every-frame math into a rate over time. Including deltaTime is going to throw off your original math somewhat, so also multiply deltaTime by whatever your working fps example is (so multiply by 60).

Setting location every tick (for movement) is arguably deterministic, so setLocation and setRotation nodes shouldn’t behave differently with variable framerate. I don’t recommend using these nodes for player movement, as beginners may find themselves gliding through geometry.

Im adding velocity with AddForce which automatically calculates with DeltaTime.
Im also using AddForce for the height by simply getting the LineTrace distance and then lerp it when desired height is reached.
Im not setting location anytime.

I think my vehicle is just to fast to do it that way. It seems i have to use splines to get better results.

IF the line trace is run on every tick, then you are forced onto whatever happens on a tick by tick basis. (ei: too fast for the trace is indeed correct).

You could try to adjust the time of every tick for the object though. maybe if you make it less then the default value you can easily circumvent the problem and keep it steady.
Just don’t over-do it since the tick event is costly enough as it is.

Are you using physics substeps?

Yes, i do linetrace every tick. I’ve read that tick is costly and im trying to avoid it as often as i can. But for now i have to use it because is reads the normals of the track and so i can calculate the rotation.

I have tried it but i don’t seem to understand how to use it correctly.
I have read that i have to enable smooth frame rate range in order to use it, but it seems to do nothing at all.( yes i hit the checkbox at the substep setting).

As of now i try to use splines. hopefully i can get this to work. Otherwise im out of ideas.

The substep wouldn’t necessarily affect the model if you are controlling its position via line traces.
it’s more of something used to smooth out physics assets when you simulate physics. For example on the positioning of a rag doll.

Because you are dealing with a vehicle the tick on it shouldn’t really matter too much. Meaning: this is your core functionality. Dedicate more resources to it and free them from elsewhere.

Also, instead of relying on a direct tick, because you are traveling at X speed you should be computing the distance ahead at witch to check instead.

let’s say you are traveling at 60kph.
solve it down to meters per second. 60 min = 60km.
1 min = 1km.
1 min = 60 sec.
60 sec = 1km > 1,000m.
1,000/60 =
~ 16.666 meter per second.

Since a tick is approximately every millisecond, let’s bring this value down to 1.666. (Divide by 1000).

So to get the information you need, your trace should be ahead of the car’s nose by 1.666 meters.

Store that value, (the worked out normal information of the hit result) and use it on the next tick’s calculations instead of the current one by simply changing all your math you have to utilize the variable you saved instead.

To complete the system, vary the distance ahead by the actual speed solved at every tick but as simplified as possible.
maybe even use Round or Floor to get less complex calculations and gain very minimal performance back.
And not the final result but the starting speed.
If you can get the speed in milliseconds to begin with you’ll save some processing time for instance.

Thanks for the detailed answer.
This sounds like a good idea to try out.
Im going to try this out when i have time.

Me again

Me again.
I have done this now and what can i say. Dude this really works quite well.
Its pretty nice but at the same time little bit sad because i have already made a good spline setup. Its not finished yet but still.

Thank you again and i hope i don’t get some trouble later with this method.
I mean, who is gonna play a fast racing game in 30 fps anyway right? :slight_smile: But you never know i guess.

Alright then see you and have a great day.

It’s the same amount of load right?
it’s not like you are reading 4 different new line traces, you are just “precaching” what is literally about to happen in the next frame.
I doubt it would affect much or get your into errors.

As far as “how did you come up with that?”
well, the base idea is actually part of the Turn In Place animation tutorial.
They pre-cache animation stuff in it and use it the next frame for increased accuracy.
also it’s a similar theory to reactive water buffers concept wise.

The reason the substep helps is that the forces calculated from the linetrace are applied during the substep.

*At least it helped our vehicle simulation loop-de-loops - you may have a different issue entirely…