Specific FrameIndex order required for multimodel animation

These bugs do plan to be resolved, when they can be.

Moderator: GZDoom Developers

Specific FrameIndex order required for multimodel animation

Postby Xeotroid » Fri May 20, 2022 8:58 pm

I'm not sure if this is actually a bug or an undocumented MODELDEF limitation, but here goes:
When specifying multiple model files in one Model block and using them both for animation, if the animation frames are specified for one model first entirely, then for another model entirely, only the latter model is actually animated. The FrameIndex lines have to be specified consecutively for each sprite frame instead.
For instance, this makes only the Model 1 actually be animated, Model 0 stays still, stuck on the first frame. If instead Model 1's frames are listed first, then Model 0's, only Model 0 is animated.
Code: Select allExpand view
Model MultiBroken {
   Model 0 "zero.md3"
   Model 1 "one.md3"   
   FrameIndex BLAH A 0 0
   FrameIndex BLAH B 0 1
   FrameIndex BLAH C 0 2
   FrameIndex BLAH D 0 3
   FrameIndex BLAH A 1 0
   FrameIndex BLAH B 1 1
   FrameIndex BLAH C 1 2
   FrameIndex BLAH D 1 3
}

To animate both models properly, it is necessary to "interweave" the FrameIndex lines like this:
Code: Select allExpand view
Model MultiWorking {
   Model 0 "zero.md3"
   Model 1 "one.md3"   
   FrameIndex BLAH A 0 0
   FrameIndex BLAH A 1 0
   FrameIndex BLAH B 0 1
   FrameIndex BLAH B 1 1
   FrameIndex BLAH C 0 2
   FrameIndex BLAH C 1 2
   FrameIndex BLAH D 0 3
   FrameIndex BLAH D 1 3
}

As far as I can tell, the order doesn't matter here. Also I haven't tried this out with Frame as I don't use MD2s. I've attempted to instead specify two Model blocks with the same name, one containing the first model, the other containing the other model, a little bit what the multi-texture example looks like on the wiki. However, only the latter defined model then shows up in-game at all.

Attached is a file that has two models used in three model definitions, two function improperly, one functions properly, and they can be viewed in an example map.
You do not have the required permissions to view the files attached to this post.
User avatar
Xeotroid
 
Joined: 23 Jun 2012
Location: Czech Rep.
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Specific FrameIndex order required for multimodel animat

Postby Cherno » Sat May 21, 2022 12:59 am

This is normal behavior. With multiple models, you are supposed to "interweave" the FrameIndex lines for all models. If one model should be not render for a particular frame, give it a frame index of -1.
User avatar
Cherno
 
Joined: 06 Dec 2016

Re: Specific FrameIndex order required for multimodel animat

Postby Xeotroid » Sat May 21, 2022 11:22 am

This should probably be noted on the MODELDEF wiki page, then. When using two models with the same frame numbers, it's not really a big issue, but when combining two models with different frame ranges, at that point it's easier to create a script that takes two text files and outputs the correct tangled up file. Though, when dealing with longer animations or multiple models, it's better to have some automated solution anyway instead of typing stuff out manually.
Would this be better suited as a feature suggestion, or would the way MODELDEF is parsed make this addition not worth the hassle to implement?
User avatar
Xeotroid
 
Joined: 23 Jun 2012
Location: Czech Rep.
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: Specific FrameIndex order required for multimodel animat

Postby Graf Zahl » Mon May 23, 2022 3:38 am

This is surely not intended behavior - but the entire model interpolation code was taken from Skulltag a long time ago and has several design issues. It is also something I'd rather not touch if it can be avoided...
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany


Return to On Hold Bugs

Who is online

Users browsing this forum: No registered users and 0 guests