maybe I’m working in the completely wrong direction, but I want to calculate the speed and acceleration of a gameobject which I’ve animated along a path (for some basic physics calculations).
(it’s converted to local space later, but the error is seems to happen here)
So like in physics 101 v=delta s/t; a=delta v/t;
The problem is, that I get massive oscillation in the result, although the object seems to run smoothly along the path.
I want to use those values to emulate a car body leaning as if affected by g forces. The result looks more like vibrating jello.
Any ideas what I do wrong?
Update:
I thought maybe the float imprecision might be the problem and reduced the updates per second. But even with myDeltaTime of 1/5s the problem is clearly visible.
With less than 2 updates per second the error seems to average out, though.
Why are you not using the physics engine to implement the behaviour of this car?
On the specific question: what’s myDeltaTime? It appears to me that your custom delta time does not match the actual rate at which your function is executed. Assuming this code is located in Update or FixedUpdate, use Time.deltaTime instead.
Yeah, I was wondering about that myself. First of all I wanted to keep control over physics effect and not handing it over to the Unity physics completely. What I might do is use it to get my acceleration data. I’ll check that out.
The reason I did this, was with very high framerates Time.detaTime becomes very small, emphasizing the effect. So I made a static deltaTime and saw to it, that the function is called at that frequency (currently 10time per second).
the reason you didn’t use the correct simulation delta time is also the reason for your anomalies.
You can not just use phantasy values that are not related to the simulation speed and expect the outcome not to react correspondingly to it by ticking out, as mathematical equation systems have stability requirements and I would bet that your “not delta time” potentially isn’t fullfilling them.
Well my delta time is not an arbitrary value. It is actually the sum of all deltatimes that have passed since the last call of the function and is hence as accurate (or not) as the timing of Unity.
I tried to run the function every frame and divide through Time.deltaTime from the start, but the oscillation was much stronger with that approach. The averaging over several frames reduced the error somewhat.
I’m starting to worry that there is no error and my animate-along-spline-script actually produces those variations in speed, which are just not visible or too minute for the eyes to see.
I guess then my only option would be the filtering of the high-frequency data with some kind of low pass function.
I think you’ll make your life a whole lot easier if you try and do this stuff through the physics engine. This kind of stuff is what it’s designed for, afterall ;).
I have to disagree: It’s designed to animate objects based on forces and torque alone.
I, on the other hand, animate the car along a fixed path, which is something you absolutely shouldn’t do with physics controlled objects.
At least the manual says so:
So to sum up: Your object is not using any physics of any kind.
Physics of any kind contains collision, as the collision handling and responses are physics too.
You are instead using raypicks to check against the ground during the “enforced movement”.
And your object is somewhere around 0, not at 20000 units away from the 0,0,0 point
I tried to add rigidbodies, just to see what happens, but I gave up on that. Other than that, there are no engine controlled physics. Just my own pseudo-stuff.
In the future I might need colliders. But not as of yet.
Actually I don’t know what raypicks are. I calculate the difference of the object relative to world center over a period of time. After that I transform it to object space to get the relative speed(changes).
Well… not 20.000, but around 1.000 might happen (depending on the size of the race track).
Since you’re not using physics at all, this is probably your problem. Most splines don’t have linear “speed” (i.e. fixed time step samples yield different distances depending on where on the spline you are). You may have to do some additional math to traverse the spline at a fixed speed.
Yes, I know what you mean. I wrote indeed quite a few lines of code to circumvent that problem. The spline vertices are the same distance from each other (with minor variations within a 100th of a unit). And position and rotation is interpolated with an algorithm which I (admittedly) still don’t fully grasp.
That might actually be the problem, that the big amount of vertices act like a cobblestone road, shaking my car around and messing with my velocity readings.
That would mean on the other hand, that I have to rethink the game from scratch.
If there’s still somebody interested: I just exported the position of the car to a csv file and let openoffice plot the path.
Looks like the car movement is as smooth as it ought to be.
That makes me hope, that there’s a solution out there for me.
If anybody should ever run into a similar problem, here’s what I found out:
There seems to be indeed a problem with float precision. I changed as much as I could to double precision which happens to smooth out the oscillation.
I’m not willing to do everything in double format (e.g. Vector-Transformations), so the problem isn’t totally gone, but I could handle that with a little bit of averaging.
I can only guess what the real problem was, but I assume it’s not a good idea to divide floats(-vectors) with very small numbers (deltaTime squared in my case) and do too much operations like normalizing and multiplying after that.
