- Home /
How to fix the delay caused by Mathf.Sin
Hi,
I'm making a simple interactive mechanism of a reciprocating engine. I am experiencing some weird behavior from Unity.
As the piston gets closer to top dead center and bottom dead center, it is in the right position in relationship to the lever arm. However, when the piston is moving between these positions, a gap develops, as if the crankshaft was lagging, and the piston was moving too fast.
Here's the code that makes it all happen
coursemod = Mathf.Sin ((shaft.transform.rotation.eulerAngles.y)*Mathf.PI/180f);
course = (longrodscale * (25.4f) * coursemod) + longrodscale *25.4f;
tempv = this.transform.position;
tempz = course -5f;
tempv.z = tempz;
this.transform.position = tempv;`
List:
What I am doing is first getting the sine of the rotation angle of the shaft so I get values between -1 and 1 which are assigned to "coursemod".
I use this to affect the course value, which is computed by using "longrodscale" variable that can be modified by the user, and multiplying it by "coursemod". This give me "course".
I then have to use a temp variable to store this, and retrieve the transform.position of my piston axis, so I can alter it.
After many minutes or hours I've lost count, I came to the conclusion that I have no idea how to fix this behavior and I am not sure what exactly is causing it. If anyone has experienced anything like it let me know, any hint is welcome.
Yes, I have clicked that button, when I copy pasted my code, but for some reason it turned out like that, even if I tried to edit it afterwards, it stayed the same.
Unfortunately not ;) If you place a bullet-list after a code block, the code block doesn't work. Insert at least one normal line of text. Yes, the UA markup is strange...
Good to know ! I didn't understand why it didn't display properly.
so @HROP has this in fact solved your problem dude? vast numbers of people have now put vast amounts of time in to this!
I'm interested whether your problem was in fact the forgotten rootL2-R2sin2Theta factor .. or was it just some other trivial problem?
@Fattie There were many issues:
there is the L1 = sqrt (L2 - sin^2) that I wasn't considering.
there is the fact that I was using the converted Euler angles of the shaft, ins$$anonymous$$d of assigning manually a value for the angle.
Also, I was using "look at" to assign the correct angle for the conrod, kept the graphical representation of the rod lagging even at low RP$$anonymous$$
I was calculating many times the sames values of cos or sin, in different scripts.
For some reason I forgot to change one of my updates back to Update (it was set at FixedUpate)
I just rewrote a "main" script where most of the calculations are being done in one update, and then the other game objects go and grab these values. I still get some lag at higher RP$$anonymous$$, but it's acceptable now for what I'm planning to do with it.
I'll post up the code, when it is cleaner. Thank you all for your help !
Answer by Bunny83 · Sep 26, 2012 at 12:01 PM
Fattie is absolutely right, the vertical movement is not a pure sine curve. Here, i made a quick sketch ;) The point is that the red line (L1) has a fix length, but it's not parallel to the movement axis (except at the top and bottom point). You need to calculate the projection of L1 onto the movement axis and add it to the cos-position (or sin depending on where you start counting)
However i guess your problem is that you shouldn't use eulerAngles this way. EulerAngles are caculated from a Quaternion and might not represent the angle you would expect due to gimbal lock avoidance.
You should use a float variable as angle that you adjust yourself. You can rotate the axis also by this angle. Never rely on an angle returned by eulerAngles.
Up voted for the mad $$anonymous$$SPaint skillz exhibited in your answer.
Thanks for your help !
I'll try assign the angle value manually, that might be the cause of this lag. I'll let you know the outcome tonight.
btw, i made an octave plot of the movement of the piston. I used extreme values for L1 / L2:
L1 = 3
L2 = 2
The curve gets closer to the normal sine the greater the L1/L2 ratio is.
This is one of the best answers I've seen in a while, and to a great question, too. The Q&A-pair looks almost schoolbook-like at first glance because of the illustrations. :) +1's all around!
PS: I've given up on scolding posters for poor code formatting. UA is fundamentally broken in that regard.
Your answer
Follow this Question
Related Questions
Physics Optimization. 0 Answers
Is this code inefficient? It is causing Lag. 1 Answer
Optimization -1 Answers