Quote:Original post by Amadeus
Although if you only have a single track it won't matter (or at least won't see the problem), but to be completely accurate your Blend method would need to know the totalWeight before using the current tracks weight in the division. Adding it up as you go changes the ratio each time a new tracks weight is added.

Interestingly, all you've said in the above citation is correct, but your conclusion of incorrectness of the method is wrong (I must assume that your intention was to hint at an incorrectness of the method). It is definitely intention that the totalWeight increases with each additional blending. Because I'm too lazy to write the proof down again, please look at the 3rd page of this thread into my post where I explain the method in great detail, beginning with "So far you need the a-priori knowledge of all weights to work".

Quote:Original post by Amadeus
Also in your test code it appears you add two key values at time 0 and 1 (or 1 nd 2 - depending on the post), yet you increase the time value by using time++ which increments by 1 each time, skipping in between float values of time (try testing with keys at times 0 and 2 if you want to keep it like this).

It's also probably best to ensure keys are within some valid time range regardless of the time passed, and disregard animations by some other means - use curr->value if time < curr->time, use next->value if time > next->time, depends on your needs I guess.

*** Source Snippet Removed ***

The animation system is intended to be open. One issue is to break the need for simultaneous keyframes in all tracks of an animation. Another is to allow single tracks to have their own behaviour (e.g. off range handling). Animations and their belonging tracks have a defined start, but their end may be open (i.e. the end may be determined at runtime, or may last until the end of the gameplay; notice that this animation system is not restricted to drive character animation, and mechanical devices may for sure have an endless animation w.r.t. the gameplay). If e.g. jumping/cycling is allowed, the tracks will furthur need to deal with their own local time. Considering all this, each track has to deal with a "valid time range" by its own, but finding a valid time range on the animation level w.r.t. track blending seems me senseless. As stated in my post above, a settings dependent search for the valid keyframes, integrated into the Interpolate(...) routine will solve the problem.

Quote:Original post by Amadeus
Be mindful of any inaccuracies - treat more as a pseudo-code suggestion - depending on how you choose to handle things you may always want the true current and previous/next keys instead of them being the same key when the time is out of range.

Yes, it is senseful to distinguish the different off range situations.