The situation with 3-d models.

[smg m7]

I've kinda been following the JDRP's work, and I'm very impressed, Daniel. But, nonetheless, GZDoom would do better with it's own. It'd give it more of an identity anyway.

[justin023]

The problem with the jDoom enemy models is that they're just not good enough. I would play with enemy models if there were any really decent ones, but the amount of work that would have to be put into them before I would use them would probably be a lot more than anybody would be willing to do (especially me, I suck @ modelling :p). I would much rather see models in Doom 3 than sprites because those models are ridiculously good.

As for simple things, I would much rather see models. The ammo box can really be depicted only one way: As a cube. With the enemies, there can be a lot of variation in how they could look. I plan on eventually making models for things like ammo, keys, columns, and other decorations. And I hope to eventually be able to use models for more than just the spawn state of the weapons. But I'm not dying for enemy models because there will probably not be any ultimate models which will pwn the sprites. When it really comes down to it, models, like dynamic lights, don't add anything to the gameplay like 3D floors do.

[Enjay]

I plan on eventually making models for things like ammo, keys, columns, and other decorations.

Are you aware that these have all already been done for JDoom? Most of them are pretty good. If nothing else, they could provide a good base for your work. The monsters, however - despite the fact they have been improved steadily over the years, are another story.

[smg m7]

Dani's new models are really good, though. It's too bad they won't be done for the next release of the JDRP, since I end up using models for everything but the monsters due to the bad modeling. Nonetheless, Dani's work is as good as the Doom 3 models, if not better.

[Graf Zahl]

Honestly, it doesn't really matter how good they are. The only important thing is whether they are faithful to the originals.

[DaniJ]

Once GZDoom gets up to speed on its model support I'd be happy to figure it in to the core jDRP pack but atm there is so much that can't be done it isn't worth me spending any time on it.

I always intended jDRP to be port independant anyway but to this date the only port that offers the features needed is Doomsday (Risen3D is missing too many of the Doomsday features since it split and the only other port that offers models is Vavoom. The support for models in Vavoom is abysmal though).

If you don't like any of the models I've done or you have suggestions on how to improve them please do let me know!

I've spent a LOT of time developing the next version of the jDRP so hopefully you'll find them much more faithful to the original sprites.

[Graf Zahl]

Once GZDoom gets up to speed on its model support I'd be happy to figure it in to the core jDRP pack but atm there is so much that can't be done it isn't worth me spending any time on it.

Right now the model support is still in its first stages. The problem is that anything I can do now will be an obstacle later when proper support for DECORATE defined actors is needed and this is something I haven't done before so it's all new to me.

But I have to start somewhere, right?

BTW, is Doomsday planning to support MD3?

[DaniJ]

But I have to start somewhere, right? Wink

Sure, I'm not knocking ya.

Its just that atm the support is so basic it makes no sense for me to try to get the models working under GZDoom.

BTW, is Doomsday planning to support MD3?

It was planned for 1.8 (as well as a Quake3 style shader system that we have already designed) but after work began on Hawthorn it was postponed.

I might have a look at it again after 1.9.0 is released. There is a huge amount of work in supporting the MD3 format correctly, for example I would like to develop a new DM3 format that has intergrated LOD support to match that of DMD (which also means upating md2tool). I'd also like to make full use of the tag system for animation and selskin purposes. Not to mention shaders which requires a substantial rewrite of the renderer...

There are more pressing issues than MD3 support atm (eg BOOM support, which in turn requires the new DMU (which is a map update API that allows Doomsday to handle the map data instead of the games) and restructuring XG and implement it into jHexen in a way that interacts with ACS (we don't want to tack BOOM support into jDoom.dll, we want to completely intergrate it so that all the games benefit)).

All these factors are what prompted skyjake to leave MD3 support untill Hawthorn where support for model formats are implemented via visualization plugins.

[Nash]

Dani, a quick question if you don't mind; what software are you modelling the JDRP models in?

And what's the tag system for MD3? How does it work?