Understanding Mountain LOD

[z929669]

This is not a DynDOLOD problem.

Trying to understand vanilla mountain LOD. It seems quite nonsensical on its face. What am I missing?

Example: EditorIDs MountainCliffCrevasse and MountainCliffCrevasse_HeavySN both use the same NIF, and the following doesn't make much sense to me, so I'm asking your opinion: Is it a mistake or just laziness? The base model is the same in both cases, but the DNAM is different:

No material, but using a light Level0 (but not at the other levels)

Material and using a heavy at Level0 (but not at the other levels)

Obviously, these look like two similar but inconsistent treatments. DynDOLOD lets us extend Level0 treatment to other levels but at the expense of performance.

 

[sheson]

MountainCliff01_LOD_0L.nif and LOD\Mountains\MountainCliff01_LOD_0H.nif are different versions for the HD snow LOD shader. Without any shader they will look the same.

There are 3 "versions" possible with these 2 LOD models.. No Snow (000485BF), Light Snow (00048DDF ), Heavy Snow (00048DE0).

The HD LOD shaders are made to work with the full normal map textures.

https://dyndolod.info/Help/Snow-Ash-LOD-Shader

[DoubleYou]

How does DynDOLOD detect the models for this? Will it use a LOD\Mountains\MountainCliff01_LOD_1H.nif, 2H, 3H if available?

[sheson]

46 minutes ago, DoubleYou said:

How does DynDOLOD detect the models for this? Will it use a LOD\Mountains\MountainCliff01_LOD_1H.nif, 2H, 3H if available?

It does check the DNAM for H version and prefers it over filename matching.
If full filename matches with L version and there is _heavysn  in EditorID it uses H version if it exists.
HD LOD snow shader only if full textures are used.

[z929669]

10 hours ago, sheson said:

MountainCliff01_LOD_0L.nif and LOD\Mountains\MountainCliff01_LOD_0H.nif are different versions for the HD snow LOD shader. Without any shader they will look the same.

There are 3 "versions" possible with these 2 LOD models.. No Snow (000485BF), Light Snow (00048DDF ), Heavy Snow (00048DE0).

The HD LOD shaders are made to work with the full normal map textures.

https://dyndolod.info/Help/Snow-Ash-LOD-Shader

Looking a bit further into more examples ... what about 0004157F .... this uses MountainCliffSlope_LightSN [STAT:0006E03F], which is assigns for Level0 as "meshes\lod\mountains\mountaincliffslope_lod_0.nif" by DynDOLOD but has no such MNAM NIF defined:

so ...

lod\mountains\mountaincliffslope_lod_0.nif   (DynDOLOD Level0)

LOD\Mountains\MountainCliffSlopeSnow_LOD_1.nif   (Skyrim.esm Level0)

According to the doc you linked, this would automatically be part of objSnow due to the EditorID string itself, but DynDOLOD is not seemingly assigning the expected LOD NIF.

I'm not questioning if this is correct or not, just trying to understand what appear to me to be exception(s).

[sheson]

53 minutes ago, z929669 said:

Looking a bit further into more examples ... what about 0004157F .... this uses MountainCliffSlope_LightSN [STAT:0006E03F], which is assigns for Level0 as "meshes\lod\mountains\mountaincliffslope_lod_0.nif" by DynDOLOD but has no such MNAM NIF defined:

so ...

lod\mountains\mountaincliffslope_lod_0.nif   (DynDOLOD Level0)

LOD\Mountains\MountainCliffSlopeSnow_LOD_1.nif   (Skyrim.esm Level0)

According to the doc you linked, this would automatically be part of objSnow due to the EditorID string itself, but DynDOLOD is not seemingly assigning the expected LOD NIF.

I'm not questioning if this is correct or not, just trying to understand what appear to me to be exception(s).

Check the DynDOLOD_SSE_Object_Report.txt if you want to know which LOD level has which LOD model assigned, by default the LOD levels from the last / rule applies:

	Level0: meshes\lod\mountains\mountaincliff01_lod_0l.nif using textures\landscape\mountains\mountainslab02.dds, textures\landscape\mountains\mountainslab02_n.dds
	Level1: meshes\lod\mountains\mountaincliff01_lod_1.nif using textures\lod\mtncliff01lod.dds, textures\lod\mtncliff01lod_n.dds
	Level2: meshes\lod\mountains\mountaincliff01_lod_2.nif using textures\lod\mtncliff01lod.dds, textures\lod\mtncliff01lod_n.dds
	LOD4: Level0
	LOD8: Level1
	LOD16: Level2

What LOD NIF did you expect it to assign? As explained since 2014, LOD models are matches based on the full model filename and rules. H versions are the exception, since HD LOD and heavy light/snow are crucial to stay consistent.

[z929669]

21 minutes ago, sheson said:

What LOD NIF did you expect it to assign? As explained since 2014, LOD models are matches based on the full model filename and rules. H versions are the exception, since HD LOD and heavy light/snow are crucial to stay consistent.

LOD\Mountains\MountainCliffSlopeSnow_LOD_1.nif 

... as referenced for this EID in the plugin

[sheson]

The EDID is checked for "_heavysn" to determine if H version should be used.

LOD models are matched on the full model filename.

DynDOLOD 3 does not use the limiting snow/brown/green/yellow LOD vanilla filenames anymore. DynDOLOD 3 now properly supports texture replacements. The full textures defined in the DynDOLOD Resources LOD models are on the fly replaced with the full textures defined by the alternate textures list, which then get translated to their stitched LOD textures version. So THAT actually changed with DynDOLOD 3 (Major Feature Changes: Automatic texture replacements for stitched object LOD textures.).

Edit, I copied pasted wrong from my object report. This is what I really get for it

MountainCliffSlope_LightSN [STAT:0006E03F] Meshes\landscape\mountains\mountaincliffslope.nif [CRC32:4EBE0826] using textures\landscape\mountains\mountainslab02.dds, textures\landscape\mountains\mountainslab02_n.dds, textures\landscape\dirt02.dds, textures\landscape\dirt02_n.dds, textures\landscape\rocks01.dds, textures\landscape\rocks01_n.dds
	mountaincliffslope_lod_0.nif MountainCliffSlope:2 = textures\landscape\dirt02.dds -> textures\landscape\snow01.dds
	mountaincliffslope_lod_1.nif MountainCliffSlope:2 = textures\landscape\dirt02.dds -> textures\landscape\snow01.dds
	mountaincliffslope_lod_2.nif MountainCliffSlope:2 = textures\landscape\dirt02.dds -> textures\landscape\snow01.dds
	Level0: meshes\lod\mountains\mountaincliffslope_lod_0.nif using textures\landscape\mountains\mountainslab02.dds, textures\landscape\mountains\mountainslab02_n.dds, textures\landscape\dirt02.dds, textures\landscape\dirt02_n.dds
	Level1: meshes\lod\mountains\mountaincliffslope_lod_1.nif using textures\landscape\mountains\mountainslab02.dds, textures\landscape\mountains\mountainslab02_n.dds, textures\landscape\dirt02.dds, textures\landscape\dirt02_n.dds
	Level2: meshes\lod\mountains\mountaincliffslope_lod_2.nif using textures\landscape\mountains\mountainslab02.dds, textures\landscape\mountains\mountainslab02_n.dds, textures\landscape\dirt02.dds, textures\landscape\dirt02_n.dds

You can see how it reports the replacement from default dirt to snow texture
"textures\landscape\dirt02.dds -> textures\landscape\snow01.dds"

[z929669]

9 minutes ago, sheson said:

The EDID is checked for "_heavysn" to determine if H version should be used.

LOD models are matched on the full model filename.

DynDOLOD 3 does not use the limiting snow/brown/green/yellow LOD vanilla filenames anymore. DynDOLOD 3 now properly supports texture replacements. The full textures defined in the DynDOLOD Resources LOD models are on the fly replaced with the full textures defined by the alternate textures list, which then get translated to their stitched LOD textures version. So THAT actually changed with DynDOLOD 3.

OK, thanks ... where can I find the alternate textures list, or is this created dynamically based on the LO? Or do you meant the alt textures defined by plugin texture set?

[z929669]

1 hour ago, sheson said:

Edit, I copied pasted wrong from my object report. This is what I really get for it

MountainCliffSlope_LightSN [STAT:0006E03F] Meshes\landscape\mountains\mountaincliffslope.nif [CRC32:4EBE0826] using textures\landscape\mountains\mountainslab02.dds, textures\landscape\mountains\mountainslab02_n.dds, textures\landscape\dirt02.dds, textures\landscape\dirt02_n.dds, textures\landscape\rocks01.dds, textures\landscape\rocks01_n.dds
	mountaincliffslope_lod_0.nif MountainCliffSlope:2 = textures\landscape\dirt02.dds -> textures\landscape\snow01.dds
	mountaincliffslope_lod_1.nif MountainCliffSlope:2 = textures\landscape\dirt02.dds -> textures\landscape\snow01.dds
	mountaincliffslope_lod_2.nif MountainCliffSlope:2 = textures\landscape\dirt02.dds -> textures\landscape\snow01.dds
	Level0: meshes\lod\mountains\mountaincliffslope_lod_0.nif using textures\landscape\mountains\mountainslab02.dds, textures\landscape\mountains\mountainslab02_n.dds, textures\landscape\dirt02.dds, textures\landscape\dirt02_n.dds
	Level1: meshes\lod\mountains\mountaincliffslope_lod_1.nif using textures\landscape\mountains\mountainslab02.dds, textures\landscape\mountains\mountainslab02_n.dds, textures\landscape\dirt02.dds, textures\landscape\dirt02_n.dds
	Level2: meshes\lod\mountains\mountaincliffslope_lod_2.nif using textures\landscape\mountains\mountainslab02.dds, textures\landscape\mountains\mountainslab02_n.dds, textures\landscape\dirt02.dds, textures\landscape\dirt02_n.dds

You can see how it reports the replacement from default dirt to snow texture
"textures\landscape\dirt02.dds -> textures\landscape\snow01.dds"

OK, so is this what you mean by "alternate textures"? So if the LOD model matching the mesh rule (path string for example) references textures\landscape\snow01.dds, even though the NIF defined by the plugin references textures\landscape\dirt02.dds, then DynDOLOD understands it's an alternate texture?

I assume the alternate must adhere to dimension protocol to be used as expected and indicated in this report.

If this is the case, then there is nothing to do for the author but make the textures and point to them from the LOD mesh.

[sheson]

1 hour ago, z929669 said:

OK, thanks ... where can I find the alternate textures list, or is this created dynamically based on the LO? Or do you meant the alt textures defined by plugin texture set?

It gets the new textures for a 3D Name from the linked TXST records from the Alternate Texture list of the base record and saves the list for the current load order to the export folder, for example LODGen_SSE_AltTextures_Tamriel.txt. LODGen uses that information to replace the full textures of the matching 3D Names  (in the LOD model - or full model if used for LOD) as explained earlier. The full texture is replaced by the stitched object LOD texture defined in LODGen_SSE_ObjectAtlasMap_Tamriel.txt. The stitched object LOD texture is replaced by its version on the object LOD texture atlas.

To recap, models can have a snow shader covering all shapes and/or a shape that uses a snow texture. Those are different things with different filename and EDID conventions.

11 minutes ago, z929669 said:

OK, so is this what you mean by "alternate textures"? So if the LOD model matching the mesh rule (path string for example) references textures\landscape\snow01.dds, even though the NIF defined by the plugin references textures\landscape\dirt02.dds, then DynDOLOD understands it's an alternate texture?

I assume the alternate must adhere to dimension protocol to be used as expected and indicated in this report.

If this is the case, then there is nothing to do for the author but make the textures and point to them from the LOD mesh.

Unfold [+] Model in xEdit to see the list of MODS - Alternate Textures.

If the LOD model is done properly (e.g. the DynDOLOD 3 version) with defining the same full textures and shape name (3D Names) as the full model, replacement will work automatically.

[z929669]

46 minutes ago, sheson said:

It gets the new textures for a 3D Name from the linked TXST records from the Alternate Texture list of the base record and saves the list for the current load order to the export folder, for example LODGen_SSE_AltTextures_Tamriel.txt. LODGen uses that information to replace ...

Unfold [+] Model in xEdit to see the list of MODS - Alternate Textures.

If the LOD model is done properly (e.g. the DynDOLOD 3 version) with defining the same full textures and shape name (3D Names) as the full model, replacement will work automatically.