Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Wanderer on February 03, 2010, 04:38:20 am

Title: Animation Code woes
Post by: Wanderer on February 03, 2010, 04:38:20 am
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.
Title: Re: Animation Code woes
Post by: Goober5000 on February 03, 2010, 10:52:26 am
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?
Title: Re: Animation Code woes
Post by: The E on February 03, 2010, 10:57:57 am
http://scp.indiegames.us/mantis/view.php?id=2109
Title: Re: Animation Code woes
Post by: Wanderer on February 03, 2010, 11:45:36 am
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.
Title: Re: Animation Code woes
Post by: Bobboau on February 03, 2010, 11:55:41 am
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.
Title: Re: Animation Code woes
Post by: Fury on February 03, 2010, 12:49:59 pm
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
Title: Re: Animation Code woes
Post by: Nuke on February 03, 2010, 02:20:59 pm
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.
Title: Re: Animation Code woes
Post by: Wanderer on February 03, 2010, 03:05:39 pm
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...
Title: Re: Animation Code woes
Post by: chief1983 on February 03, 2010, 05:24:47 pm
This is probably the best thing to ever come from Jaws 3.
Title: Re: Animation Code woes
Post by: Zacam on February 03, 2010, 05:38:17 pm
This is probably the best thing to ever come from Jaws 3.

Amen.
Title: Re: Animation Code woes
Post by: Bobboau on February 04, 2010, 10:11:58 am
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
Title: Re: Animation Code woes
Post by: The E on February 04, 2010, 10:20:42 am
Those models are the same ones where the issue manifested itself while we were working on WiH.
Title: Re: Animation Code woes
Post by: Bobboau on February 06, 2010, 11:26:33 pm
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"
Title: Re: Animation Code woes
Post by: Fury on February 15, 2010, 07:07:15 am
Any progress on this?
Title: Re: Animation Code woes
Post by: Bobboau on February 15, 2010, 11:50:43 am
I never got an answer back on my question, and I haven't got my development environment set up yet.
Title: Re: Animation Code woes
Post by: Fury on February 15, 2010, 11:52:00 am
What question?
Title: Re: Animation Code woes
Post by: chief1983 on February 15, 2010, 12:39:23 pm
how low is "very low"

Looks like that one, but I'm not even sure what it refers to.  The delay errors or something?
Title: Re: Animation Code woes
Post by: Fury on February 15, 2010, 12:45:40 pm
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.
Title: Re: Animation Code woes
Post by: Nuke on February 15, 2010, 03:06:50 pm
i think he wanted a model to test against. i myself noticed a change in animation code behavior doing my sliding door model demonstration (http://www.hard-light.net/forums/index.php?topic=67769.msg1338831#msg1338831). 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.
Title: Re: Animation Code woes
Post by: Wanderer on February 16, 2010, 03:51:25 am
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).
Title: Re: Animation Code woes
Post by: Bobboau on February 18, 2010, 01:52:55 am
could it be that it's just not taking into account the case that the animation is still in the speeding up phase? if this is the case I can probably fix it easily. I can probably get it fixed the day after tomorrow if that's what it is, although I'm not sure that's what it is.
Title: Re: Animation Code woes
Post by: Fury on February 25, 2010, 12:43:09 am
Still nothing? :(
Title: Re: Animation Code woes
Post by: Fury on March 26, 2010, 03:46:29 am
 :bump:
Title: Re: Animation Code woes
Post by: Bobboau on March 26, 2010, 10:47:31 am
I actually have some free time this weekend.
Title: Re: Animation Code woes
Post by: Fury on April 20, 2010, 07:36:04 am
 :bump:
Title: Re: Animation Code woes
Post by: Bobboau on April 23, 2010, 09:58:07 pm
I'm such a horrible person...:(
I honestly haven't been able to do any recreational coding for the last few months, honestly I haven't done much of it since I started going to the school I'm about to graduate from, May 7th is my last exam, ever, maybe I can get to it then? it's not like the old days when I had freespace and a development environment all primed to go on a moments notice, I have a hard time just getting FSO's code.
Title: Re: Animation Code woes
Post by: Nuke on April 26, 2010, 11:22:27 pm
ive been kinda keeping a loose eye on the system and kinda fixing bugs as i found them. of course the system needs a partial overhaul for sanity reasons (see other animation code thread) and new features/triggers. setting the $type: to any type not directly hardcoded should be acceptable (i think this works already), since any type can be triggered by scripting. also the scripting trigger is probably unnecessary because script can call any trigger by name. maybe also add a sexp with the same functionality of the scripting functions. implement linked animations! i believe they were part of the original plan for the animation system. aside from a -1 to 1 value to link them to, they really only need 3 values: rotation amount, rotation offset, and smoothing. then make it possible to animate subobjects in the cockpit model. thats about all i want.
Title: Re: Animation Code woes
Post by: Spoon on April 27, 2010, 05:24:32 am
I just want better, more versatile animation system.
The 'Turret firing' trigger actually working would be a start  :p
Title: Re: Animation Code woes
Post by: Nuke on May 01, 2010, 07:10:47 am
i did notice a couple things. one i believe i fixed was that the sub-object had to have hit points to animate, i found this annoying since you might want to have a non-destructible animation object. you may have also needed to set an object speed (not sure about this one). and finally you had to edit your model and add +triggered: to the sub-object that you wanted to animate. that last one is easy to miss, not obvious at all, poorly documented, and worst of all, its not reported to the modder in the debug builds. if possible i think the requirement of the subobject property should be removed if it doesnt serve any major purpose.
Title: Re: Animation Code woes
Post by: QuantumDelta on May 12, 2010, 01:43:45 pm
How's this issue coming along? I can see it being a potential game stopper (or AWESOME feature being removed for the BP guys) for WiH atm for quite a lot of pilots :<
Title: Re: Animation Code woes
Post by: Fury on May 12, 2010, 03:30:14 pm
Honestly, animation code is being more trouble than it is worth. When you get something to work, it only works half the time on good day.

Someone really should fix this.
Title: Re: Animation Code woes
Post by: Goober5000 on May 12, 2010, 09:32:17 pm
The animation code, unfortunately, is one of a long line of FSO features that were abandoned before completion.  I sometimes wonder if we should start ripping those sorts of features out.
Title: Re: Animation Code woes
Post by: The E on May 12, 2010, 09:37:24 pm
In this case, that might be a good idea. As it is implemented, it's too full of weird stuff that borders on black magic (For example, the turret firing trigger).

A new implementation, one that not only does rotation but also translation and that is better controllable (using, for example, the embedded scripting thing I proposed here (http://www.hard-light.net/forums/index.php?topic=69345.0)) would be good.
Title: Re: Animation Code woes
Post by: chief1983 on May 12, 2010, 10:00:50 pm
There's no working support for translation whatsoever in the engine yet, so that would be kind of difficult.  At least rotation already model and collision support.
Title: Re: Animation Code woes
Post by: Trivial Psychic on May 12, 2010, 10:08:56 pm
There is a way to simulate translations, by using two invisible, non-collidable submodels, configured a bit like an arm with an elbow joint.  You'd have to control 3 rotation points... one at the "elbow" where the two invisible submodels contact each other, and one where where each contacts the main model.  All three would need to be timed to trigger at the same time.
Title: Re: Animation Code woes
Post by: Goober5000 on May 12, 2010, 11:05:37 pm
There's no working support for translation whatsoever in the engine yet, so that would be kind of difficult.  At least rotation already model and collision support.
The model and collision code already needs to be rewritten.  If someone is doing that, translation support could be added at the same time.
Title: Re: Animation Code woes
Post by: Spoon on May 13, 2010, 04:39:09 am
The animation code, unfortunately, is one of a long line of FSO features that were abandoned before completion.  I sometimes wonder if we should start ripping those sorts of features out.
Considering the fair amount of capital ships that have an initial turret rotation setting I'd say, please no. Not to mention the ships that have triggers on afterburners.
While limited, at least *some* parts of the current animation code works.
Of course, I'd have no complaints if it were to get a proper replacement or something.
Title: Re: Animation Code woes
Post by: Vasudan Admiral on May 13, 2010, 09:15:14 am
Agreed - ripping out the animation code without replacement would be an awful idea! It may not be as bug free or even as functional as it should be, but it does mostly work - and the flexability it offers ship builders even in its current state is amazing.
Title: Re: Animation Code woes
Post by: chief1983 on May 13, 2010, 10:29:16 am
Is there proper documentation then on what currently does work (and what was intended to work)?  Without that it could prove difficult to rewrite a replacement.
Title: Re: Animation Code woes
Post by: Goober5000 on May 13, 2010, 11:17:15 pm
Unlikely.  It was Bobboau's baby, and any changes made by other people were merely bugfixes and feature patches.
Title: Re: Animation Code woes
Post by: Nuke on May 15, 2010, 06:54:39 pm
i think most if not all of the animation triggers could be done with scripting anyway. though im kind of concerned that there would be collision detection issues. up till now i had only used scripted animations on non-collideable objects, such as cockpit interior. attempts to use the same thing on large collideable objects may pose an issue. essentially we need a way to change the orientation of a subobject from scripting without messing up collision detection.

There is a way to simulate translations, by using two invisible, non-collidable submodels, configured a bit like an arm with an elbow joint.  You'd have to control 3 rotation points... one at the "elbow" where the two invisible submodels contact each other, and one where where each contacts the main model.  All three would need to be timed to trigger at the same time.

ive tried that and it seriously messes with collision detection (especially while the object is animating).
Title: Re: Animation Code woes
Post by: FUBAR-BDHR on May 15, 2010, 08:43:42 pm
When you tried it was it with subobjects that were always withing the bounding box of one of the detail levels (detail0, detial1, etc)?  If at anytime during the rotation a subobject moves outside that box it may loose collision detection.  Kind of a keep all hands and feet inside during the ride.
Title: Re: Animation Code woes
Post by: Nuke on May 16, 2010, 09:15:21 pm
thats about where it screws up. there is currently no way to fix the model bounding boxes without several very dirty model hacks (fantom objects, ect). its one of the many reasons i want to see in-model subobjects, subsystems and turrets replaced with external models, so they can be transformed, rendered, collided, and loded entirely independant of its parent (and fixing a long list of problems with the way subobjects are handled). of course that still doesnt fix the actual problem, i merely works around it.

were trying to use 2010 polycounts with a 1998 model format and 1998 collision detection code, and thats the real issue. turrets in retail were noting more than decorated 12 poly cubes and were trying to use that same system with 400 poly turrets with holes and sobobjects that can be rotated on a modders whim. many clever modders have come up with workarounds to fix some collision issues, but i consider these interim solutions. they just trick the engine into thinking an object is bigger than it actually is. this only causes the engine to dive into the collision code in places it doesnt need to. what we need is smarter collision code.
Title: Re: Animation Code woes
Post by: Wanderer on May 30, 2010, 03:48:06 pm
Please check if my patch helped with the problems. Also it would be nice if people reported if it broke something...
Title: Re: Animation Code woes
Post by: Aardwolf on May 31, 2010, 02:33:29 pm
Please check if my patch helped with the problems. Also it would be nice if people reported if it broke something...

Nice and bad at the same time, you mean.