Modelling vs. func_detail

Discussion in 'Mapping Questions & Discussion' started by tnelly, Jan 9, 2011.

  1. tnelly

    tnelly L1: Registered

    Messages:
    12
    Positive Ratings:
    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
     
  2. StickZer0

    aa StickZer0 💙💙💃💙💙

    Messages:
    664
    Positive Ratings:
    667
    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
     
    • Thanks Thanks x 1
  3. Fr0Z3nR

    aa Fr0Z3nR Creator of blackholes & memes. Destroyer of forums

    Messages:
    6,391
    Positive Ratings:
    4,906
    I heard it was something to do with lighting. and VRad or VVIS or whatnot.
     
    • Thanks Thanks x 1
  4. honeymustard

    honeymustard L9: Fashionable Member

    Messages:
    698
    Positive Ratings:
    273
    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.
     
    • Thanks Thanks x 1
  5. Loc_n_lol

    Loc_n_lol L10: Glamorous Member

    Messages:
    726
    Positive Ratings:
    273
    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.

    Also valid, though I don't know at which point it makes a noticable improvement.
     
    • Thanks Thanks x 1
  6. Mick-a-nator

    aa Mick-a-nator

    Messages:
    640
    Positive Ratings:
    314
    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 ^_^
     
    • Thanks Thanks x 1
  7. Pocket

    aa Pocket func_croc

    Messages:
    4,489
    Positive Ratings:
    2,215
    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.
     
    • Thanks Thanks x 1
  8. tnelly

    tnelly L1: Registered

    Messages:
    12
    Positive Ratings:
    0
    So this is something that not only for me is not clear, good to hear :D

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

    aa grazr Old Man Mutant Ninja Turtle

    Messages:
    5,436
    Positive Ratings:
    3,561
    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.
     
    • Thanks Thanks x 5
    Last edited: Jan 10, 2011