Modelling vs. func_detail

tnelly

L1: Registered
Dec 18, 2010
12
0
Ok, modeling will obviously win, BUT:

In some cases, can func_detail do the same roles as models, without any disadvantages?

In example, when I want to make custom beams, fences, windows, bridges and like that, that are not in the same size as already existing models, then is it ok if I just make them out of func_detail? If someone can't make proper models, it's faster and simpler to make it this way. (with func_detail)

Is there any reason, wherefore func_detail is not recommended to use in larger amount, instead of models? (in case of lots of windows, beams)

I would be also happy for any other pros/contras in this matter :p
 

StickZer0

💙💙💃💙💙
aa
Nov 25, 2008
664
647
I can't provide details, but I do remember being told that models use less rendering power or something than actual world brushes, and the reason why models are seen as "more expensive" is because they generally have more polys than a world brush.
Not entirely sure though
 
Apr 13, 2009
728
309
Models use vertex lighting, which is much cheaper to render than lightmaps (per polygon) but doesn't look nearly as good. If you you want to see shadows, don't make it a model.

Even if you can't model for shit you can use propper to turn some of your func_details into models. Useful for detail beams, door and window frames, particularly when you are getting close to max t-junction errors.

I believe models are cached, so if you're using a lot of the same prop, it wouldn't be as costly as using multiple func_details.

Also valid, though I don't know at which point it makes a noticable improvement.
 
Feb 18, 2009
640
629
Not that is makes much diff, but shouldn't brushes take up a tiny bit more memory in the bsp? Just a guess (brushes = vertex/face data, model = point data and a ref to a file). Of course that is invalid when talking about custom models, what with packing them into the bsp.

Go me and my pointless "contributions" to threads ^_^
 

Pocket

Half a Lambert is better than one.
aa
Nov 14, 2009
4,694
2,579
There's also the waterindices issue. I don't know what waterindices are, but the more brushes you have, the more of those your map gains, and eventually you're liable to run into an absolute limit. That's happened before, with a map that didn't seem to be particularly heavy on them compared to Valve's maps.
 

tnelly

L1: Registered
Dec 18, 2010
12
0
So this is something that not only for me is not clear, good to hear :D

Even if you can't model for shit you can use propper to turn some of your func_details into models. Useful for detail beams, door and window frames, particularly when you are getting close to max t-junction errors.

That's also something that I was wondering about, but couldn't find answer yet, so thanks!
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
waterindices ~ t-junctions. When a face edge meets another (at a perpindicular) it tesselates said face, when a face can't be split into a fan shape via triangles it gets cut multiple times. I'm gonna steal Boojum's image url here: http://dl.dropbox.com/u/98931/MappingResources/waterindicies.png

The engine has a limit to the amount of t-junctions/water indicies/tesselations that can exist in a single level and this can be problematic for some larger levels. This is why you'll see models used for trusses in areas like outside 2fort's primary spawn. This prevents faces like the concrete floor being cut into many more tri's.

Displacements can serve the same purpose as models though. They wont cause tesselations in perpindicular face edges but they do create more tri's, as it is a mesh. But you can make mini bends in them for acute details to the same effect as a model. They also use vertex lighting.

tying world brushes to entities causes vvis to ignore them, any solid brush entity will not cause tesselations (except func_detail), such as func_brush or func_lod. Valve use func_lod on stair trims where the steps cause tens of tesselations on a single face. func_detail is really only a fake entity used to reduce compile times by simplifying visleaf formations.

Models become more efficient when you use several of them as they only have to be cached once in the memory, rather than a load of unique geometry. Along with the fact that vertex lighting is cheaper to render than lightmaps it makes models very useful. You can imagine lightmaps as another layer to the material that has to be rendered, along with any normal/bump map under/ontop of the base texture; you should be able to understand how vertex lighting would be cheaper to render on a model, particularly when it involves fewer tri's/faces, than a lightmap is.

But this isn't to say models are always superior to func_details otherwise they would be redundant. Sometimes it is more cost effective time wise to just use a func_detail. Also, func_detail brushes are always calculated as seperate entities whilst data for a model is often calculated from it's origin, such as lighting. So a large model that cuts through geometry will have strange lighting affects if it is low poly and the map isn't compiled with additional lighting parameters such as -staticproppolys (which still many not fully resolve any lighting bugs).

Edit: It's also important to note that func_detail's and/or models are not a means to an end. Not everything should be func_detail'ed, and particularly geometry that blocks LoS (line of sight), even if of moderate complexity, should be left as solid brush work, as the lengthening of the compile time is justified by the boost to in game performance.
 
Last edited: