DynDOLOD 3.00 Alpha 182

[z929669]

54 minutes ago, Gamma_Metroid said:

Same result. I updated to alpha 89 as well just in case. Not sure which logs to post since I can't find anything useful in them.

See the OP and post the logs as described. Note the forum posting guidelines in the parent forum. If done as described, the logs indicated may contain clues that most people won't find significant.

[Mousetick]

Apologies in advance if the following are FAQ and/or CSQ (Completely Stupid Questions). I did search https://dyndolod.info/ but couldn't find the answers I'm seeking.

• Are mods like No Sunlight Through Mountains and Majestic Mountains - Patch for Dynamic Volumetric Lighting and Sun Shadows which make mountain meshes double-sided essentially useless with DynDOLOD's Terrain Underside?
• The higher the resolution and the lower the height of the Terrain Underside, the "closer" it follows the shape of the terrain without leaving air gaps underneath or protruding above it, basically forming the other, invisible, side of the terrain. Is this correct?
• Which data are considered for the Terrain, exactly? Is it the shape of the ground only as defined by LAND records, or does it include other things?
• Is it possible that with a sufficiently coarse or deep Terrain Underside, leaving large gaps between it and the terrain, some light rays could shine through it at certain angles when using Enhanced Volumetric Lighting and Shadows (EVLaS)? In which case, the aforementioned mods might still be useful to avoid such "leaks" of light through the full models of loaded cells?
• Does the DynDOLOD tool suggest different resolution and height for Terrain Underside depending on which Low/Medium/High preset is selected? If not, what would be the recommended settings for Low Quality / High Performance, Medium / Medium, and High Quality / Low Performance, for a vanilla SSE?
• What does the Quality setting of Terrain Underside represent exactly, what does it quantify?
• I'm guessing the number of polygons generated for the Terrain Underside varies greatly as the quality is increased/decreased. Is there a way to determine post-facto how many polygons were generated, e.g. in the log?

From https://dyndolod.info/Help/Terrain-Underside:

Quote

In addition consider to uncomment (remove the DoubleSidedTextureMask=mountain,mtn in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAME MODE].ini, so that the object LOD for mountains (the rocks) blocks sun rays as well.

• I'm confused by the term "DoubleSidedTexture". In my mind a texture is like paint applied to a surface, e.g. a mesh, which can have multiple sides. But like a liquid a texture itself doesn't really have "sides"? Could you clarify what DoubleSidedTextureMask mean and correspond to practically?
• What does "mountain,mtn" represent exactly? Are there scenarios, if any, where a user would need to add other values to this list?

Thanks for bearing with all the questions.

[Gamma_Metroid]

1 hour ago, z929669 said:

See the OP and post the logs as described. Note the forum posting guidelines in the parent forum. If done as described, the logs indicated may contain clues that most people won't find significant.

Here are the logs and more examples of .bto files where vertex colors are being lost. https://ufile.io/f/jgnqu What is confounding me is that some objects are retaining vertex colors as they should, but others are not.

[sheson]

6 hours ago, pedxingx said:

Sheson,

I checked the PapyrusUtilDev.log. I don't see any errors related to SHESON_DynDOLOD or LegacyoftheDragonborn.

I believe I am using Legacy of the Dragonborn 5.6.3. That is the file currently sitting on my hard drive. Where can I find this CRC and what CRC do you have?  I can try reinstalling the mod again and check the CRC. I may have installed the wrong version and I don't have MO2 connected to nexus to confirm the currently installed version.

I remember something else. A fewmonths ago, I was troubleshooting another dyndolod problem. I did switch from PapyrusUtil to dyndolod.dll and back. When I did this, I made clean saves each time and ran fallrim. Can that have lasting effects with Dyndolod?

xEdit/xLODgen/DynDOLOD print the CRC32 of plugins in the log or in xEdit in the left tree view Name column.

Background Loader: [LegacyoftheDragonborn.esm] File loaded (CRC32:56140CBA)

For 5.6.3 I get 5C46C844. Did you do any edits maybe?

[sheson]

1 hour ago, Mousetick said:

Apologies in advance if the following are FAQ and/or CSQ (Completely Stupid Questions). I did search https://dyndolod.info/ but couldn't find the answers I'm seeking.

• Are mods like No Sunlight Through Mountains and Majestic Mountains - Patch for Dynamic Volumetric Lighting and Sun Shadows which make mountain meshes double-sided essentially useless with DynDOLOD's Terrain Underside?
• The higher the resolution and the lower the height of the Terrain Underside, the "closer" it follows the shape of the terrain without leaving air gaps underneath or protruding above it, basically forming the other, invisible, side of the terrain. Is this correct?
• Which data are considered for the Terrain, exactly? Is it the shape of the ground only as defined by LAND records, or does it include other things?
• Is it possible that with a sufficiently coarse or deep Terrain Underside, leaving large gaps between it and the terrain, some light rays could shine through it at certain angles when using Enhanced Volumetric Lighting and Shadows (EVLaS)? In which case, the aforementioned mods might still be useful to avoid such "leaks" of light through the full models of loaded cells?
• Does the DynDOLOD tool suggest different resolution and height for Terrain Underside depending on which Low/Medium/High preset is selected? If not, what would be the recommended settings for Low Quality / High Performance, Medium / Medium, and High Quality / Low Performance, for a vanilla SSE?
• What does the Quality setting of Terrain Underside represent exactly, what does it quantify?
• I'm guessing the number of polygons generated for the Terrain Underside varies greatly as the quality is increased/decreased. Is there a way to determine post-facto how many polygons were generated, e.g. in the log?

From https://dyndolod.info/Help/Terrain-Underside:

• I'm confused by the term "DoubleSidedTexture". In my mind a texture is like paint applied to a surface, e.g. a mesh, which can have multiple sides. But like a liquid a texture itself doesn't really have "sides"? Could you clarify what DoubleSidedTextureMask mean and correspond to practically?
• What does "mountain,mtn" represent exactly? Are there scenarios, if any, where a user would need to add other values to this list?

Thanks for bearing with all the questions.

DynDOLOD does not change any full models like these mods do.
Smaller number for quality = higher resolution, same setting and result as terrain LOD generation quality LOD Level 32.
Terrain and terrain LOD uses LAND record height data.
The terrain underside can not block sun shining through objects which are higher than the terrain already. Terrain underside is a bit lower than actual terrain. Terrain LOD Level 32 can not match loaded terrain perfectly.
The low, medium, high preset load different mesh mask and reference rules for object LOD generation. They do not change any other settings. The default quality is always 10.
The quality number is the same setting as terrain LOD generation LOD Level 32. It is the max delta between two height terrain points considered equal. See Fast Polygonal Approximation of Terrains and Height Fields by Michael Garland and Paul Heckbert. The actual best resolution is limited by the max triangle/vertices account allowed in a NIF shape.
You could open the underside NIF in NifSkope to see how many triangles/vertices each shape uses.

See the explanation above the DoubleSidedMeshMask and DoubleSidedTextureMask INI setting:
set the double_sided shader flag .. on these lists of meshes / textures masks (partial filename)
The MeshMask is to match LOD model file names. All shapes/shaders of the LOD model with matching filename are set double sided.
The TextureMask is to match texture file name. All shapes/shaders with a matching texture filename are set double sided.
A filemask is a "text pattern that matches certain filenames".

[Mousetick]

Thanks for all those very instructive answers. I'm afraid I have a few more follow-up questions 

- It seems to me then that the 2 aforementioned double-sided mountain mesh mods would be as essential as DynDOLOD's Terrain Underside in ensuring that sunlight doesn't shine through at certain heights or angles depending on underlying terrain, and that they can cast proper shadows with EVLaS. What do you think? Even though this is not directly related to DynDOLOD, since we're talking about full models, I'd like to know your expert opinion. I've read many conflicting and seemingly misinformed comments on this.

- Each LAND record is a 33x33 grid and Tamriel is ~105x75 cells (I don't know the exact numbers), which gives ~8.5M terrain data points. Does the 'Fast Polygonal Approximation of Terrains and Height Fields' algorithm allows for estimating the [min,max] range of generated triangles for a given data set size and quality? Or is this so highly optimized and dependent on terrain shape that the min/max are unpredictable?

- What happens when the chosen underside quality cause the algorithm to generate more triangles than a NIF shape can contain? From DynDOLOD's point of view, and from the user's point of view. Does DynDOLOD enforces a hard limit: I see that xLODGen uses 32767 by default for LOD Level 32 max number of vertices.

- Is it correct to assume that as the quality increases (smaller quality setting in the UI) the height can be reduced correspondingly (i.e. moving the underside closer to the terrain height in relative terms), as the underside matches the terrain shape more faithfully? Are there any guidelines from your experience on how these 2 inputs can adjusted together, or can it only be done empirically?

- Are there any advantages in moving the underside closer to the terrain using the Height setting, beside preventing large gaps that could leak light through? I'm thinking the shadows cast by the terrain would be more accurate too, but this may not be significant.

- If I understood you correctly, the underside mesh is identical to the terrain LOD mesh Level 32 generated by xLODGen, except that it's one single big piece instead of split into smaller *.btr pieces, and that 'optimize unseen' doesn't apply to the underside. Did I get that right?

- By the way, I guess it's probably the nomenclature used by algorithm, but using decreasing numbers to increase quality is counter-intuitive and not very user-friendly. Oh well, it's too late to change it now

- Is it safe to open Tamriel_Underside.nif for example in NIFSkope without it spinning its wheels and freezing due to the humongous mesh?

- Ok, so DoubleSidedTextureMask=mountain,mtn would match any texture filename containing the strings 'mountain' or 'mtn' anywhere in the name. Is this accurate, or is this just the prefix and the filename must begin with 'mountain' or 'mtn'? Please clarify.

- Let's say I put a huge pyramid in the middle of the Whiterun tundra, and its texture filenames are pyramid_*.dds, and I'd like its LOD to block sunlight. I'd just change DoubleSidedTextureMask to DoubleSidedTextureMask=mountain,mtn,pyramid. Correct?

- Any specific reason why DoubleSidedTextureMask is commented out and not enabled by default? What would be the downside of generating double-sided mountain LODs all the time for all users, even if they're not using EVLaS? 

Thank you very much for your attention and patience.

[sheson]

1 hour ago, Mousetick said:

Thanks for all those very instructive answers. I'm afraid I have a few more follow-up questions 

- It seems to me then that the 2 aforementioned double-sided mountain mesh mods would be as essential as DynDOLOD's Terrain Underside in ensuring that sunlight doesn't shine through at certain heights or angles depending on underlying terrain, and that they can cast proper shadows with EVLaS. What do you think? Even though this is not directly related to DynDOLOD, since we're talking about full models, I'd like to know your expert opinion. I've read many conflicting and seemingly misinformed comments on this.

- Each LAND record is a 33x33 grid and Tamriel is ~105x75 cells (I don't know the exact numbers), which gives ~8.5M terrain data points. Does the 'Fast Polygonal Approximation of Terrains and Height Fields' algorithm allows for estimating the [min,max] range of generated triangles for a given data set size and quality? Or is this so highly optimized and dependent on terrain shape that the min/max are unpredictable?

- What happens when the chosen underside quality cause the algorithm to generate more triangles than a NIF shape can contain? From DynDOLOD's point of view, and from the user's point of view. Does DynDOLOD enforces a hard limit: I see that xLODGen uses 32767 by default for LOD Level 32 max number of vertices.

- Is it correct to assume that as the quality increases (smaller quality setting in the UI) the height can be reduced correspondingly (i.e. moving the underside closer to the terrain height in relative terms), as the underside matches the terrain shape more faithfully? Are there any guidelines from your experience on how these 2 inputs can adjusted together, or can it only be done empirically?

- Are there any advantages in moving the underside closer to the terrain using the Height setting, beside preventing large gaps that could leak light through? I'm thinking the shadows cast by the terrain would be more accurate too, but this may not be significant.

- If I understood you correctly, the underside mesh is identical to the terrain LOD mesh Level 32 generated by xLODGen, except that it's one single big piece instead of split into smaller *.btr pieces, and that 'optimize unseen' doesn't apply to the underside. Did I get that right?

- By the way, I guess it's probably the nomenclature used by algorithm, but using decreasing numbers to increase quality is counter-intuitive and not very user-friendly. Oh well, it's too late to change it now

- Is it safe to open Tamriel_Underside.nif for example in NIFSkope without it spinning its wheels and freezing due to the humongous mesh?

- Ok, so DoubleSidedTextureMask=mountain,mtn would match any texture filename containing the strings 'mountain' or 'mtn' anywhere in the name. Is this accurate, or is this just the prefix and the filename must begin with 'mountain' or 'mtn'? Please clarify.

- Let's say I put a huge pyramid in the middle of the Whiterun tundra, and its texture filenames are pyramid_*.dds, and I'd like its LOD to block sunlight. I'd just change DoubleSidedTextureMask to DoubleSidedTextureMask=mountain,mtn,pyramid. Correct?

- Any specific reason why DoubleSidedTextureMask is commented out and not enabled by default? What would be the downside of generating double-sided mountain LODs all the time for all users, even if they're not using EVLaS? 

Thank you very much for your attention and patience.

If you see the sun shining through buildings or mountain rock object, install those mods.
The algorithm uses the (error) delta and a max vertices value - as you can see from  the xLODGen terrain LOD mesh options. While Skyrim NIF supports 65536 vertices, the max is simply half to assure the max limit of triangles (also 65536) is never surpassed. Max vertices trumps delta. Lowest deltas are discarded first, obviously. Flat terrain will have very few vertices/triangles, rough will have lots. Simply check file sizes of terrain LOD meshes.
With a max limit of 32767 vertices it is not possible to have more than 65536 triangles.
The more detailed the terrain underside mesh is, the closer it can be to the real terrain without it breaking through.  No guidelines. Simply lower it if it sticks through.
There are no other advantages I know of.
The underside mesh is not one single piece. It is the LOD Level 32 meshes combined into a single NIF with flipped faces. Each LOD quad is separate.  Quads outside the view frustum are culled.
The Quality setting is the allowed error. 0 = no error. Readmes and hints explain what settings mean.
The underside mesh is normal NIF and can be opened in NifSkope.
As the terms "mask" and "partial filename" suggest it is a *[whatever]* of the filename, like all usage "masks"  and "partial whatever" everywhere else
Yes
The doublesided flag can have a performance penalty. It can have unwanted visual results. It is also unclear (I never personally tested) if it has the desired effect. It was added as a feature request.

[sheson]

12 hours ago, Gamma_Metroid said:

Here are the logs and more examples of .bto files where vertex colors are being lost. https://ufile.io/f/jgnqu What is confounding me is that some objects are retaining vertex colors as they should, but others are not.

Can you edit C:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_WrldMorrowind.txt and remove all lines for the references but one for a LOD models that have vertex colors for all the LOD levels.

Then start DynDOLOD in Expert mode, select the worldspace and Execute LODGen. Should generate on BTO per Level with just that LOD model.

Let me know if the vertex colors are kept then.

[Mousetick]

Last comments and questions, I promise 

12 hours ago, sheson said:

With a max limit of 32767 vertices it is not possible to have more than 65536 triangles.

The underside mesh is not one single piece. It is the LOD Level 32 meshes combined into a single NIF with flipped faces.

From that I'm inferring that DynDOLOD always uses a max of 32K for each LOD Level 32 quad when generating the underside, since it's not adjustable in the UI. Right? There are 60 LOD quads in Tamriel. In the absolute worst case, the Tamriel underside NIF would be made of meshes of up to 32K vertices, 60 of them, totaling 1.9M vertices. Does my math seem right to you? If not please correct me.

13 hours ago, sheson said:

The Quality setting is the allowed error. 0 = no error. Readmes and hints explain what settings mean.

Ah! So the quality setting is basically the max allowed deviation. Now that makes a lot more sense.

I'm not disputing the fact that the meaning of the settings is documented if the user pays attention to the tooltips or RTFM. I'm just saying the label is counter-intuitive, which makes it harder than necessary for the average user to understand, and makes the term 'quality' ambiguous and confusing, as our present discussion can demonstrate, since we have to qualify it every time to clarify what we're exactly talking about.

Decreasing the max allowed deviation increases the definition/resolution/fidelity of the underside which increases its quality. Would you disagree?

Speaking of, the Height label is similarly confusing and counter-intuitive. Height is usually understood to be an absolute measure, here it's used to specify what is actually a distance, a relative measure.

Please don't take my comments the wrong way. Take them as constructive criticism for possible future improvements or additions you may want to make. I believe using more intuitive and unambiguous terminology would help users and it would help you as well, by spending less time answering questions or writing documentation, allowing you to focus on more important tasks.

14 hours ago, sheson said:

The doublesided flag can have a performance penalty. It can have unwanted visual results. It is also unclear (I never personally tested) if it has the desired effect. It was added as a feature request.

Quite interesting. EVLaS' developer states outright that it's completely useless, it does nothing. Quote from the mod's comments section on Nexus:

Quote

Ignore the DoubleSided options, they're actually useless. LODs are completely ignored by the shadows no matter if double sided or not. I'm currently digging around the game to see if that can be forced some other way at runtime but that could take a while, so for now the underside is your only option.

Based on your input and the statement above, I'm going to turn off the DoubleSided LOD options and use a double-sided full model mod.

Thanks again. 

[Gamma_Metroid]

9 hours ago, sheson said:

Can you edit C:\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_WrldMorrowind.txt and remove all lines for the references but one for a LOD models that have vertex colors for all the LOD levels.

Then start DynDOLOD in Expert mode, select the worldspace and Execute LODGen. Should generate on BTO per Level with just that LOD model.

Let me know if the vertex colors are kept then.

Still the same result. Vertex colors are dropped at LOD8+: https://ufile.io/f/ntm43

[pedxingx]

On 5/8/2022 at 8:32 PM, sheson said:

xEdit/xLODgen/DynDOLOD print the CRC32 of plugins in the log or in xEdit in the left tree view Name column.

Background Loader: [LegacyoftheDragonborn.esm] File loaded (CRC32:56140CBA)

For 5.6.3 I get 5C46C844. Did you do any edits maybe?

I found out I had an older version of Legacy of the Dragonborn installed. I updated to the latest version of 5.6.3 and now I have the same CRC as you.  I made another clean save and rebuilt the dyndolod output again. I still have the same problem with the guild house disappearing on me.

[sheson]

7 hours ago, pedxingx said:

I found out I had an older version of Legacy of the Dragonborn installed. I updated to the latest version of 5.6.3 and now I have the same CRC as you.  I made another clean save and rebuilt the dyndolod output again. I still have the same problem with the guild house disappearing on me.

I was able to reproduce, will be fixed next version.

[David2408]

Hey sheson, I have a question regarding DynDOLOD grass LOD and ENB complex grass. 

If using complex grass compatible textures for a grass mod (e.g. Folkvangr) and I have pre-built grass cache and grass LOD from a point in time before I had installed complex grass compatible textures, would I need to rerun grass caching and grass LOD generation? 

In other words, I am interested to learn about possible interaction between ENB complex grass, grass caching and DynDOLOD grass LOD - if there is any.

[sheson]

38 minutes ago, David2408 said:

Hey sheson, I have a question regarding DynDOLOD grass LOD and ENB complex grass. 

If using complex grass compatible textures for a grass mod (e.g. Folkvangr) and I have pre-built grass cache and grass LOD from a point in time before I had installed complex grass compatible textures, would I need to rerun grass caching and grass LOD generation? 

In other words, I am interested to learn about possible interaction between ENB complex grass, grass caching and DynDOLOD grass LOD - if there is any.

Regarding grass cache, refer to NGIO description https://www.nexusmods.com/skyrimspecialedition/mods/42161
"IMPORTANT: If you change anything about your mods or grass related settings you need to delete every file in that directory so that grass can be generated again, or you will not see any changes or even have bugs like floating grass (if terrain is changed) or grass in objects (if object placement is changed). If you only change drawing distance it's not required to delete cache files."

Grass cache contains used grass NIF, positions, rotation. If only the textures of grass are replaced and nothing else,  then that does not change grass cache positions.

https://dyndolod.info/Help/Grass-LOD#Updating

[David2408]

23 minutes ago, sheson said:

Regarding grass cache, refer to NGIO description https://www.nexusmods.com/skyrimspecialedition/mods/42161
"IMPORTANT: If you change anything about your mods or grass related settings you need to delete every file in that directory so that grass can be generated again, or you will not see any changes or even have bugs like floating grass (if terrain is changed) or grass in objects (if object placement is changed). If you only change drawing distance it's not required to delete cache files."

Grass cache contains used grass NIF, positions, rotation. If only the textures of grass are replaced and nothing else,  then that does not change grass cache positions.

https://dyndolod.info/Help/Grass-LOD#Updating

Thank you for pointing me in the right direction! The complex grass compatible textures are the only update I made to my grass mod setup, so with your hint I assume I will not need a new cache.