I try to take velocity of object(sphere) by GetPhysicsLinearVelocity()
Value is correct at fps under 100 but incorrect in fps at 10.
For example shepre moving on horizontal plane:
I use t.MaxFPS to change fps
Help please.
Interesting because I had a similar, if inverse, problem: when I set the max FPS to 200 all the forces got stronger so a minor tap of the foot became a punt into orbit. I never got an answer as to why but I couldn’t reproduce it in a separate project (and I can’t share the one with the issue).
I am not using forces) Its just by gravity.
I make more research and I see that 30 fps its minimum for correct velocity value. < 30 fps - velocity same but change position by frame wrong(game play slowly).
It’s the same simulation. Forces cause velocities and I said the objects go into orbit which means very high velocity. And if you don’t have physics simulation turned on then getting the velocity won’t work at all so I assumed you have it enabled.
Pretty sure we’re seeing the same issue: the update rate of a simulation should never affect the realtime physics being simulated. You go low and you get less velocity, I go high and get more velocity. So something is wrong. If we’re seeing the same problem then that means neither of us is crazy and bolsters our case for investigation.
Did any of you figure this one out?
I’m trying to figure out exact velocities and are getting unpredictable/wrong values too.
I’m setting the velocity straight using SetPhysicsLinearVelocity and have also tried Impulse but none of them seem to be causing the object to move at the correct speed.
I think you can make “patch” by using current fps for modify your calc. But its need research - linear dependency or not) I decide - my game will not work lower 30 fps) Or need code research for finding place where physics simulation make slowly
an expensive workaround could use EventTick (which is ■■■■■■ overall but may be okay depending on your needs)
create a previous_frame_location variable
on each tick, update the variable.
when needed, check the distance between current and previous locations, and divide that by tick’s Delta Time (time between frames in ms)
this way you will get the physical velocity (v=m/t)
notice that TickEvent is the shittiest solution possible so use at last resort :]
Modifying the engine seems a bit daunting and the only other option is to figure out the velocity yourself.
On tick, subtract the last location from the current location and divide by the delta time. That will be your velocity vector at that instant. The lower the FPS, the less accurate it will be, but it shouldn’t be affected by the tick rate.
IMO doing a subtraction, a division, and a copy of a vector, on tick, is not expensive at all. Even in BP is fine but if you’re counting cycles then you can throw it into a base class. I’m giving my opinion on this because my answer suggested this method already.
The fear of using tick is healthy, but it’s not something to avoid at all costs.
I have been doing that to calculate my own velocities.
But the problem is when setting velocities and expecting objects to follow those set velocities, which they don’t. This means that you cannot use the engines physics to make precise or reliable physics movement. If I set an object to travel at exactly 300m/s it won’t travel at 300m/s.
I discovered this as I was error testing why my velocity based damage system wasn’t lining up at all between Remote clients and server.
I have other situations in my game where this is also a drawback.
Can you recreate the issue in a simple example project? If so, you should post to the Bug Reports section and give it to Epic so they can figure out what’s wrong.
When I was searching around on the forum some people seemed to be saying that its because they are using physX which is a non-deterministic engine. Something like that.
I did make a Blueprint just to prove it but I think they already know about this issue and it is not a bug per se, just that their physics engine is not designed to be reliable.
I re-read my post on this issue and realize now that SeanL did say it is framerate dependent. That sounds pretty stupid. Good to know. So any project with physics can reproduce this issue.
Wait. This makes no sense. Frame rates fluctuate all the time but we don’t see physics changing like that. A dip from 60-30 would have enough effect that we’d notice, but has anyone?
Found this thread, which I actually participated in. Man… Development can get so blurry. I forgot I posted there at all.