DRD Team

I was just wondering, is there a way to get 3D Models in any PWAD that uses regular Doom sprites, wherever regular Doom sprites are used? I saw that Graf Zahl linked to a lights.wad file with generic dynamic light definitions from ZDooMGL and I thought maybe there's also such a thing with 3D models that could also work with GZDooM; that is, if GZDooM supports models the same way as some other port already in existence.

Also, great job on GZDooM. I've been playing NDCP in GZDooM at maximum graphics settings/quality with the lights.wad definitions and other custom WADs to add liquid splash and extra wall blood and transparency and other such effects, and also using custom cfgs to add light effects and weapon zooming. It actually almost feels like a complete game.

hi

just read this line

"I've been playing NDCP in GZDooM at maximum graphics settings/quality with the lights.wad definitions and other custom WADs to add liquid splash and extra wall blood and transparency and other such effects"

and was wondering what these special effect wads are. i know they go in the skins dir (like lights.wad) so could i get some links to the splash flats and the others ones please?

Thanks

Lemonzest

Hey

Actually, my lights.wad didn't go into skins, it's just in the GZDooM directory, and working fine. As for the other WADs and CFGs, I don't really remember where I downloaded them, but if you find me on MSN I'll send'em to you there. My hotmail is gee_dougg@hotmail.com and if I'm not on-line just e-mail me and I'll try to remember to send'em to you somehow.

Regarding models:

At this point in development, the model feature is really only useful for mod authors to add custom content (new 3-d models).

If you are interested in playing regular Doom pwads with models, then unfortunately there's no immediately and readily available way to do so.

The long answer: You can try to rip the models from the JDoom Resource Pack (although DaniJ won't be too please about that ) - even then, you won't be able to bring the JDRP models' animation data into GZDoom as they are all animated very differently. JDRP uses a different model format, which if I'm not mistaken are MD2 models ran through a certain DMD (Doom MoDel?) converter that JDoom can read.

You would take the mesh from the JDRP, convert it into any format your 3-d software can open (assuming you have one) then you'd have to reanimate it and stuff. Maybe you also have to remap the skin meshes again because that data might not get convereted. I don't know.

Short answer: It's not worth the effort. As I said before, model support at this point is only good for mod authors to create new content.

And the way models are defined in GZDoom currently makes it very difficult to animate them. The implementation that GZDoom currently uses is really only suitable for static decorative models. You actually CAN make animated models with the current implementation but it's just a little clumsy and not efficient IMO.

EDIT: If you are interested in creating your own 3-d models though, then do a forum search for MODELDEF. That is the lump where 3-d models are defined.

The basic concept is to "remap" each sprite frame to a single fram in the 3-d model.

GZDoom supports MD2 and MD3. I'd go for MD3 though, because MD2 is a very clumsy model format.

I was afraid of that. I knew the model support would only be static/enviroenmental.... But I thought maybe the old ZDooMGL models could be used or something.

Hmmm... I'm willing to try and convert the old ZDoomGL models to GZDoom.

Where can I download the old models?

I know they are crap but at least it gives users something to play with.

Edit: Just to correct you: the model implementation in GZDoom isn't limited to static environments. As I said before, you CAN animate the models. It's just that the system isn't really designed to do so.

You can work around it. What you get, HOWEVER, are very choppy animations similar to Quake 1 before model animation interpolation was around.

Also, it depends on the model author. The author can pre-create a VERY smooth animation in the modelling software. Like a 50 frame walking animation. But that means the author would then have to define 50 walking frames for the actor in the DECORATE lump, then add 50 lines of code to the MODELDEF lump to remap those 2-d frames to each individual walking frame in the 3-d model. As I said, a clumsy approach, but works.

What Graf plans to update in the future is a better way to define animated models. There would also be smooth interpolation.

I'm not sure, actually. The old site had some download links but Timmie's removed them. The old site was at http://www.doomworld.com/doomgl/ and when you clicked on ZDooMGL you were taken to a ZDooMGL page that showed off the old Kokac version, but now it just takes you to the Mancunet ZDooMGL site. The old one with the models should still be around somewhere though. I think Graf might know.

Edit: About the static models, I understand. I just meant that I was afraid the efficient usability of models in GZDooM at the moment might be limited to that. Of course you can animate them, but I didn't know how efficient GZDooM was. I kind'a guessed though, because Graf had already said that it was "basic" model support (or something to that extent). Thanks for all the info by the way. Some of it I already knew (I'm not exactly a n00b to the community, heh) but I don't know much about certain port-specific features, such as Decorate in ZDooM and XGs in Doomsday, and other stuff (like Legacy's scripting format - forgot the name just now). Anyways I'll shut up now.

Nash wrote: The long answer: You can try to rip the models from the JDoom Resource Pack (although DaniJ won't be too please about that ) - even then, you won't be able to bring the JDRP models' animation data into GZDoom as they are all animated very differently. JDRP uses a different model format, which if I'm not mistaken are MD2 models ran through a certain DMD (Doom MoDel?) converter that JDoom can read.

DMD is an extended MD2 format. GZDoom can read that as well.

DMD is an extended MD2 format. GZDoom can read that as well.

True but why have you disabled the LOD support?

To make it work I have to understand first how a few of the parameters are being used.

What units is the 'distance' factor using? Is this simple world coordinates or is there some scaling factor involved? And what is rend_model_lod for?

What units is the 'distance' factor using? Is this simple world coordinates or is there some scaling factor involved?

It's complicated. Naturally its a 2D distance from the viewplayer to object (float) but I can't explain how its determined as I'm not familar with that part of the renderer. It has ties to the sprite/masked wall sorting too (they are all treated in a similar fashion).

And what is rend_model_lod for?

Thats a simple CVAR controling which LOD is rendered.
0=LOD disabled (LOD level 0 is always used)
1=Normal (the appropriate LOD is determined automatically)
>1 =Custom high LOD level (after determining the LOD level if it is lower than the value of rend_model_lod - use the value of that CVAR as the LOD level).

DaniJ wrote:It's complicated. Naturally its a 2D distance from the viewplayer to object (float) but I can't explain how its determined as I'm not familar with that part of the renderer. It has ties to the sprite/masked wall sorting too (they are all treated in a similar fashion).

Now you know why I haven't activated it yet!

It shouldn't really matter to GZDoom how Doomsday calculates this value.

The "distance" parameter is set at runtime (not in the model format) so just use whatever unit value fits in with your coordinate system and then fudge around till you get a LOD threshold roughly the same as Doomsday.

I can't really explain all the factors involved as that parameter is used throughout the engine (it is also used for dynamicaly changing the sort order under certain circumstances). Its also modified for various other purposes (sprites don't clip into floors, sprites that are always perpendicular to the view plane etc, etc).