[Answered] Why are Second Life LOD naming conventions opposite of industry standard?

[Kriss Lehmann]

With the latest update to Mesh uploading, I started noticing a problem very quickly. My highest poly model started tripping the "material subset" error.

After some reading, I saw the notice that model imports now have a strict LOD naming convention for "auto matching":
LOD 2 is for Medium LOD
LOD 1 is for Low LOD
LOD 0 is for Lowest LOD

Unfortunantly, this runs counter to multiple platforms (Unreal, Unity, CryEngine) that I've encountered: 
LOD 0 (or not using an LOD prefix) is for the highest polygon count
LOD 1 is for the second highest
LOD 2 is for the third highest
etc, etc.

This rule is what made my initial model upload trip the "material subset" error (Something you would normally see for a faulty material lower in the LOD stack).

This matching feature can be turned off by invoking the "ImporterLegacyMatching" debug setting, allowing you to use any name for your LOD uploads, but my question is this:

Why is this strict naming convention the opposite of the industry standard at all?

A quick search will show that Unity, Unreal and CryEngine all use the LOD 0, LOD 1, LOD 2, LOD 3 naming convention for highest to lowest LOD models.

 

[ObviousAltIsObvious]

what standards document specifies this?

 

[Kriss Lehmann]

I can not point to an official standards document, so please feel free to substitute "industry standard" with "naming convention used by the larger public 3D engines (listed) within the the gaming industry". Thank you for the response.

[Drongle McMahon]

No doubt you won't find this answer satisfactory, but here it is anyway...

There are two intuitive, but opposite ways of ordering LOD (levels of detail). On the one hand, you might think it obvious that that the highest number should indicate the highest detail. On the other hand, you might think that the lowest number should indicate what's seen at the shortest distance (which to me seems a little less obvious).

It so happens that the former of these Obvious Alternatives (sorry) was chosen by the earliest coders of SL. Thus in llvolume.h we find "const S32 MIN_LOD = 0; const S32 MAX_LOD = 3;", where MAX_LOD is used to indicate the maximum level of detail. So that choice was embedded in the code from the very start. Now when the developers came to coin the new naming convention, it was natural for them to use the numbering that was already implicit in the code, avoiding the need for conversion, and probably minimising the likelihood of errors.

Personally, I find the naming convention cumbersome, or even obstructive. I believe (last time I looked, at least - see wiki comment) that as long as you avoid any "_LODx" suffixes, you can obtain the old behaviour irrespective of the setting of ImporterLegacyMatching. So with Blender, where alphabetical ordering in the exporter can be used to control the associations in LODs of multi-mesh models, there are no problems. That means you can still use the same dae file at different LODs, something I used to do quite often when optimising LODs for different purposes, without having to go in and rename the meshes in all the files every time.

[Kriss Lehmann]

Actually, That was a very satisfactory answer! Thank you very much, Drongle.