DRD Team

Hi all! I have some technical questions.

1) I'm working on mod with lots of 3d models (.md3). They are high poly, every one with 384x384-512x512 texture, most of them simmilar (i.e. one model appears 10-20 times on map). They don't down FPS, but loading only when player see them, and this makes one second lag. So, question: is it possible to precache models while map/wad itself loading?

2) Soft transparency of alpha channel on 16/32 bit .tga & .png model textures still not supported?

3) Where can I found information about making animation for 3d models?

Thanks!

-Andrew

2. is because of the lack of triangle sorting mechanism. It's reduced to 1-bit alpha to avoid the graphical glitches that would happen with translucency. (The reason why sloped 3D floors cannot be translucent is essentially the same, by the way.)

I don't know about 1. and 3.

3) It can depend on what model editor you are using.
If for instance, you are using Blender, you would go here for detailed tutorials.
But it can be different for each model editor. Note that those blender tutorials were made for a much older version, so some thing may not be the same.

You can also use google very well to find out how to do stuff.

Thank's for answers! Just a little screenshot :)

I'm using MilkShape 3D, so, I hope, google will help :) In any way, it is still possible to look how animation was done in existing projects with .md3 models.

Precaching models would probably add a lot of "hanging" time when loading maps, AFAIK.

This true, but I think in some situations/maps this anyway better, than loading models only when player see them.
For example, map with +-12 high res. textures (512x512 jpg), simple cubic architecture (a-la Wolf 3D) and HQ Scale x2 loading ~3-4 seconds on my PC, so, adding 4-5 more seconds to preload all models will not be terrible.

Kilian wrote:Hi all! I have some technical questions.

1) I'm working on mod with lots of 3d models (.md3). They are high poly, every one with 384x384-512x512 texture, most of them simmilar (i.e. one model appears 10-20 times on map). They don't down FPS, but loading only when player see them, and this makes one second lag. So, question: is it possible to precache models while map/wad itself loading?

I have some invested interest in this as well. I'm going to be testing my models in 3 of the source ports that i've been asking about in the next couple of weeks.

I would like to know what you mean by high poly. How many triangles are on each model?

I can't tell exactly now, just because I recreate some of them (texture sizez and poly count reduced).

Approximately, there was ~1300 + 1200 + 550 polys (textures: 512x512 + 512+512 + 256+256).

My computer isn't so weak, as I said before, after laggy loading there is no any performance problems. That's why I'm interesting in seeing optional trigger for precaching 3d models when map is loading :)

Some screenshots of that models: 1 and 2

Firebrand wrote:Precaching models would probably add a lot of "hanging" time when loading maps, AFAIK.

I agree with Kilian. A delay at the start, when things are loading and you are not playing anyway, is much preferable to random stutters during play when you happen to come across a previously unseen model. Of course, if pre-caching was an option then we could all be happy.

Doh! More ideas, more questions ...

1) Merging effects of mirror and warping texture to get something like realistic water, and, maybe "hot air" - possible
2) Are there any more shaders that are provided in gzdoom.pk3
3) What are the limits set by the number of models and sprites on one map
4) The engine handles 8 bit sprites faster than 16 bit w. alpha? 8 bit more good for performance
5) Which format for wall/ceiling is better for perfomance (Jpg/png/tga - 16 bit, hires)
6) Can 3d models use wall/ceiling textures (I can't get it work because of the different ways to folders)
7) Different HUD weapon bobbing - possible
Shinemaps on wall/ceiling textures - possible

1) I am not sure, I am not at all familiar with shader language, nor how GZDoom uses it. Graf might be the only one who can properly answer that, unless there's other people who have played with it (and there does seem to be some who are, recently).
2) Everything that GZDoom provides is in the pk3 under shaders/. Otherwise I don't know what you're asking.
3) The limit is likely very very high - however, I would not recommend exploring such limits, as GZDoom will break very easily if the engine is stressed too much (and this goes for both the OpenGL as well as the game engine (zdoom) components)
4) Overall, yes, as long as your card can handle paletted images (and most do, these days).
5) Converting to PNG 32-bit is probably best, but I don't actually know for sure. I am not sure if GZDoom handles 16-bit images natively. If you use TGA, you're stuck with an uncompressed image (but the pk3 archive itself can handle that), if you use JPG you will have image artifacts and no translucency, not to mention JPG has to be decoded which will slightly increase loading time. Also, if you use TGA, you will eventually have to transition to using PNG anyway for sprites since TGA doesn't support offsets, so you might as well just stick with PNG since it handles everything in a single file and format. (Helps a lot!)
6) AFAIK, any texture is available for any surface that can use them. If not, you may use the [wiki]TEXTURES[/wiki] lump to port them to other surfaces. I don't think it's necessary, though, as I think GZDoom will read any texture regardless of what surface type it is defined for.
7) Not sure, someone else who's played with weapons more may know.
8) I don't think this is possible currently.

Eruanna, thank you very much!

Eruanna wrote: 4) Overall, yes, as long as your card can handle paletted images (and most do, these days).
5) Converting to PNG 32-bit is probably best, but I don't actually know for sure. I am not sure if GZDoom handles 16-bit images natively. If you use TGA, you're stuck with an uncompressed image (but the pk3 archive itself can handle that), if you use JPG you will have image artifacts and no translucency, not to mention JPG has to be decoded which will slightly increase loading time. Also, if you use TGA, you will eventually have to transition to using PNG anyway for sprites since TGA doesn't support offsets, so you might as well just stick with PNG since it handles everything in a single file and format. (Helps a lot!)

Internally everything is converted to the format set in the menu. GZDoom itself only handles 32 bit RGBA for its buffers and lets OpenGL do the conversion if the native format is different. GZDoom will never create paletted textures.

6) AFAIK, any texture is available for any surface that can use them. If not, you may use the [wiki]TEXTURES[/wiki] lump to port them to other surfaces. I don't think it's necessary, though, as I think GZDoom will read any texture regardless of what surface type it is defined for.

If you can specify it in the model definition, yes. Model skins do not reference textures by their internal name though. They only use full paths to the graphic lump.