Issues with DynDOLOD mountain LOD texture and meshes

[Letho]

Hi Sheson, I started using DynDOLOD a few days ago and I love this mod and your great work for the modding community (memory patch, etc.). I have recently run into a few issues though. Let me go through it step by step.

 

1. I have RTFM and watched GamerPoets (Michael's) tutorial DynDOLOD from start to finish. I'm still having the general problem, that I don't fully understand some things from a technical side, so my issue probably originates there. Nevertheless I am posting some screenshots of the problem itself instead of writing a n00b's wall of text of questions related to DynDOLOD in general^^

 

2. What I have done so far

I have installed the tree billboard and the DynDOLOD ressources after installing the scripting dependencies (SKSE+Papyrus Utils). After that I have installed SMIM, ELFX and my retexture (Skyrim Realistic Overhaul) mods and overwrote everything.

After that I ran TexGen and DynDOLOD /w @high, using the default mesh rules and all extra shinies (lights, windows, glow, etc.)

 

3. The issue I am having

There is a mountain with some snowy rubble outside of Whiterun (circled red in the screenshot), and a mountain rock (circled blue in the screenshot), that will make a great example. The game switching from LOD to the full model makes an extremely visual difference and thus kills the immersion heaviliy. I have screenshoted both variants and wrote the refId next to the objects:

 

 

 

___LOD___

 

 

 

___FULL MODEL___

 

 

4. There is still one general question about LOD I have to ask, because I find it very confusing:

The rubble part (refId=0004d6ff) only has 4LOD assigned to it - 8LOD+ is blank. Nevertheless I see the LOD model from high distances, shouldn't it fade out as soon I leave the 4LOD distance?

 

 

Is DynDOLOD assigning wrong textures to the LOD mesh? I know this happens to windmills and farmhouses as well, but they are - if I understood Michael correctly - stored in a prerendered texture-Atlas and hence uneditable for DynDOLOD. How could i "fix" my problem? I tried using LOD4/8/16 FULL models for the backslash-rule but DynDOLOD froze after 2,5hours after having created 80k of 257k references for DynDOLOD in the log.

 

Thanks for this forum and for still supporting DynDOLOD!

 

Cheers,

Letho

Edited June 23, 2017 by Letho

[sheson]

3. 

 

DynDOLOD does not change how LOD works in the engine. Everything past the loaded cells is LOD area, which typically means the full models are replaced by lower quality LOD models. Since the engine simply switches between models instead of morphing there is always a visual change when that switch happens.

 

You can use DynDOLOD mesh rules to set base records of objects or specific reference to use the full model in LOD level 4. Then the shape and texture are identical when the switch happens and only lighting/shadow/decals/snow shader are different. This can have the worse side effect that the is even more obvious because both full and LOD model exist at the same time for a second and cover each other perfectly in 3D space causing flicker. Skryim SE switch has slightly better fading in this regard.

 

 

4.

 

If no LOD model is assigned to LOD level 8, then those objects will not have LOD in that level. However it sounds like you are looking up default LOD assignment of the base record in CK, xEdit. DynDOLO overwrites those with its mesh rules, unless you check the box "Use orginal LOD assignments"

 

 

In regards to texture, the are two things that can happen. Either a LOD model use pre-rendered LOD textures - like Windmills (but not the Riverwood style Farmhouses) or that a replacement texture on a base record  has no specific LOD model for the replaced texture. The first requires manually updated/crafted LOD textures. The last can only happen with mods using yet undefined replacement textures. It is a bit more complicated to explain. For example, if you happen to have a full model landscape texture being snow white change to brown dirt LOD. It is a crutch I need to keep from vanilla LOD for now. If I ever could find the time to update all suitable vanilla LOD models that could be more automated, but the crutch typically works good enough and is quickly updated for new mods.

 

 

There is no way the engine can support full models for LOD4 for everything mesh rule. LOD models are typically

 

What you could try is creating a mesh rule for the folders "landscape\mountains\" and "landscape\unique\" with LOD4 set to full model, then either LOD8 set to static LOD4 and LOD16 set to static LOD8, or just keep 8/8 and 16/16, VWD checked, Far LOD etc. That can work, but you need to get used to a different type of flicker/transition because of lighting/shadows/decals/snow shaders as explained above.

Edited June 23, 2017 by sheson

[Letho]

Thx for the fast reply!

 

(...) Then the shape and texture are identical when the switch happens and only lighting/shadow/decals/snow shader are different.

 

I erroneously thought lighting/shadows/decals/snow shader were all part of the texture information and changed alongside the texture and hence using the same model for every LOD level would make the switching invisible to the player's eye. Bad mistake, obviously :(

 

 

If no LOD model is assigned to LOD level 8, then those objects will not have LOD in that level. However it sounds like you are looking up default LOD assignment of the base record in CK, xEdit. DynDOLO overwrites those with its mesh rules, unless you check the box "Use orginal LOD assignments"

 

 

Base records and references are like classes and instances in coding, is that correct?

 

What exactly does it mean to not have LOD in a specific level? Let me give an example: In the vanilla game an object "abc.nif" (base record) has a model defined for LOD level 4. Higher levels don't have a LOD mesh. Whenever I walk out of LOD4 range ingame, the model should totally vanish, right? So the engine will not automatically use the lowest LOD models as models for higher LOD levels.

 

 

 

(...) that a replacement texture on a base record  has no specific LOD model for the replaced texture. (...) The last can only happen with mods using yet undefined replacement textures.

 

Would you mind explaining that a litte more? I was thinking that every LOD model has it's own LOD texture attached to it and that TexGen would create those textures for every LOD level (btw.: base on what rules? If there is no LOD8 for a specific model, will TexGen create no LOD8 texture? If not, can we make it happen by using DynDOLOD to create LOD8 meshes and then rerun TexGen? How can mods use undefined replacement textures?

 

 

What you could try is creating a mesh rule for the folders "landscape\mountains\" and "landscape\unique\" with LOD4 set to full model, then either LOD8 set to static LOD4 and LOD16 set to static LOD8, or just keep 8/8 and 16/16, VWD checked, Far LOD etc. That can work, but you need to get used to a different type of flicker/transition because of lighting/shadows/decals/snow shaders as explained above.

 

This touches another aspec of DynDOLOD that I did not understand from neither the manual nor Michael's video: Let me take the example from above: "abc.nif" hase a LOD4 model, but no LOD8/16/...

 

1. What will visible when distant exactly do in this case, when checked and all LOD levels are set to Full Model? I would assume it would only replace the LOD4 by the full model and ignore 8/16 as the LOD4 is the only one that has a predefined LOD model.

2. What exactly do the _FAR model and billboard options do?

3. The other options are the DynDOLOD options and they only apply to dynamic LOD, that being animated objects like water falls, etc. and those that are dynamically added to the world during a game session, correct?

 

Sorry for all my questions, but I am very curious and always want to fully understand stuff (I am not a total coding beginner for I am writing lua based addons for ESO, but that doesnt help much with gfx related things :))

[sheson]

Base records and references are like classes and instances in coding, is that correct?

yes, you could say it that way. LOD typically is defined on the base record level, so it equally affects all references using that base record.

 

What exactly does it mean to not have LOD in a specific level? Let me give an example: In the vanilla game an object "abc.nif" (base record) has a model defined for LOD level 4. Higher levels don't have a LOD mesh. Whenever I walk out of LOD4 range ingame, the model should totally vanish, right? So the engine will not automatically use the lowest LOD models as models for higher LOD levels.

If MNAM data is used and a LOD level is not defined for a LOD level, there will be no LOD for this object in that level.

With the default settings of DynDOLOD, the MNAM - Distant LOD definitions of base records typically are ignored and do not matter unless they are used for fallback, because a filename match was not possible.

Setting a LOD level for a mesh mask/reference formid rule means it should use the defined LOD model for that level if such a LOD model exists. See DynDOLOD_Mod_Authors.html for how the filename of the LOD models define to which LOD Level they belong to.

 

Generally, the engine does not use single LOD models directly for LOD. The engine uses pre-computed supermeshes. The MNAMs is just data for CK/TES5LODGen, while DynDOLOD uses rules and filename conventions before falling back on MNAM data.

 

I was thinking that every LOD model has it's own LOD texture attached to it and that TexGen would create those textures for every LOD level (btw.: base on what rules? If there is no LOD8 for a specific model, will TexGen create no LOD8 texture? If not, can we make it happen by using DynDOLOD to create LOD8 meshes and then rerun TexGen? How can mods use undefined replacement textures?

Because of how Bethesda setup LOD in the first place you will find similar LOD models with just different textures.

mountaincliffslope_lod_0.nif

mountaincliffslopegreen_lod_0.nif

mountaincliffslopesnow_lod_0.nif

mountaincliffslopeyellow_lod_0.nif

 

These were then manually assigned through NMANs. DynDOLOD mimics that idea by having a list DynDOLOD_TES5_textures_names.txt which matches texture sets to those names green, snow, yellow and many more. You will then find a lot of models in DynDOLOD Resources using these names. Thus my notion if a mod uses new/undefined texture sets I might need to add the required data for it to make textures match - if falls back to the default model instead, typically brown / dirt but not always.

TexGen updates all these.

 

In addition, DynDOLOD can also automatically apply texture set replacements to LOD models, however, this only works with LOD models I created specifically for this purpose. The default method mostly just works fine but requires manual additions for new mods that require them - that is typically just new lands mods. I might add that Fallout4 does this better, because its material sets also define LOD textures replacements.

 

There are just LOD textures. They do not really have levels. Different quality LOD models intended for different LOD levels typically share all the same LOD texture. All supermeshes for all LOD levels share the same atlas texture.

 

TexGen uses text files with its own type rules how to copy/resize/paste single hi-res textures into single/mini atlas LOD textures which are then later used for the atlas creation. See "How to add LOD textures creation rules to TexGen" in DynDOLOD_Mod_Authors.html

 

DynDOLOD/TexGen does not create LOD meshes - if you mean taking a full model and decimate it. Creating LOD meshes requires specialized software and manual labor. DynDOLOD + LODGen.exe use LOD models found in the load order and creates supermeshes "Static Object LOD" *.BTO

 

 

1. What will visible when distant exactly do in this case, when checked and all LOD levels are set to Full Model? I would assume it would only replace the LOD4 by the full model and ignore 8/16 as the LOD4 is the only one that has a predefined LOD model.

2. What exactly do the _FAR model and billboard options do?

3. The other options are the DynDOLOD options and they only apply to dynamic LOD, that being animated objects like water falls, etc. and those that are dynamically added to the world during a game session, correct?

1. Entirely depends on the rule which applies in this case.

2. _FAR is for LOD models used in Oblivion. It is a xLODGen setting required for Skyblivion worldspaces. Billboard means to use a billboard texture with an automatically created 2D flat meshes X in static LOD. It is kind of explained in file:///C:/Skyrim/DynDOLOD/Docs/trees.ultra/DynDOLOD-Trees.html

3. the DynDOLOD options are nicely explained in the edit window after double clicking a rule and hopefully somewhat in the Configuration section of DynDOLOD_Manual.html

Edited June 23, 2017 by sheson

[Letho]

Tanks for your detailed reply again, it helped me a lot to correct some wrong concepts in my mind! Since Skyrim Realistic Overhaul is a pure retexture without any other files than *.dds, I don't think it uses new or undefined texture sets. Quite strange :/

 

One last thing though:

 

 

3. the DynDOLOD options are nicely explained in the edit window after double clicking a rule and hopefully somewhat in the Configuration section of DynDOLOD_Manual.html

I would rather call them "labeled"^^ My main problem is that I have never moded and I don't fully understand the exact difference between dynamic LOD and static LOD and how both come into play. This is from the manual, regarding DynDOLOD configuration:

 

 

The filter rules Grid and Reference apply to dynamic object LOD. 'Far' and 'Near' refer to the Far/NearGridToLoad setting. A 'Never Fade' is visible at any distance. 'LOD' means to use a LOD model if available or fall back to a full model if needed. 'Full' will always use a full model even if a LOD model is available.

If I understood Michael correctly, dynamic LOD is exclusively used for models, that are animated (water falls, wind mills, etc.) or those that are added to the game world while in the middle of a gaming session (e.g. a completed quest adding a new tree in whiterun, after geting the small tree from that ancient tree in the green cave). If this is correct, a rock or a mountain is always static and as such precompiled on loading a savegame or starting the game (don't know where precompiled stuff is loaded). So the only options of interest when creating Rock/Mountain LOD are The LodGenOptions: LOD 4,8,16,vwd. The DynDOLOD options: 'grid' and 'reference' have no impact on those and can be left blank, right?

Edited June 23, 2017 by Letho

[sheson]

So the vanilla has 2D tree LOD and static object LOD (and Terrain LOD that DynDOLOD not yet touches).

 

These pre-computed LODs are just many static supermeshes/texture files that are loaded and displayed at fixed positions. To change them they need to be generated again. They basically have no features/functionality. They are just really large models that have idea about the models or their properties that were used to create them.

 

Then there is this setting (Is Full LOD / Neverfade) that allows to show full models with all their function/features in the LOD area past the loaded cells. Typically used for clouds/fog in the mountains. References using this feature are always active and culled by the pre-computed occlusion, which means having a lot of them to improve the distance quickly becomes a resource and performance problem.

 

So I "invented" dynamic LOD, which is explained in the manual in the section "DynDOLOD Mod". So with the definition of the Near / Far Grid those models are disabled when at certain distances, allowing for more of them to be used overall in the entire world. For exactly the waterfalls, windmills, the whiterun tree, fires etc. being the main purpose.

 

The dynamic LOD is also used for what could have been static LOD, but is an object in the game, that enables/disables based on quests. There are like a few buildings and landscape features that change over time when playing the game. Helgen for example, everything is fine and all the buidlings are broken.

 

The vast majority of landscape features and buildings etc is static LOD, though. If you leave the dynamic options blank than those meshes/reference that can not (by definition) be in static LOD because they are quest enabled/disabled will not get dynamic LOD either (which is mostly how vanilla LOD treats them).

Edited June 23, 2017 by sheson

[Letho]

Thanks for all the explanations! I will use your method, setting "landscape\mountains\" and "landscape\unique\" with LOD4 to full model and let you know how it worked out!

 

Btw. in your manual you refer to Michael's tutorial for learning how to make mesh rules. Michael explains, that mesh rules ending with a backslash will PREVENT DynDOLOD from creating LOD for the files in that folder. So I reckon either you mistyped in your first post and it should be "landscape\mountains" (= no backslash at the end) in order to generate LOD for all mountain files, or rather Michael got it wrong^^

[sheson]

Nowadays either will work. \ at the end it doesn't matter really anymore.

Edited June 23, 2017 by sheson

[Letho]

I tried using both variants and they give different results :D

 

Using HIGH preset + "landscape\mountains" + "landscape\unique" gives 1340 files in 62 folders @1.15GB

Using HIGH preset + "landscape\mountains\" + "landscape\unique\" gives 1488 files in 62 folders @1.4GB

 

Probably a bug? Do you want the logs?

Edited June 23, 2017 by Letho

[Letho]

Ok, forget it, both options produce the same now, did it 6 times and its always the same. Must have made a configuration mistake :)

Edited June 23, 2017 by Letho

[Letho]

Ok, i will finally give up on trying to use DynDOLOD's advanced settings to my advantage. Sometimes LOD is not showing at all, sometimes the creation process takes forever when using custom mesh rules for mountains. I will stick with the high default preset and suffer the engine's bad and unmorphed object replacement. Thx for all your time!