[Wanderer]

When testing stuff for Blue Planet it was noticed that there are several problems with the animation code. Could some offer some help with the issues?

One annoying is that occasionally weapon 'not allowed to fire due animation' timestamps get bad values. I think i have seen some evidence of this issue in model_anim_get_time_type() function to the part which begins with // if vi is <= to v comment. For animation defined to last in the tables only 2000 milliseconds it gave me delay values in excess of 100 000 milliseconds essentially disabling the weapon bank for 100 s. Reason for this seems to be the

Code: [Select]

..
+ (pss->trigger.end_angle.a1d[a] - pss->trigger.current_ang.a1d[a])
/ (pss->trigger.current_vel.a1d[a] * direction)
..Bit which when current_vel is very low tends to gain extremely high values. Any suggestions on how to fix these?

Also the animations themselves occasionally get stuck between the start and endpoints but this appears to be separate from the 'firing delay' issue.

Both these issues seem to arise when animation is triggered before it has had time to 'rewind' or 'reset' properly. That is the animated part was still moving back to initial position when the next call to move to 'animated' position came. Occasionally it is possible to reset the situation by changing weapon banks and giving enough time for each animation to reset properly but this doesn't seem to always work either.

[Goober5000]

This doesn't surprise me.  The animation code was designed by a certain coder, who shall remain nameless, who has a habit of coding awesome features that occasionally contain bizarre logic.

Is this in Mantis?

[The E]

http://scp.indiegames.us/mantis/view.php?id=2109

[Wanderer]

Noticed that hammering the switch weapon bank keys madly i can get the animations stuck. But this will eventually unwind itself (used time compression) and the animations seem to play out. Sorta like being on queue or being run backwards and forwards simultaneously or something.

[Bobboau]

sorry I haven't had time to review that since you sent me that PM, I was going to look at it this weekend when I had some free time. sense I'm posting can you give me a model that demonstrates the problem well?
I am assuming the animation it's self does not actually take 100 second.

I have to warn you though it's been about 3 years since I last looked at that code.

that section of code quoted is saying (total change in angle)/(rate of change of angle) = time, I don't think that logic is too bizarre, and I did a better job explaining my math in that system than I had in the past, though there were some bits that were a little odd, and the reversing an already active animation code was by far the oddest and most difficult to test.

and there is an animation queue involved, it's how an even in one frame can trigger an animation a thousand frames later.

[Fury]

I haven't played it personally, but I hear Dawn of Sol uses Steve-O's fighters, they use external primary weapon animations. So you can use their modpack to debug the problem.
http://www.hard-light.net/forums/index.php?topic=66994.0

[Nuke]

i looked at the code but i really didnt get how it worked. i did fix a bug where subobjects with disabled hitpoints (0% of hull as defined in the table) would not animate. i kinda wanted variable geometry which could not be shot off. also while i was working on this:
http://www.hard-light.net/forums/index.php?topic=67769.msg1338775#msg1338775

animations werent working as they used to, the animation would seem to animate to a position and not reverse animate, causing the door to rotate in bizzare ways. delay errors would certainly cause this.

[Wanderer]

While watching amazingly bad movie... decided to waste time with this rather than watch Jaws III for the nth time...

Assuming the animated objects look like .. well ... objects then... assuming i didn't this time do whole lot of epic fails.. Phear my awesome and leet graphics skillz.. http://imagebin.org/83125

Math not guaranteed to be right.

Code: [Select]

v = v0 + at
s = s0 + v0t + att/2
T(1) = time from some velocity to zero velocity
T(2) = time from zero velocity to set velocity
S(1) = distance moved before reaching zero velocity after starting from some velocity
S(2) = distance moved after reaching zero velocity before reaching set velocity

 - 1st case - neg velocity
v0 to 0
v = v0 + at || v = 0, v0 = V(initial)
T(1) = -V(initial)/a

 - 2nd case - from zero to set velocity
0 to v
v = v0 + at || v0 = 0, v0 = V(maximum)
T(2) = V(maximum) / a

 - 3rd case - distance during neg velocity
s = s0 + v0t + att/2 || s0 = S(initial), v0 = V(initial), t = -V(initial)/a
S(1) = S(initial) - V(initial)V(initial)/a + V(initial)V(initial)/2a = S(initial) - 2V(initial)V(initial)/2a + V(initial)V(initial)/2a
S(1) = S(initial) - V(initial)V(initial)/2a

 - 4th case - distance during pos velocity
s = s0 + v0t + att/2 || s0 = S(1), v0 = 0, t = V(maximum) / a
S(2) = S(1) + V(maximum)V(maximum)/2a
S(2) = S(initial) - V(initial)V(initial)/2a + V(maximum)V(maximum)/2a

--------------------------------------------------

 - if S(turnpoint) > S(2) then
 
T(total) = T(acc) + T(ss) + T(decel)

 - T(acc)
T(acc) = T(1) + T(2)

 - T(decel)
v = v0 + at || v = 0, v0 = V(maximum), a = A(decel) = -1 * a
T(decel) = -V(maximum)/A(decel) = V(maximum) / a

 - T(ss)
s = vt || v = V(maximum), s = S(turnpoint) - S(2)
S(turnpoint) - S(initial) + V(initial)V(initial)/2a - V(maximum)V(maximum)/2a = V(maximum)T(ss)
T(ss) = (S(turnpoint) - S(initial) + (V(initial)^2 - V(maximum)^2)/2a) / V(maximum)

 - T(total)
T(total) = T(acc) + T(ss) + T(decel)
T(total) = -V(initial)/a + 2V(maximum)/a + (S(turnpoint) - S(initial) + (V(initial)^2 - V(maximum)^2)/2a) / V(maximum)
- unit observation...
s = m/s / m/s^2 + m/s / m/s^2 + (m - m + ((m/s)^2 - (m/s)^2)/m/s^2) / m/s
= s + s + (m + (m^2/s^2)/ m/s^2) m/s
= s + ( m )/ m/s
= s
 -------------------------------------------------
 
 - if S(turnpoint) <= S(2) then
 
T(total) = T(acc) + T(decel)

 - T(acc)
T(acc) = T(1) + T(intercept)

 - T(intercept)
As a is constant and object is at rest at end position the interception must happen exactly between the end position and the position after reaching 0 speed
s = s0 + v0 t + att/2 || s0 = 0, v0 = 0, s = (S(final) - S(1)) / 2
(S(final) - S(1)) / 2 = a/2 * T(intercept)^2
(S(final) - S(1))/a = T(intercept)^2
.. accept only positive root
T(intercept) = sqrt((S(final) - S(1))/a)

 - T(decel)
T(decel) = T(intercept)
 
 - T(total)
T(total) = T(acc) + T(decel)
= T(1) + T(intercept) + T(intercept)
= T(1) + 2 * T(intercept)
T(total) = 2 * sqrt((S(final) - S(initial))/a - ( (V(initial)/a)^2 ) / 2 ) - V(initial)/a


Sooo... in the 'yellow' case i got the

Code: [Select]

T(total) =  (2V(maximum) - V(initial))/a + (S(turnpoint) - S(initial) + (V(initial)^2 - V(maximum)^2)/2a) / V(maximum)and for the green one i got this

Code: [Select]

T(total) = 2 * sqrt((S(final) - S(initial))/a - ( (V(initial)/a)^2 ) / 2 ) - V(initial)/a
And of course this is probably not really compatible with queued items as such...

[chief1983]

This is probably the best thing to ever come from Jaws 3.

[Zacam]

This is probably the best thing to ever come from Jaws 3.

Amen.

[Bobboau]

I haven't played it personally, but I hear Dawn of Sol uses Steve-O's fighters, they use external primary weapon animations. So you can use their modpack to debug the problem.
http://www.hard-light.net/forums/index.php?topic=66994.0

the issue might not arise in those models

[The E]

Those models are the same ones where the issue manifested itself while we were working on WiH.

[Bobboau]

I'm having a hard time getting my build environment working, so I'm not yet been able to test this theory, but I'm thinking this might be a floating point error, how low is "very low"

[Fury]

Any progress on this?

[Bobboau]

I never got an answer back on my question, and I haven't got my development environment set up yet.

[Fury]

What question?

[chief1983]

how low is "very low"

Looks like that one, but I'm not even sure what it refers to.  The delay errors or something?

[Fury]

I saw that too, but didn't recognize it as a question. Even if I did, I don't understand it. I'm guessing it refers to Wanderer's first post.

[Nuke]

i think he wanted a model to test against. i myself noticed a change in animation code behavior doing my sliding door model demonstration. in which reverse animation didnt seem to work (the animations would occur in the same direction over and over again). it was a mystery to me why it wasnt working correctly. i assumed it was a feature and not a bug because i had asked for one way animations in the past, and had thought somebody implemented it and just didnt document it.

[Wanderer]

I'm having a hard time getting my build environment working, so I'm not yet been able to test this theory, but I'm thinking this might be a floating point error, how low is "very low"

If you are referring to the thing i mentioned then this is not it.. That is the excessive waiting times are currently caused by dividing a number with very small number (but no where near enough floating point problem areas).

In this:

Code: [Select]

(pss->trigger.end_angle.a1d[a] - pss->trigger.current_ang.a1d[a])
/ (pss->trigger.current_vel.a1d[a] * direction)If you manage to swap the animation direction swiftly enough (ie. say with 3 weapon bank ship with animated bank being the 3rd.. swapping for example like linked - 1 - 2 - 3). Then the difference between end_angle and current_angle is still reasonably high. Now the swift weapon swapping will then cause the code to do that math when the current_vel hasn't yet sped up to the set animation speed so it can be very close to a zero (technically, it could be zero, but given its a float its extremely unlikely to happen).