koobas.hobune.stream
Drawn trajectory different than real trajectory
Hi all,
I'm trying to draw the trajectory of a projectile (aka Angry bird). I managed to do it, however once I launch the projectile it doesn't exactly follow the trajectory, and I don't manage to find from where comes the difference...
Here is the code I'm using:
void OnDrawGizmos(){
GameObject player = GameObject.FindWithTag("Player");
float h = 0.0f;
while(player.transform.TransformPoint(PlotTrajectoryAtTime(h)).y >= 0){
Gizmos.DrawSphere(player.transform.TransformPoint(PlotTrajectoryAtTime(h)), 0.2f);
h = h + 0.1f;
}
}
public Vector3 PlotTrajectoryAtTime (float t) {
return startVelocity*t + Physics.gravity*t*t*0.5f + startPoint;
}
public void Update(){
if (Input.GetKeyUp(KeyCode.L)){
GameObject player = GameObject.FindWithTag("Player");
GameObject.Find ("Rock").transform.position = player.transform.TransformPoint(0,startPoint.y,startPoint.z); //the object to launch
Vector3 force = player.transform.TransformDirection(startVelocity); // to launch the rock in the good direction
GameObject.Find("Rock").transform.rigidbody.velocity = force;
}
}
However the trajectory drawn in the Editor is "higher" than the real trajectory followed by the rock... amy idea?
Cheers,
Nicolas
Game physics and real world physics are different. Game physics just estimates curved flight using straight line movements over 50 frames/sec. Each line will be a tiny bit over or under the actual curved line, but very close. Unity apparently applies gravity first.
You could move the thrown rock using the real physics formula, then "release" it as a rigidbody when a spherecast or something detected an imminent crash. Or, I think you could tweak the real calculation for your curve to match Unity's. Maybe subtracting 1/2 a frame's worth of gravity from the starting amount might give consistent results over various arcs.
Thanks Owen. Actually, the problem came from the fact that the Player object localSize was different than 1, thus when I used transformDirection to calculate the vector it led to problems. I'm now using an object with a size of 1/1/1 and it works perfectly :)
You mean TransformPoint, in line 23. It may have been putting your rock a bit too low. TransformDirection doesn't use scale (since it's often used exactly as you're doing -- to make a speed. TransPoint often places a child, so would care about scale. Both could have been written either way,)
It's good to know that TransformDirection doesn't take the scale into account. I will try to replace TransformPoint then, as I'd like to be able to change the size of the player without affecting the trajectory. But when it's set to 1 it works perfectly, it's good :)
I'm having the same problem with the calculated trajectory "higher" than actual trajectory. The difference is consistently about 7% of the "jump" height. I checked the formulas many times and tried various implementations always with the same result. It's not the scale and there is no air drag. Artificially changing the initial velocity and/or direction even by a tiny bit only makes things worse.
If I cannot find a fix I will have to implement my own physics replacement as my game relies on EXACT trajectory, as the trajectory is calculated by the game and cannot be influenced by the player in my case.
