Sorry your browser is not supported!

I was trying to do a quick animation based on one of the static helicopter models that ships with DBC - nothing fancy, just spin the pentagon that represented the rotor blades. However, as the blades reached an angle of about 180°, in order to each an angle of 181° they suddenly swept back through 0 and then down from 359 to 181. The animation then proceeded to rotate from 181 to 350, where my animation ended.

Trying this again with the knight model from DarkMATTER (another model I'd been working with), I set about rotating the knight's waste through 360°. Here's my code:




You'll have to modify the first line so you can load the knight. The same thing happens - the knight's torso sweeps around through the first 180° and then spins round backwards, passing through 0 to arrive at the 181° mark before changing direction again and spinning back round from 180° to 350°, completing the animation.

All that's in DBC 1.20. Now, when I first downloaded the updater, I made a point of keeping DBC 1.13. I tried seeing what would happen in this older version, and the knight's torso just spun round in a smooth circle - there was no sudden reverse of direction to bring the torso past 180°.

I'm not sure if this is an "error" in DBC 1.20, or if it's supposed to be like that. Does anyone know what's going on here?

I'm glad you brought this up. I was working on an animator as well in 1.20 and I loaded a model that I had converted from the software program Anim8or to directx with animation. In 1.13 it animates as I expect, in 1.20 the limbs jump around. I think it has to do with the rotation problem you are mentioning.

In my DBC animator, I was using Limb Direction() to return the world angle of the limbs. If I use an increasing angle say the x angle, it goes up to 90 then cycles down then jumps to 360, cycles down to 270 then back up to 360. This happens both in 1.13 and 1.20 . The trick now is to find out how this information is useful. It would seem that the angle < 180 is being calculated as 90*cos(90-ang) , and greater than 180 is being calculated as 360-(90*cos(90-ang)) . So, in theory, we need a formula to compensate for the correct angle that should be set up in the key. It may mean getting close to 90 degrees and then setting a single increment between keyframes to cross over to the higher values.


[EDIT]
I just thought of something, a directx file's mesh rotation data is stored as quaternion key frames. Even though the rotation of a limb doesn't seem to behave properly when you set the keyframe and then play or loop the animation directly in DBC, when you save the animation it may store the quaternions properly so that the animation plays correctly if you load back in that animation. I haven't tested this so I may do so after I finish typing this.

And if it is still wrong, then perhaps a custom rotation key function that outputs the rotation information as a proper quaternion will have to be written.

Hi, Latch!

I don't think it's the quarternion keyframes (whatever they are - I'm not that advanced with Maths) that are giving the problem. I used Lightning Limbs to export an animated .x file of the helicopter I'd originally worked on - I've attached it to this post. When I ran this code in GDK:



the rotors spun round smoothly, as expected. But loading the model into DBC 1.20 and I got the same problem as before:



So I think it's safe to say that it's something to do with how 1.20 does the rotation. I've found that it is possible to get an almost perfectly smooth circle spin, by specifying 360 keyframes - one for for each angle in the circle:



but for some reason there's a small discrepency when it hits frame 119 (as near as I can tell). The Limb directions go
118.4
47.1068
120

I've no idea why this should be - DB appears to be calculating the Cosine correctly, so it may be something to do with the model.



I would agree with that, except for the little discrepency that creeps in with 119. I'm not sure how to go about compensating for this, though. Perhaps it would be better/easier to do the animation manually - place the keyframe data in a file, and have the program calculate the amount each limb must rotate each frame to meet the specified angle at the next keyframe. At least this code snippet works smoothly:

[original response]
If you've already saved the animation from 1.20 and added it to the end of the directx file and it works in GDK then you've proved it's not that.

[edited response]
I wasn't satisfied with the behaviour of the key frame rotation and something in the back of my head said it had to do with the transform matrix (not a grid but matrix math) that DBC 1.20 is using to calculate keyframe rotations. This means that the quaternion rotation keys that DBC 1.20 is saving may be in error if the matrix transform used is off. To test this, I did a comparison of a set of rotation keys I had for a turret that just happened to be the same number of keyframes and angles as your helicopter blade rotation. What I found is that the rotations above a certain angle were opposite in the helicopter animation versus the turret animation. I'm assuming the rotations are in increments of 90 degrees (I didn't calculate it out and I don't remember what the turret's was though 4 keys on a loop suggests 90)

So, I modified the rotation keys in the helicopter with opposite signs and the rotation seems to work for a full 360. Here's the old prop rotation keys:



and here's the modified key with rotations above 90 with reversed signs. It could be because it's going beyond 120 (which seems to be the golden number in DBC 1.20) but in any case:



So, what does this mean? It suggests that the error in DBC 1.20 lies within the matrix used to output key frames. There's probably a negative sign in the C++ code or a sin and cos are reversed somewhere. When you create an animation in 1.20, you are getting the bad rotation keys so just playing it goes screwy; and then, when you save the animation, it is saved with the bad keys (in the case of the rotations, bad quaternions). As far as the other transoformations, scale and offset, I don't know if there are more problems - (again assuming the matrix used in the 1.20 engine isn't quite right)

I've included a modifed version of your copter X file that rotates properly both in 1.13 and 1.20. So why was the original rotation ok in 1.13 and the modified animation ok in 1.20 and 1.13? Well, I can only speculate because I don't know the code in the engine - and my fix is all based on assumtions. What I suspect is that the angles are really calculated based on 0 to 360 and -360 to 0. In DBC 1.13, there was probably an algorithm that looked at the interpolation between keys and if it was less than a certain amount, the angle was calculated to be in the + direction, and if the interpolation was greater than a certain amount, the angle was calculated to be in - direction.

That's probably why 120 degrees is significant - in DBC 1.20 I would guess that the interpolation is calculating from the first key or 0 degrees instead of the key before the rotation goes to 120. If 120 is where DarkBASIC is thing the value of the angle is too great to be in the positve direction, it is considered to be negativ, that angle caclulated would always be in the negative direction - thus the reversal of the rotation at that point. So, there might be a bug or a typo that never looks to the key before 120 degrees and always calculates it from 0.

Anyway, the only way I can think to fix it is to set up the animation keys, save that animation data, open the animation file, and reverse the signs on the keys that represnt rotations at or above 120 (again, I'm making some assumptions). I'll test it out over the next few days and I recommend you do the same. Let me know what you find out.

Hi Latch! I was running several tests yesterday, and a few more today based on what you'd said.

I don't think that DBC 1.20 is saving animation data incorrectly - I've been running Lightning Limbs in 1.20, and the animations I've been saving out with it run fine in 1.13 and GDK but don't work in 1.20 itself. But adding the - signs as you suggested makes the animation work in 1.13, 1.20 and GDK. So I think the error merely lies in DBC's playing of the object, rather than anything else - though why the change in signs doesn't affect the animation in other programs is a mystery to me.

120 does seem to be the golden number - I've found that if I set these keyframes:

the limb will spin to 119 before flipping back round through 0 to reach 180. But change the 119 to 120, and the limb will only spin round to 90 before flipping back through 0, through 180 and then to 120. I can't quite explain why 120 should be such an important number, but I was thinking the reverse of direction as the limb hits 90 might be explained in terms of the sin curve.

It was your two equations that set me onto it, as I realised that Cos(90-x) = Sin(x). Also, when I looked at the animation data I saw the line "90 ; 4; 0.707107, 0.000000, -0.707107, 0.000000;;," and 0.707107 is a special number, Sin(45). But Sin(45) = Sin(135), so when I'm faced with 0.707107 I have no way of knowing which angle it should actually be. For any given value, ArcSin will only return a number between 0 and 90, and so DB will never produce an angle that rotates the limb between 90 and 180. Instead, it will spin the limb in the other direction and move 3 times faster to arrive at the correct location in time for the next keyframe.

It wouldn't surprise me if I was totally wrong on all this, but I'm afraid it's the best guess I've got. The limit of 120 might be due, as you suggested, to the way the interpolation is calculated. Certainly the presence of a keyframe between 90 and 120 can force the limb to keep rotating in the right direction before flipping back - maybe the typo in the c++ code was that 120 should read 180, as (I'm guessing) the limb rotation would then be subject to the maths that controls the rotation through 180..360 and that clearly works.


I don't think it would have been in DB 1.13 itself, rather the d3d dll. According to one of the files I got about the .x file format ages ago, the animation templates are used by the Direct3d Retained Mode, but support for that was removed from DB 1.20 because the dll wasn't always present on the newer operating systems. Perhaps the error crept in when DBC 1.20 was being programmed to take over the dll's commands?


[Edit]
Just been doing another test, Latch, and I've got some bad news - your fix works fine but only if there is rotation about just 1 axis. Add in a second axis, with 360 rotation, and your fix gets the animation working fine, but "flipped", so to speak. I've attached a Knight with animation I set up in DB 1.20 (pulled out the low-res one by mistake, so the Chest is Limb 2). 5 keyframes were set:

But if you invert the signs as you suggested, the animation becomes quite different, I think like a mirror image of the original.