Tris count versus sruface count

[Rav3n]

First of all I'll start by saying hi to everyone.
Hi, I'm Rav3n i actually belong to the Urban Terror level design community more then to Quake 3. But since we use more or less same tools and engine i guess my question can be posted here.

Here's the thing.

I'm working on something quite demanding (brushwork and details wise).

Right now I'm trying to build a street, to be more precise I'm making buildings.
To make things easier i decided to convert front sides which are more detailed into models.
Everything works but here's my problem. Surface count is now very low, maybe 25% of the surface count i was getting when compiling the building as brushwork. But the tris count went up, not much maybe 15% but keeping in mind these buildings are tall and we are talking about a street with more then just 1 building the tris count in total will be well over 30k.

So what i want to know is can a reduced amount of surfaces compensate the increase in tris count.

My textures are mostly 1024*1024 (i already got attacked for using textures above 512*512 :S), all non visible surfaces are caulked and edges clipped where it was possible.

If someone asks why didn't i post this question on the UrT forum the answer is quite simple.
I already know their answer, they'll start screaming out Null's statement that the tris count should not go over 30k.
I respect Null very much but that statement is 5 years old and people still stick to it like it's something from the Holy Bible.

[Bonnebez]

I will let the experts over there answer you, but before one of them come up with a solution i will share with you a question that have been in my mind for some time : is it possible to use levels of details on models other than weapons and items ?

[Rav3n]

You mean reduce the amount of details shown on models through games graphics settings?
AFAIK UrT's way of reducing details comes down to reducing texture quality.
If it would be possible to remove details and decals while preserving texture quality it would be perfect.

[Noruen]

It is simply because of the fact, that you use models. idTech 3 uses models more like accessories, it is not clever to use them as large complex "structural" components. When you use brushes instead of models, you can optimize polycount by hints, areaportals... So i suggest to return to brushes And also keep in mind, that long streets and open areas really needs to save every polygon. But 30k is ok todays

[Rav3n]

The only reason i decided to try using larger models was so i can easily move them around, hide them and in the end if i want to make a change on the building it's a lot easier to edit it when you have it singled out.

I'll replace models with brushes and test it.
Luckily i built those models in radiant itself so swapping the 2 is less then 10 minutes of work.

[^misantropia^]

I don't think it really matters from a performance perspective if you use models or (non-structural) brushes, the engine has to render them one way or the other. Back-face culling is arguably slightly less efficient for models but you can offset that with LOD.

This is assuming you use MD3 models, ASE models are essentially converted to brushwork and compiled into the map.

[Rav3n]

No I'm using ase models. I don't normally use them on this scale but wanted to experiment a little with them.

[obsidian]

AFAIK, Q3 does not do LoD on map models, only on patches (without -patchmeta) and certain things like weapon models. It's something that can be coded in as a lot of mods and games using idTech3 have map model LoD. Really not sure about UrT. (misantropia, if you see any code in Q3 which says otherwise, please tell me how it's supposed to work)

misantropia is right about performance, it should be on par with brushes assuming brushes and models are relatively "clean". Back-face culling is a rather simple process so it's not a big performance hit.

I'm not sure why you're getting more tris on models than your brushwork versions, Q3Map2 should be just running BSP on the map as it normally does and then just dumps the resulting vectors to an .ase file.

[Rav3n]

I'm not sure why you're getting more tris on models than your brushwork versions, Q3Map2 should be just running BSP on the map as it normally does and then just dumps the resulting vectors to an .ase file.

Here's a quick test. On one side there is brushwork and on the other an .ase model of exactly the same thing.
The increase isn't big but like Nouren stated every poly counts if it's open area.

Brushwork:


Model:


As you can see on those screenshots the surface count is very low but I'm not sure if it means anything with the tris increase.

[^misantropia^]

AFAIK, Q3 does not do LoD on map models, only on patches (without -patchmeta) and certain things like weapon models. It's something that can be coded in as a lot of mods and games using idTech3 have map model LoD. Really not sure about UrT. (misantropia, if you see any code in Q3 which says otherwise, please tell me how it's supposed to work)

I should've mentioned that you have to do it by hand: create a LOD for mymodel.md3 and save it as mymodel_1.md3. Second-level LOD should, unsurprisingly, be saved to mymodel_2.md3 and that's it, as far as LOD support goes.

[obsidian]

Try viewing the model with /r_showtris 1 and see if you can spot any areas where it's creating more polygons than it should.


Edit: Misantropia, it doesn't seem to work for map models. I built two spheres of different polycounts and converted them into md3 files, named lod_1.md3 and lod_2.md3 and made sure that they weren't being compiled into the bsp (tied to a func_bobbing and changing file name causes model to disappear in-game). misc_model entites are compiled into the bsp regardless of format, and I tried that initially too, but neither method shows any change in LoD.

[Rav3n]

Already checked the model with showtris. As far as i could tell all the polygons are in the right places, no clusters or splits that would render extra polygons.
I guess I'll just have to "paint" on some details with special textures.

[Rav3n]

BTW Obsidian is that q3data.exe converter worth using?
I remember reading about it but not sure if there's any real benefit from converting .ase to md3

[obsidian]

For a level designer, .md3 uses are a bit limited, but they can still be useful in certain situations.

• Weapon and player models
• Models utilizing shaders with deformVertexes autosprite(2)
• Alternate method of attaching models to triggerable func_ entities

[Rav3n]

Thanks Obsidian, you ARE the dude

[^misantropia^]

Edit: Misantropia, it doesn't seem to work for map models. I built two spheres of different polycounts and converted them into md3 files, named lod_1.md3 and lod_2.md3 and made sure that they weren't being compiled into the bsp (tied to a func_bobbing and changing file name causes model to disappear in-game). misc_model entites are compiled into the bsp regardless of format, and I tried that initially too, but neither method shows any change in LoD.

It seems this is a case of 'used to work'. The bit that loads misc_models (and LODs) appears to have been gutted in one of the later point releases. Seems I'm ten years out of date. :/