View source for 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. --[[User:Wunderboy|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. --[[User:Vaarscha|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) --[[User:Bluestrike|Bluestrike]] 13:09, 16 Aug 2006 (PDT)

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

:It was ''not'' an oversight. It does work with <code>$body</code>, 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 <code>$body</code> uses less resources, but I might be absolutely wrong here. Guess we need clarification from someone who knows. --[[User:Vaarscha|Vaarscha]] 15:29, 20 Mar 2006 (PST)
::<code>$body</code> is a less complex version of <code>$model</code>. The <code>$model</code> command offers more parameters (flexes, eyes, etc.), mainly for use with characters. In most cases, <code>$model</code> should be be used with characters, and <code>$body</code> should be used with props. --[[User:JeffLane|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. --[[User:Vaarscha|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 -- [[User:Defrag|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. --[[User:Vaarscha|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 apparent resolution of the object's height and width are halved. ''' 
... ie both horizontal and vertical dimensions are halved so the total number of pixels used to render the object (its area) is quartered.

To calculate the ''actual number of pixels'' used to render an object at a given distance we can use this simple formula (where the Default player horizontal FoV = [[Dimensions#Field_of_View|75°]] and Object Size and Distance are both measured by source map unit = 1")
* '''(Object Size * Horizontal Screen Resolution) / (Distance * 1.55)'''. 

eg For a horizontal screen resolution of 1600 px, an object which is 8" wide at a distance of 16" = (1600 * 8) / (16 * 1.55) = 512 horizontal px. So if 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

If we let screen res = 1 the result is the object's dimension as a fraction of the total FoV. eg (1 * 8) / (16 * 1.55) = 0.32 or 32% of the screen.

Because the Source Engine varies vertical FoV proportionately with Screen Aspect Ratio, 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). When 'zooming'  Source automatically compensates the decreased FOV with increased resolution, so the 1.55 factor is the only one we need. (If anyone's curious it is derived from angular field of view (aFOV) by '''Factor = 2 tan(aFOV/2)''')

[[User:Beeswax|Beeswax]] 12:19, 9 Oct 2007 (PDT)