DRD Team

Good point. It's easier that way anyways. Plus, I don't want these to work for only one source port.

Nice work by the way. Looks like it's been a lot of fun. Just out of curiosity, have you gotten them to work in the game yet?

The problem with the OBJ method is that whilst a lot of people can use correctly packaged model packs, the number of people who could set one up from models provided in a format that needs knowledge of a model editing program is far more limited. ie, until someone converted your models and released a model pack for a specific port, hardly anyone would use them.

NiuHaka, yeah I have got some models in-game. I have got the zombieguy, shotgunguy, doomguy and the humans on the pikes(twitching and dead)
My animation skills are not the best though because these are the first ever animations I have done.

Enjay, When someone has packaged one of the models for a port I will then have it hosted on the DMP sourceforge page so people can use them for their port. I only have the skill to package for doomsday.
And Doomsday uses md2, but others could export the Obj models for md3 and use them with gzdoom and the likes. Darkslayer from the skulltag forums has done a few of my models I believe

Does anyone know if there is a vertices and/or triangle limit for any of these source ports?

I ask because I seem to remember there being some kind of vert limit with the DOOM engine. I started modeling last night and was only thinking about the md3 limitations.

The limit you may think of applies to the map format. Models are completely indepenent objects and the onlylimits they might have come from the format they are stored in - if that format has a liimit, that is.

Okay. Yes, that sounds right. So does that limit still apply to maps when using any of these source ports?

It would be cool to see models organized in a good way so that they can be packed for any source port , it's a good idea, but it will take a good time to be completed.

KuriKai's DMP project is exactly the kind of direction I was trying to take the jDRP in when I was it's maintainer (and chief contributor for quite a while). I then joined deng team to work on Doomsday as I thought it was the only way the engine would ever get the features I wanted. Yeah, I basically gave up working on models, learned to code in C and that, as they say, is history.

I've already contributed a lot of the art I had started to produce to the DMP project and hopefully KuriKai will include some of it

What I really wanted to say is this:
It should be possible to produce a simple (command line) application which combined with a handful of utility apps can output the various definition formats used by each sourceport and convert your model "source files" as needed also. Basically it should be possible to automate away the current burden on maintaining a project such as this.

I personally think this is import, if only to give a focus point to the combined DOOM community. The present situation of different "hires" projects for each port is completely counter productive.

Ultimately I'd like to alleviate the burden myself by implementing support for newer, more standard (read: open) file formats but right now we are in the middle of a complete rewrite.

That's definitely an interesting approach for this kind of feature DaniJ, I think it would be interesting if the process could somehow be automatized, but the problem here is that we are talking about a big number of ways of achieving the same thing, I mean, there's a big number of requirements for each sourceport to display models, AFAIK, all sourceports support MD2 models, but others have support for MD3, DMD, etc. which makes this process a bit more difficult IMO.

Well, I started modeling the Doomer a few nights ago and came up with something I'm starting to like. The problem with it is that i'm getting dangerously close to the triangle limit for md2 and I know for sure that I'll be doubling these triangles for some of the other models, mainly the Cyber Demon and the Spider Mastermind.

This is just the first pass so I could potentially be adding some more triangles. Not sure on how many more triangles his gun will take but this tri count is too close for comfort. I'm pretty much locking myself into using md3 which also means i'm locking myself into using gzdoom.

Here are a couple of screens of what i'm working on. No textures yet. Just material shaders for now. I'm going for a realistic look with anatomically accurate proportions. I also just now realized that I forgot his elbow pad things. I kind of like it better this way though.

Edit: Oh yeah and the death models will be taking quite a few more triangles so md2 are for sure out. Looks like 100% for gzdoom.



Here you can see the triangle count. Triangles will go up after adding the shotgun.

Looks great.

The triangle count is always a problem, also for the engines.
I think for the doomguy its not a big problem because there are not
much of them in the game at the same time.

The engines for doom are not fast in rendering the stuff like a modern engine.
I always keep the models at 1000-1500 triangles otherwise there is a lag when there are
much models to render.

I say first try it out, before you have done a lot of work and it is not usable for the game
because of the lag.


Willem

Wow. That is awesome.

If you have to, I suppose you could remove quite a lot of triangles - Sure you'd end up with sharper eges/corners, but textures could partially hide that, right?

On another thought, do GZDoom and/or MD3 support bump maps?

NiuHaka, looking good. Keep in mind that because of the aspect ratio of the original doom engine, that models will get stretched a bit.

sitters wrote:Looks great.

The triangle count is always a problem, also for the engines.
I think for the doomguy its not a big problem because there are not
much of them in the game at the same time.

The engines for doom are not fast in rendering the stuff like a modern engine.
I always keep the models at 1000-1500 triangles otherwise there is a lag when there are
much models to render.

I say first try it out, before you have done a lot of work and it is not usable for the game
because of the lag.


Willem

Too bad nobody knew what the recommended tri count was when I asked in the original post. :p Actually It will be okay if I have to trim him down a bit because I will still use this model for the title screen etc.

Is this "lag" due to source port limitations or hardware limitations?

NeuralStunner wrote: Wow. That is awesome.

If you have to, I suppose you could remove quite a lot of triangles - Sure you'd end up with sharper eges/corners, but textures could partially hide that, right?

On another thought, do GZDoom and/or MD3 support bump maps?

Yes I could remove a lot of triangles. I normally work with a triangle limit of around 1,000 which is why I wanted to build this guy with much more. And yes textures hide low triangle counts very well.

Also, I don't know if by bump maps you meant normal maps but It would be a dream come true if normal maps were supported. I highly doubt it though. *crosses fingers* I hope someone answers this one.

KuriKai wrote:NiuHaka, looking good. Keep in mind that because of the aspect ratio of the original doom engine, that models will get stretched a bit.

I thought that there were aspect ratios in zdoom that fixed this. I know that those aspect ratios were not used much because vanilla doom was created with the stretch in mind but I was actually hoping to build this stuff as if there was no stretching.

In case there is no aspect ratio that does not stretch- Does anyone know what percent they are stretched?

That are source port limitations, the ports uses a older technique of rendering as
modern games, of-course when you have bloody fast hardware it also works faster.

So far I know there is no normal map support by all ports.

Models can be scaled in the definitions for the models, so the aspect ratio can be
correct in the game.