Model definition format

[Nash]

I kind of don't quite get how the models would work.

Does that mean for every state, I would have to provide a separate model file? That's plenty of files, if you ask me...

How would animations work, then?

[Graf Zahl]

No, you don't need a separate model file for each state. You have to assign frames from the model file to each state.

[solarsnowfall]

Hmm, my modeling knowledge is limited to cinematics. Can any one refer me to some tutorials for propper usage of the mdl2 format?

[ellmo]

Yeah... I would be grateful for that as well. Like how to convert a default GMax / 3DS Max model into an MDL2?

[DaniJ]

The way you must set per-frame parameters in this syntax is horibble, it would be a huge pain in the ass and seriously bloat the definition.

You've not made prevision for the sub-model files to change on a per-frame/per-inter basis. This is used extensively.

Submodel scale is relative to the model scale, not absolute.

[Graf Zahl]

Could you please be a little more detailed?

I just put the file together based on the .DED file for the Arachnotron. Did I miss something?`Please keep in mind that this is the first time I am working with models in a Doom engiine.

[DaniJ]

The syntax you have here simply won't work and looses most of Doomsdays fexibility.

I don't really have the time atm to explain all the problems with it. Could you take a look at the DED reference HERE and examine exactly how it works more thoroughly. It would take a LOT of explaining.

The main problem is the way you have a block of values at the top, Doomsday doesn't use that format (Vavoom does) because its extremely limiting:

Code: Select all

   Model 0, "spider_platform.dmd"
   Model 1, "spider_brain_left.dmd"
   Model 2, "spider_brain_right.dmd"
   Model 3, "arachnotron_death.dmd"
   Scale 0, 1.4, 1.2, 1.4
   Scale 1, 1.4, 1.2, 1.4
   Scale 2, 1.4, 1.2, 1.4
   Scale 3, 1.4, 1.2, 1.4

These should be modifiable at any point in the frame sequence, even inter marks. They arn't global model values in the way THING variables (like height, mass etc) are, infact there are very few global model variables. All the values are interpolated between frames also (where applicable). This even applys to flags, which at the mid point between two inter marks will change.

Also the values of the parameters can be inherited between frames using the "Copy" directive. The logic is that if "Copy" is found before a model frame definition then ALL the parameters are copied. The great thing about that is that it means you can selectively copy stuff to certain frames from the previously defined one (obviously the order of definitions plays a big part). For example:

Code: Select all

Model
{
   Scale { 1 1 1 }
   State = "attack01"
   Sub{
       File = "arachnotron/brain.dmd"
       Flags = brightshadow
       Frame = "attack01"
   }
   ...blah
}

Copy Model
{ # Parameters are inherited from previous definition
   State = "attack03"
   Sub{
       Frame = "attack02"
   }
}

Model
{
   # NONE of the parameters are inherited from the previous def
   State = "attack02"
   Sub{
       File = "arachnotron/brain2.dmd"
       Frame = "attack02"
   }
}

Copy Model
{
   # Parameters are inherited from previous definition
   # Sub model 1 uses a different model file but all the sub model parameters are inherited
   # Sub model 2 only appears in this frame and none
   # of the values can be inherited because it wasn't in the previous one
   State = "death01"
   Sub{
      File = "arachnotron/brainexplode.dmd"
      Flags = alignyaw                               # This flag is NOT in addition to the
                                                     # brightshadow flag defined earlier.
      Frame = "squish1"
   }
   Sub{
      File = "arachnotron/splat.dmd"
      Frame = "squish1"
   }
}

Another problem is that even global model parameters can be altered by individual sub models eg:

Code: Select all

Model
{
   Flags = alignyaw | alignpitch | brightshadow
   Sub{
       Flags = brightshadow
   }
   Sub{
   }
}

Both sub models inherit all the global model flags except sub model 0 which does NOT inherit brightshadow.

To be honest I doubt if its possible to condense it the way you are attempting to, without losing functionality or making the syntax even more incomprehensible.

There is really only one problem with Doomsdays current model def syntax and that is to do with world-time animation when a THING has more than one state. More about that as an when you get to that point.

[Graf Zahl]

Don't expect me to support anything Doomsday can from the start. I have to get this running first so I'll restrict my first version to the simple and more common cases (and no interpolation) so I can go on from there. That means no flag changes and so on until later.

Once I got something I can expand things hopefully will become easier.

[Nash]

I really can't wait for this feature.

Do you have an estimate on when will it be working?

[Graf Zahl]

No. When I find some motivation to work on the code longer than a few minutes maybe.

[justin023]

Seems really over complicated. For now i'll stick to converting models to sprites, but a future project with models could be cool. What kinds of models would this support? Hopefully quake, quake2, and half-life.

[Manc]

Seems really over complicated. For now i'll stick to converting models to sprites, but a future project with models could be cool. What kinds of models would this support? Hopefully quake, quake2, and half-life.

Each one of those games has different and old formats. Quake uses MDL, HL uses an enhanced MDL with bone rigging, Quake2 uses MD2. IF this is all that graf can handle then fine, but if anything md2 should be used at the very least. It'd be really nice to see md3 (which q3 uses) but it'll mean more work of course. MD2 does lend itself well to doom because it has animation states that can act as a good link to the doom frameset system.

[justin023]

The one I would like to see the most is half-life.

[Chilvence]

Holy crap, I would have never expected this to happen...

I remember last time I gave this subject some serious thought, I was into the idea of seriously loosening the ties between sprite states and model frames. To be more clear, I think it would be much more productive to define animation loops in the model seperately, and then key them to start at specific places in the frame state table.

for example

[spoiler]

Code: Select all

animation arachnotron/walk
{
	model 1 { file=brains.md2 frame=walk01 texture=muckygoo.jpg }
	model 2 { file=legs.md2 frame=walk01 texture=shinylegs.png }
	tics 3 <wait this number of tics then process the next block>
	model 1 { <changes from the last frame here }
	model 2 { <etc> }	
	spawn vomit <support for model specific extras like particles and lights>
	tics 3
	....
}

animation arachnotron/fire
{

}

trigger arachnotron [ <- actor class name ]
{

	state see
	{
		arachnotron/walk
		loop=yes [example property, loop model animation independently of sprite]
	}
	state missile
	{
		arachnotron/fire
	}
	state missile+2
	{
		<support for changing the model sequence mid-stride - primarily useful for bosses with multiple attacks>
	}
}

[/spoiler]

The idea being its alot more flexible and simpler to set up - the animation blocks could be extended to do a variety of things, like trigger particle effects, flashes of light, switch models halfway etc - not all of it is of intrest to GZDoom, of course, but I still think this way is simpler. Rather than having to mess with a million and 1 interpolation values, the model frames could just be defined with tics, or even better, milliseconds, and you'd still get the benefits of smoother model animation.

I would really hate for a new model definition format to be loosely based - or even slightly similar to - Doomsdays method, because deep down I hate it lots and lots.

edit: expanded example

BTW Manc, I don't really think that MD3 when used in its simplest form has that much more over MD2 - if you were to initially skip support for using tags, multiple surface textures and whatnot, you've essentially got MD2 with much improved vertice precision - something that is drastically needed. Not to mention lots more tools are MD3 friendly.

What would be really nice though would be to skip all that crap and go with an industry standard, general purpose format. Support for proprietery game formats in modeling programs comes and goes, it would be nice to have something more stable.. er.. staple

[Graf Zahl]

Holy crap, I would have never expected this to happen...

I remember last time I gave this subject some serious thought, I was into the idea of seriously loosening the ties between sprite states and model frames. To be more clear, I think it would be much more productive to define animation loops in the model seperately, and then key them to start at specific places in the frame state table.

That would work for simple monsters but as soon as complex DECORATE constructions come into play it'd fail completely. Such a simple definition format can't handle all that is needed. If you can solve that I'd appreciate it.

I would really hate for a new model definition format to be loosely based - or even slightly similar to - Doomsdays method, because deep down I hate it lots and lots.

Guess why this hasn't progressed any further so far. I don't like it either because it creates really bloated and hard to maintain definition files. Doomsday 'solves' this by giving each state a name but that's not an option for me.

What would be really nice though would be to skip all that crap and go with an industry standard, general purpose format. Support for proprietery game formats in modeling programs comes and goes, it would be nice to have something more stable.. er.. staple

Industry standards are nice - but I need to have some models - and currently they only exist as MD2/DMD's.