DRD Team

Posted: **Fri Oct 14, 2005 12:47**

I just spent some time trying to analyze the model definitions in the JDRP to see how much of it I might be able to use.

The bad news: The definitions are so closely tied to the way Doomsday defines its actors that I can't use it. I also don't like the definition format which IMO is quite non-intuitive.

All this means I have to define a completely new format from scratch. Here's my first attempt:

Code: Select all

MODEL Arachnotron
{
	Path "Monsters/Arachnotron"
	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

	States
	{
		Spawn
		{
			Frame 0, "attack1"
			Frame 1, "attack1"
			Frame 2, "attack1"
		}
		Spawn+1
		{
			Frame 0, "attack1"
			Frame 1, "attack1"
			Frame 2, "attack1"
		}
		
		Missile
		{
			Inter 0
			{
				Frame 0, "walk5_D"
				Frame 1, "walk5_D"
				Frame 2, "walk5_D"
			}
			Inter 0.1
			{
				Frame 0, "walk6_D"
				Frame 1, "walk6_D"
				Frame 2, "walk6_D"
			}
			Inter 0.2
			{
				Frame 0, "walk2_D"
				Frame 1, "walk2_D"
				Frame 2, "walk2_D"
			}
			Inter 0.3
			{
				Frame 0, "walk3_D"
				Frame 1, "walk3_D"
				Frame 2, "walk3_D"
			}
			Inter 0.4
			{
				Frame 0, "walk5_D"
				Frame 1, "walk5_D"
				Frame 2, "walk5_D"
			}
			Inter 0.5
			{
				Frame 0, "walk6_D"
				Frame 1, "walk6_D"
				Frame 2, "walk6_D"
			}
			Inter 0.6
			{
				Frame 0, "walk2_D"
				Frame 1, "walk2_D"
				Frame 2, "walk2_D"
			}
			Inter 0.7
			{
				Frame 0, "walk3_D"
				Frame 1, "walk3_D"
				Frame 2, "walk3_D"
			}
			Inter 0.8
			{
				Frame 0, "walk5_D"
				Frame 1, "walk5_D"
				Frame 2, "walk5_D"
			}
			Inter 0.9
			{
				Frame 0, "walk6_D"
				Frame 1, "walk6_D"
				Frame 2, "walk6_D"
			}
			Inter 0.99
			{
				Frame 0, "attack1"
				Frame 1, "attack1"
				Frame 2, "attack1"
			}
		}
		Missile+1
		{
			Frame 0, "attack1"
			Frame 1, "attack1"
			Frame 2, "attack1"
		}
		Missile+2
		{
			Frame 0, "attack2"
			Frame 1, "attack2"
			Frame 2, "attack2"
		}
		Missile+3
		{
			Frame 0, "attack1"
			Frame 1, "attack1"
			Frame 2, "attack1"
		}
		See
		{
			Frame 0, "attack_D30"
			Frame 1, "attack_D30"
			Frame 2, "attack_D30"
		}
		See+1
		{
			Frame 0, "walk1"
			Frame 1, "walk1"
			Frame 2, "walk1"
		}
		See+2
		{
			Frame 0, "walk2"
			Frame 1, "walk2"
			Frame 2, "walk2"
		}
		See+3
		{
			Frame 0, "walk3"
			Frame 1, "walk3"
			Frame 2, "walk3"
		}
		See+4
		{
			Frame 0, "walk4"
			Frame 1, "walk4"
			Frame 2, "walk4"
		}
		See+5
		{
			Frame 0, "walk5"
			Frame 1, "walk5"
			Frame 2, "walk5"
		}
		See+6
		{
			Frame 0, "walk6"
			Frame 1, "walk6"
			Frame 2, "walk6"
		}
		See+7
		{
			Frame 0, "walk1"
			Frame 1, "walk1"
			Frame 2, "walk1"
		}
		See+8
		{
			Frame 0, "walk2"
			Frame 1, "walk2"
			Frame 2, "walk2"
		}
		See+9
		{
			Frame 0, "walk3"
			Frame 1, "walk3"
			Frame 2, "walk3"
		}
		See+10
		{
			Frame 0, "walk4"
			Frame 1, "walk4"
			Frame 2, "walk4"
		}
		See+11
		{
			Frame 0, "walk5"
			Frame 1, "walk5"
			Frame 2, "walk5"
		}
		See+12
		{
			Frame 0, "walk6"
			Frame 1, "walk6"
			Frame 2, "walk6"
		}
		Pain
		{
			Frame 0, "pain1"
			Frame 1, "pain1"
			Frame 2, "pain1"
		}
		Pain+1
		{
			Frame 0, "pain1"
			Frame 1, "pain1"
			Frame 2, "pain1"
		}
		Death
		{
			Inter 0
			{
				Frame 3, "1"
			}
			Inter 0.2
			{
				Frame 3, "2"
			}
			Inter 0.4
			{
				Frame 3, "3"
			}
			Inter 0.6
			{
				Frame 3, "4"
			}
			Inter 0.8
			{
				Frame 3, "5"
			}
		}
		Death+1
		{
			Inter 0
			{
				Frame 3, "6"
			}
			Inter 0.5
			{
				Frame 3, "7"
			}
		}
		Death+2
		{
			Inter 0
			{
				Frame 3, "8"
			}
			Inter 0.5
			{
				Frame 3, "9"
			}
		}
		Death+3
		{
			Inter 0
			{
				Frame 3, "10"
			}
			Inter 0.5
			{
				Frame 3, "11"
			}
		}
		Death+4
		{
			Inter 0
			{
				Frame 3, "12"
			}
			Inter 0.5
			{
				Frame 3, "13"
			}
		}
		Death+5
		{
			Frame 3, "14"
		}
		Death+6
		{
			Frame 3, "15"
		}
		Raise
		{
			Frame 3, "13"
		}
		Raise+1
		{
			Frame 3, "12"
		}
		Raise+2
		{
			Frame 3, "11"
		}
		Raise+3
		{
			Frame 3, "7"
		}
		Raise+4
		{
			Frame 3, "5"
		}
		Raise+5
		{
			Frame 3, "3"
		}
		Raise+6
		{
			Frame 3, "2"
		}
	}		
}

Please post ypur opinions so that I can eliminate any potential problems before I start writing a parser for it.

Posted: **Fri Oct 14, 2005 12:54**

That seems pretty good to me, except one thing,

rather than the 'Model 0' then 'Scale 0' thing, why not do it more like this:

Code: Select all

Model 0
{
    name "model.md2"
    scale 1.4 1.2 1.4
    ...
}

That fits in a bit better with the format of the rest, plus it also makes things easier in case you decide to add more model properties (like environment maps, special effects etc).

Posted: **Fri Oct 14, 2005 13:46**

I thought that maybe it'd be useful to change the scale somewhere in between. But you are right. It is cleaner your way.

Posted: **Fri Oct 14, 2005 14:55**

Seems like quite alot of effort for a model

Posted: **Fri Oct 14, 2005 16:24**

You have to assign a model frame to each and every state. And the models at hand even assign more than one frame to a state. That blows it up considerably. What you see above is a straight translation of the .DED file for the Arachnotron's model without much care about the exact meaning of some stuff.

Posted: **Fri Oct 14, 2005 18:05**

Might seem like a messy way to use models in the newer games and even the OpenGL ports but you got to remember 3D Models by nature are going to be 10X more smoother animation wise than doing everything by sprites. Plus you a have much greater control over the model. Another great thing is that you can do a shit load of cool things with models that are not possible with sprites like fully animated idle sections. I would rather take the more messy gotta code every 3D Model action route over the bloated millions frame and a half wad route. Trust me 3D Models will save tons of valuable space in the wads.

Posted: **Sat Oct 15, 2005 5:07**

Personally, I'd probably only be using models for decorations (unless I decided to really take the time for enemies), and it doesn't seem like it'd be all that difficult to define the states for those using that setup.

Posted: **Sat Oct 15, 2005 5:17**

How exactly would this work for view weapons? I imagine you'd have to set some coordinates for the origin of the model on screen (x/y/z positions, three rotational axes, maybe an FOV setting seperate of the player's view)?

Posted: **Sat Oct 15, 2005 9:13**

Be sure to add support for crouching models for people who want to provide player replacement models...

Posted: **Sat Oct 15, 2005 9:21**

wildweasel wrote:How exactly would this work for view weapons? I imagine you'd have to set some coordinates for the origin of the model on screen (x/y/z positions, three rotational axes, maybe an FOV setting seperate of the player's view)?

Later. I have to get it to work first.

Nash wrote:Be sure to add support for crouching models for people who want to provide player replacement models...

Most definitely not. I already said that I consider crouching an abandoned feature and I won't invest any work in it anymore.

Posted: **Sat Oct 15, 2005 16:50**

wow... this seems alot more complicated than mdl files from hl/cz I think those use some quake c format thing and compiles a bunch of .smd files into one mdl with the textures and such... it also gives each animation a name which if called plays the animation once... although it has been a while, and if you dont decide to use mdl's i guess ill have to get used to the complicated stuff

Posted: **Sat Oct 15, 2005 17:34**

It has to be tied to the states, otherwise it doesn't work in Doom. More modern games can make it simpler by defining a lot of that data inside the model itself. Here I have to make the model fit into the existing data and that results in the high amount of data you see.

Posted: **Sat Oct 15, 2005 23:45**

A question: Will the models be able to be walked upon and such (for when used as decorations), with correct collision detection, or will they still just use Doom's height and radius?

I ask because I plan on using models for some buildings that'll have sloped rooftops, and I was wondering if a person would actually be able to run across the rooftops correctly.

Posted: **Sun Oct 16, 2005 0:12**

BetaSword wrote:A question: Will the models be able to be walked upon and such (for when used as decorations), with correct collision detection, or will they still just use Doom's height and radius?

The Doom engine is incapable of handling correct collision detection. And that doesn't even account for the lack of easy to process information in the models. So the collision detection will use the known bounding boxes.

I ask because I plan on using models for some buildings that'll have sloped rooftops, and I was wondering if a person would actually be able to run across the rooftops correctly.

No. You can't use models for geometry the player has to interact with in more than the most primitive manner.

Posted: **Sun Oct 16, 2005 5:37**

Ah, alright. Well, I'll still be able to use it for some of the buildings that can't easily be done with normal sectors, but they couldn't be climbed on anyways. Eh, models will still make so many things much easier to do.

DRD Team

Model definition format

Model definition format