Md3 model animation help

juizzysquirt · Post by **juizzysquirt** » Fri Oct 23, 2020 12:43 am

I'm having problems achieving smooth rotation for cylinders or other round objects with interpolation, models seems to "pulsate" between some of the frames. I get that things get wonky if using only two frames, but even 5 frames for rotating round object 180-degrees back and forth should be enough? Problem persists even with large amount of frames, albeit less noticeable.

I'm using Maverick Model 3d and I'm not that experienced with animations overall, but everything seems proper in editor. In this example of rotating donut I've got 2 identical models with 5 frames for 180-degree rotation, and one with 13 frames. The difference between first two is using less frames in decorate which seems to amplify the wobbling. Does it have something to do with keyframes, are the frames assigned with modeldef actually keyframes and it requires some non-keyframes in between?

I would greatly appreciate any advice. Just summon donut1, donut2 and donut3 to see what I'm talking about.

Decorate:

Spoiler:

Modeldef:

Spoiler:

Post by **Enjay** » Fri Oct 23, 2020 6:42 am

If I am trying to do a rotation in Maverick, I press shift while creating the rotation (in a frames-type animation). This makes the rotation "leap" by predetermined amounts. I think it is 6 leaps per 90 degrees (24 for a full rotation). That kind of increment is usually good enough for me, but sometimes I need to stick in an extra angle between the presets, and that has to be done by eye I think.

However, if you just want your model to sit and rotate constantly (and I know that's not what your donuts are doing, so maybe you don't) then I wouldn't bother animating it at all. I'd use the built-in GZDoom ability (via modeldef) to rotate the model. Although most of the time, people use this ability just to have a model rotate around the vertical axis, it can be set differently with a few modeldef parameters and it will give a nice smooth rotation.

In saying that, your donut3 looks pretty decent to me.

Anyway, try the attached. Summon donut4. It's just a quick shonky mockup where I moved the donut model down so that its origin is bang in the middle and set the actor to have NOGRAVITY. The reason for doing that was just so that you can spawn one in the air (jump up before opening the console, or use the fly command at the console) and see it rotate. In an actual example, you can set where the rotation centre is using modeldef (there are quite a few parameters that deal with tailoring rotation). This does not use any in-model animation (in fact, I removed the animation frames). It's just using GZDoom's built-in rotation.

Also note that I set the final scale parameter to be 1.2 times the others in modeldef. This takes account of the fact that Doom has a 1:1.2 pixel ratio. Without this, the model would look distorted as it rotates.

juizzysquirt · Post by **juizzysquirt** » Fri Oct 23, 2020 12:58 pm

I'm actually trying to animate rotating door knob in a 3d door, so I need to control the animation rather precisely (and with only few frames if possible). But there's something strange about how rotations like this show up in GZdoom, I don't recall having any problems with normal enemy walking animations etc. I'm actually going to try if squishing the knob-object itself to 1:1.2 would fix this, though it wouldn't fix the real issue here.

Guest · Post by **Guest** » Fri Oct 29, 2021 2:02 am

Hey, sorry to bump this thread but I know what's going on. zdoom doesn't animate the full rotation, it morphes from one keyframe to the next as you define in DECORATE. So rotations are treated as morphs as every vertex moves in a direct line to its destination, causing a wheel to shrink as every opposite side moves in towards the center, then back out to its destination.

Anyway, to solve this, define much more points of rotation in DECORATE, and in modeldefs. this way the engine will be forced to "morph" the wheel turning.

EG: my car code in modeldefs:

Model hiluxBall
{
Path "MD\cars"
Model 0 "hilux.md3"
Skin 0 "hilux.png"
Scale 1.0 1.0 1.0

FrameIndex HILU A 0 1
FrameIndex HILU B 0 3
FrameIndex HILU C 0 5
FrameIndex HILU D 0 7
FrameIndex HILU E 0 9
FrameIndex HILU F 0 11
FrameIndex HILU G 0 13
FrameIndex HILU H 0 15
FrameIndex HILU I 0 17
FrameIndex HILU J 0 19
FrameIndex HILU K 0 21
FrameIndex HILU L 0 23
FrameIndex HILU M 0 25
FrameIndex HILU N 0 27
FrameIndex HILU O 0 29
}

The numbers above refer to frames 1 - 30, relating to 0 - 360 degrees rotation in Blender.
The more points of rotation you put in, the smoother and less "pulse-y" the rotation animation. Downside is code bloat.

ZDoom