Talk:LOD Models

You might want to mention the use of Max's "MultiRes" modifier which can be used to progressively reduce the polycount of a mesh without having to re-model it. It's very useful for character models and has the ability for you to lock specific vertices from being collapsed where you want to retain detail. If you also save your envelope data from the Skin modifier you can re-load it on a model after using MultiRes so you don't need to re-do the vertex weights. I've used the technique numerous times and you can turn out 5-6 LODs for a character model in under 20 minutes. --Wunderboy 14:38, 14 Mar 2006 (PST)

Hey, thanks for adding so much character-model specific stuff. Unfortunately I only have experience with props, as HEAT has yet to find a decent player modeler :(

Maybe it would have been a better idea to make two seperate parts, one for props and one advanced part for characters? Because right now, it seems to be a little overkill for someone who'd like to do a LOD for a regular prop (especially the .QC part - maybe I'll just add a prop-QC complete example).

As for the MultiRes: I think for character models it is the best choice, but not for my example. It'll start removing vertices in places you don't want to, and (this happens if you have some big faces, not like on some player models) the smoothing groups get messy. The Vertex Weld is the better (because faster) choice in my example, yet it might be interesting and helpful to have another example for character models. Maybe you can make some screens when you do your next one?

I've written "Reducing polys of complex surfaces - This can be done by using the tools your modeling package offers.". As you pointed out, it's a good idea to mention the tools available (for each specific modeling package). Maybe some XSI and Maya modelers read this and can post the tools with a short description of what they do and where to find them. --Vaarscha 23:25, 14 Mar 2006 (PST)

Hmm don't lods recieve propper ligthing? Makes the change a bit to obvioes or is this perhaps a issue with the latest sdk update

http://www.bluestrike.be/tempspul/normal.jpg http://www.bluestrike.be/tempspul/lod.jpg (see the balcony) --Bluestrike 13:09, 16 Aug 2006 (PDT)

$body vs $model

I noticed you used $body in the simple example but all the QC's I've seen for Source use $model. Are they interchangeable or was it just an oversight? --Wunderboy 11:37, 20 Mar 2006 (PST)

It was not an oversight. It does work with $body, at least for static props. It doesn't for physic props, I think, but I'd have to try that.

In fact, I'd eagerly like to know what's the difference between both. The wiki contains no valueable information on this ($body isn't even listed in qc commands) and I haven't found any other information either. I believe that $body uses less resources, but I might be absolutely wrong here. Guess we need clarification from someone who knows. --Vaarscha 15:29, 20 Mar 2006 (PST)

$body is a less complex version of $model. The $model command offers more parameters (flexes, eyes, etc.), mainly for use with characters. In most cases, $model should be be used with characters, and $body should be used with props. --JeffLane 17:43, 20 Mar 2006 (PST)

Thanks for clearing this up! I have added it to .QC Commands so other people find the information faster. --Vaarscha 23:48, 20 Mar 2006 (PST)

Units

Why does LOD system use metres whereas the rest of the game uses units = inches? The only mention of this fact is cursory at best. I realise metres may be more convenient for eyeballing distances, but any inconsistency is confusing. I think the fact that it's in metres needs to be more visible in the article -- Defrag

Why did Valve do this, why did Valve do that - how the hell is anyone supposed to know? They probably don't know it themself.

Anyway, if someone reads the article carefully, I doubt he/she will miss that it's in metres. It's mentioned several times, including in the definition of the .qc command. Plus you should always use the HLMV to check how it looks in distance, so just copy the values straight from there. Blindly typing something, whether inches or meters, into the .qc isn't such a good idea imo. --Vaarscha 14:50, 22 Jul 2006 (PDT)

A very simple rule of thumb which may be useful for estimating LOD; This is true for any Field of View:

If the distance between viewpoint and object is doubled, the object is rendered at half the previous resolution; ie it's apparent horizontal and vertical dimensions are both halved.

It is also possible to calculate the actual number of pixels used to render an object at a given distance, but it is more complex because of the number of variables involved: Distance, Object Width & Height, Horizontal & Vertical Field of View, Horizontal & Vertical Screen Resolution, etc. At the end of the day, the exact calculations are impractically laborious for a 'rough idea' of LOD, but we can create a few ballpark figures:

Default player horizontal FoV = 75° so we can use a simple formula : Object Size/ (Distance * 1.55) where Object Size and Distance are both measured by source map unit = 1"). The result gives us the object's dimension as a fraction of the total FoV, which, multiplied by the screen width in pixels gives us the object's screen-width in pixels.

For a 75° FoV and a horizontal screen resolution of 1600 pixels, an object which is 8 units wide at a distance of 16 units = ( 8 / (16 * 1.55) = 0.32 =) 32% hFoV = (32% * 1600 = ) 512 horizontal pixels.

So if 8"w @ 16"d = 512hpx, and we double the distance to 32" the resolution is halved (=256 px), or if we double the size of the object to 16", we double the resolution (1024 px) ... etc

Because the Source Engine varies Screen Aspect Ratio and FOV proportionately, our unit ratios can be applied to both horizontal and vertical measurements; an object which is 8" wide and 16" high will render as 256 px wide and 512 px high at a viewing distance of 32" (on both a 1600x1200 and a 1600x900 screen)

The only part of the formula which doesn't convert easily is the 1.55 FOV factor ... which is derived from the angular field of view (aFOV) by the formula: Factor = 2 tan(aFOV/2)

Beeswax 12:19, 9 Oct 2007 (PDT)