Warcraft III resources & community, 2003–2006 · archived

Does anyone have experience with the MDL/MDX formats?

8 posts
#1

Does anyone have experience with the MDL/MDX formats?

I'm looking for some pointers on how geosets and geoset animations connects. It seems like there's a N:1 relation from geosetanims to geosets, though it seems correct in most cases there are exceptions.

As an example, look into battlestandard.mdl. There is one geoset and one geosetanimation (shouldn't be any doubt how they are connected, right?). The geoset animation have this alpha track:


Alpha 4 {
	DontInterp,
	7667: 0,
	7800: 1,
	9500: 1,
	9867: 0,
}


Thus everything after 9867 is 0 (invisible), right?

But looking at the sequences, two of them (stand-1 and stand-2 have the intervals { 16667, 19667 } and { 20333, 23333 }, which is way beyond 9867, thus always invisible, right? How does this work? The animations plays fine (is visible) in warcraft 3, but I just can't see the logic why they are visible! Shouldn't they have alpha = 0?[/code]
#2
Close, but not correct

GeosetAnims decide to go the opposite to what we'd think. 1 is invisible, 0 is visible
#3
Actually, 1 is visible, 0 is invisible. The problem here is that in warcraft each sequence considers only the keyframes within the interval; so the geoset's default visibility is 1, and when there is not keyframe changing this at the start of the sequence, it remains visible. So if "9867: 0," is the first frame of a sequence, the geoset becomes invisible for that sequence, until it hits the next key telling it to change. If a different sequence begins after, say at 10000, then the visibility will go back to default because alpha has not been defined within that sequence.

Sorry if that doesn't make any sense :S
#4
Your explanation makes perfect sense to me.

When visibility is specified, it is only for the animation containing the frame nr.
Everything else defaults to visible.
#5
Much appreciated, this may solve my problem!

Another follow-up question, if an animation loops do you know how the interpolation is handled when going from the end of the interval to the beginning? Is it a direct jump or is there a proper interpolation form the last node in the interval to the first? (tell me if that sentence makes no sence, or is confusing)
#6
Please continue your intelligent questions.
I want to make an animation program (in python), and I need all the info I can get to make it.
#7
The suggestion above worked 99.9% fine for visibility (for some reason some rare geosets, usually the corpse does not show up sometimes, but that's a minor problem currently).

However, for rotations I'm not as convinced. Consider DivineShieldTarget.mdl:

The animation Stand goes in the interval { 1967, 2667 }.

The surrounding rotation nodes are:

1625: { 0, 0, 0.413028, 0.910718 },
InTan { 0, 0, 0.407093, 0.913387 },
OutTan { 0, 0, 0.421408, 0.906871 },

2167: { 0, 0, 0.931646, 0.363368 },
InTan { 0, 0, 0.931646, 0.363368 },
OutTan { 0, 0, 0.931646, 0.363368 },

(no more)


The model rotates constantly, but if a default rotation value should be applied between 1625 and 1967 it won't rotate. I then assume that a default rotation value should be applied at 1967 and then all values inbetween be interpolated? But what about after 2167 to 2667?
#8
I have looked closely at it in the model viewer.
The rune-circle preforms a rotation of about 1/8, then back again.

So, the model viewer interprets the rotation instrucktions different from the game engine.

I think the issue is this:
The rotation are never reset. The bone do not remember its initial direction, each rotation are "added" to its direction.

Btw. does anyone know what the four values in rotation movements are? I know that the three values in the translation movement are the {x, y, z} values.