DynDOLOD 3.00 Alpha 182

[Mousetick]

Understanding DynDOLOD.esm initially disabled large reference autofix.

The following example illustrates an instance of a large reference initially disabled by an ESM and automatically fixed by DynDOLOD in its ESM:

• I'm curious about the object being replaced with the WorshipperActivator, which is a simple invisible X Marker using a vanilla model unlikely to be replaced by a mod. I'm assuming this is done for dependability, efficiency and performance reasons. Even though these references are buried deep underground and can't be seen by the player, they're still enabled and their full model is still loaded in the extended large reference grid. So using a simplistic object instead of the original one is more efficient and consumes much fewer resources. Please correct me if I'm wrong.
• What are the exact criteria DynDOLOD uses to determine if this automatic fix can be applied?

Here is an example that is not automatically fixed:

• This reference is created and initially disabled by the same ESM plugin. It's not disabling an existing reference added by another ESM. It's declared as a large reference in that same ESM. No other plugin overwrites that reference. It's completely standalone.
• It's kinda weird. Its 'Enable Parent' field is set to PlayerRef, which means the reference is initially disabled, but then not really? I'm not sure what it's supposed to mean. Why not simply let it be enabled? Anyway, this is flagged by DynDOLOD as an 'initially disabled large reference' because it can't be fixed automatically.

Thanks.

 

[ozBillo]

** removed ** 

 

Edited March 27, 2022 by ozBillo
I didn't search first

[sheson]

8 hours ago, Mousetick said:

Understanding DynDOLOD.esm initially disabled large reference autofix.

The following example illustrates an instance of a large reference initially disabled by an ESM and automatically fixed by DynDOLOD in its ESM:

• I'm curious about the object being replaced with the WorshipperActivator, which is a simple invisible X Marker using a vanilla model unlikely to be replaced by a mod. I'm assuming this is done for dependability, efficiency and performance reasons. Even though these references are buried deep underground and can't be seen by the player, they're still enabled and their full model is still loaded in the extended large reference grid. So using a simplistic object instead of the original one is more efficient and consumes much fewer resources. Please correct me if I'm wrong.
• What are the exact criteria DynDOLOD uses to determine if this automatic fix can be applied?

Here is an example that is not automatically fixed:

• This reference is created and initially disabled by the same ESM plugin. It's not disabling an existing reference added by another ESM. It's declared as a large reference in that same ESM. No other plugin overwrites that reference. It's completely standalone.
• It's kinda weird. Its 'Enable Parent' field is set to PlayerRef, which means the reference is initially disabled, but then not really? I'm not sure what it's supposed to mean. Why not simply let it be enabled? Anyway, this is flagged by DynDOLOD as an 'initially disabled large reference' because it can't be fixed automatically.

Thanks.

 

The model is replaced so the full model does not have to be loaded and rendered.

The criteria is: is large reference, last overwrite record in ESM, is initially disabled, opposite enable parent player, z = -30000

No idea why that record is initially disabled or has the player as enable parent. It seems pointless, since it will be always enabled.

[blue321]

For some reason, some tree lods starts flickering. This happen around Whiterun. I dont see it happen anywhere else. Is there a solution to this? My dyndolod settings is set to high, i changed it to medium before but there is still some flickering. Back when I use Dyndolod 2.98, this doesnt happen. Only after I use Dyndolod 3, the tree lods started to flicker

[Aren]

Hello. I just upgraded to version 3.0 from 2.98 in an attempt to use this mod (as suggested in comments, version 2.x resulted in some missing billboard textures). After following the steps on the documentation, the mod seems to be working and my problem of missing texture is gone. However, I now have an issue with some other LODs as well, mostly trees. As you can see on the screens, some LODs quickly and completly disappear for about half a second when approaching, before reappearing as normal. This is annoying and gives an impression of constant flickering when moving. It's very noticeable in open spaces like Whiterun, and does not only affect the trees but some objects/rocks as well. Notice that it only affects close billboards, while the same ones in distant landscape stay in place.
 

Screens of the problem :

https://imgur.com/a/XBkN5oM
 

Thanks a lot for any help.

[sheson]

1 hour ago, Aren said:

Hello. I just upgraded to version 3.0 from 2.98 in an attempt to use this mod (as suggested in comments, version 2.x resulted in some missing billboard textures). After following the steps on the documentation, the mod seems to be working and my problem of missing texture is gone. However, I now have an issue with some other LODs as well, mostly trees. As you can see on the screens, some LODs quickly and completly disappear for about half a second when approaching, before reappearing as normal. This is annoying and gives an impression of constant flickering when moving. It's very noticeable in open spaces like Whiterun, and does not only affect the trees but some objects/rocks as well. Notice that it only affects close billboards, while the same ones in distant landscape stay in place.
 

Screens of the problem :

https://imgur.com/a/XBkN5oM
 

Thanks a lot for any help.

Read the first post which log and debug log to upload when making posts.

Test with a new game. If that fixes it, make sure to follow the instructions https://dyndolod.info/Updating and especially follow the clean save instructions https://dyndolod.info/Help/Clean-Save.

If it still happens with a new game, make sure that the DynDOLOD papyrus scripts are the latest version.
Either from the latest DynDOLOD Resources SE Alpha for PapyrusUtil or the latest DynDOLOD DLL scripts for DynDOLOD DLL.

[Mousetick]

4 hours ago, sheson said:

The model is replaced so the full does not have to be loaded and rendered.

This is an important detail that may be lost on mod authors wishing to disable large references. Setting Z to -30000 is an effective workaround, but the object is still enabled and its full model becomes useless overhead. Replacing it by a dummy object, like DynDOLOD does, would be better. It may be worthwhile to incorporate this advice to https://dyndolod.info/Help/Large-References.

This would be even more important advice when disabling existing large references and recreating them as regular references in a split ESM+ESP combo, to work around overwritten large reference bugs. In that case, without replacing the original object by a dummy one, we end up with 2 "full" instances of the object.

Please correct me if I'm wrong.

4 hours ago, sheson said:

The criteria is: is large reference, last overwrite record in ESM, is initially disabled, opposite enable parent player, z = -30000

Ok, so in other words, the record has to conform exactly to xEdit's "Undelete and disable reference" convention. What if the object is initially disabled, opposite enable parent, but Z = -20000?

Thanks.

 

---

A little off-topic but may be useful to readers:

I've had good success simply flagging plugins as ESM to avoid large reference bugs. It works very well with mods that only change the scenery, such as landscape-focused mods, for example. It's not a guaranteed blanket solution, for example if the mod overwrites a large reference and moves it to a different cell, the results are unexpected and require manual patching, as I had reported earlier in this topic.

There are also some issues with larger mods that add NPCs and/or quests (e.g. Cutting Room Floor, Helgen Reborn, ...). Without going into too many off-topic details here: due to the way the engine handles temporary references in ESMs vs. ESPs, and mods not being correctly written, quests referencing NPCs can be completely broken.

Fortunately there are 2 little known xEdit scripts which can automatically fix these bugs:

• ESMifyer - Easily convert quest mods to ESM with xEdit (Nexus)
• ESMifyer Addon - Set unique NPCs persistent (Nexus)

Caveat emptor: use at your own risk. YMMV.

[sheson]

22 minutes ago, Mousetick said:

This is an important detail that may be lost on mod authors wishing to disable large references. Setting Z to -30000 is an effective workaround, but the object is still enabled and its full model becomes useless overhead. Replacing it by a dummy object, like DynDOLOD does, would be better. It may be worthwhile to incorporate this advice to https://dyndolod.info/Help/Large-References.

This would be even more important advice when disabling existing large references and recreating them as regular references in a split ESM+ESP combo, to work around overwritten large reference bugs. In that case, without replacing the original object by a dummy one, we end up with 2 "full" instances of the object.

Please correct me if I'm wrong.

Ok, so in other words, the record has to conform exactly to xEdit's "Undelete and disable reference" convention. What if the object is initially disabled, opposite enable parent, but Z = -20000?

Thanks.

 

---

A little off-topic but may be useful to readers:

I've had good success simply flagging plugins as ESM to avoid large reference bugs. It works very well with mods that only change the scenery, such as landscape-focused mods, for example. It's not a guaranteed blanket solution, for example if the mod overwrites a large reference and moves it to a different cell, the results are unexpected and require manual patching, as I had reported earlier in this topic.

There are also some issues with larger mods that add NPCs and/or quests (e.g. Cutting Room Floor, Helgen Reborn, ...). Without going into too many off-topic details here: due to the way the engine handles temporary references in ESMs vs. ESPs, and mods not being correctly written, quests referencing NPCs can be completely broken.

Fortunately there are 2 little known xEdit scripts which can automatically fix these bugs:

• ESMifyer - Easily convert quest mods to ESM with xEdit (Nexus)
• ESMifyer Addon - Set unique NPCs persistent (Nexus)

Caveat emptor: use at your own risk. YMMV.

DynDOLOD changes the model based  on my hunch/assumption that it might help. I did not test if the engine is smart enough to cull objects that are completely under the terrain. Maybe it does and changing the model does not help. It just doesn't hurt either.

If z is not -30000, then the reference does not match the criteria and is not modified.

[Mousetick]

26 minutes ago, sheson said:

I did not test if the engine is smart enough to cull objects that are completely under the terrain.

How much are you willing to bet that it most likely isn't smart enough? 

The engine might omit the object from the rendering queue - this is what occlusion culling is supposed to achieve, if my understanding is correct. But the full model must still be loaded in memory, as the object could be dynamically enabled, repositioned or resized at any time (e.g. via a Papyrus script: https://ck.uesp.net/wiki/index.php?title=SetPosition_-_ObjectReference). Unless the engine uses some kind of object lazy-loading + purge mechanism based on whether the object is visible or not (doubtful).

Anyhow, thanks for the clarifications.

[sheson]

2 hours ago, Mousetick said:

How much are you willing to bet that it most likely isn't smart enough? 

The engine might omit the object from the rendering queue - this is what occlusion culling is supposed to achieve, if my understanding is correct. But the full model must still be loaded in memory, as the object could be dynamically enabled, repositioned or resized at any time (e.g. via a Papyrus script: https://ck.uesp.net/wiki/index.php?title=SetPosition_-_ObjectReference). Unless the engine uses some kind of object lazy-loading + purge mechanism based on whether the object is visible or not (doubtful).

Anyhow, thanks for the clarifications.

It could use the object bounds from base record * scale from the reference in a pre-pass. They often have these decade old techniques down. Without actually testing we can not be sure. Hence my preemptive hunch...

[Dhamon]

Skyrim SSE with the latest DynDOLOD 3. I can see both Object LODs and full models, flickering in the active cell, as in these screens:
https://imgur.com/a/6nMk5kC

They disappear only when I disable DynDOLOD. The FAQ says that this bug can happen with Fast Travel, but I haven't used fast travel, it's permanent.

So I followed all the instructions, RTFM, but I can't understand what I'm doing wrong. I'm using Wrye Bash to package the outputs from xLODGen's terrain LOD and DynDOLOD LODs.
I am using the Medium settings, Large Reference enabled, and uLargeRefLODGridSize > uGridsToLoad (11 > 5)

I hope somebody can point me in the correct direction

[sheson]

1 hour ago, Dhamon said:

Skyrim SSE with the latest DynDOLOD 3. I can see both Object LODs and full models, flickering in the active cell, as in these screens:
https://imgur.com/a/6nMk5kC

They disappear only when I disable DynDOLOD. The FAQ says that this bug can happen with Fast Travel, but I haven't used fast travel, it's permanent.

So I followed all the instructions, RTFM, but I can't understand what I'm doing wrong. I'm using Wrye Bash to package the outputs from xLODGen's terrain LOD and DynDOLOD LODs.
I am using the Medium settings, Large Reference enabled, and uLargeRefLODGridSize > uGridsToLoad (11 > 5)

I hope somebody can point me in the correct direction

Read the first post of the DynDOLOD 3 Alpha thread where to post when making reports. I moved your post.

Read the first post of the DynDOLOD 3 Alpha thread which log and debug to upload when making posts.

I have no idea what you mean by using Wrye Bash to "package" the outputs. Simply install output as a mod.

See the section "General Game Questions" at https://dyndolod.info/Help/Object-LOD. "Object LOD shows in active exterior cells" lists two possibilities. You mention only one in your post.
Also see the FAQ answers for "Object LOD model and full model show at the same time causing texture flicker"  and "Out of place or floating objects"

When making/posting screenshots open console and click the object of interest to show its form id.
If the LOD objects do not have form IDs, they are object/tree LOD meshes. Verify if they go away by toggling LOD off with tll in console. If they remain, they are placed references.

[dzee349]

Hi Sheson, 

I was wondering what the difference is between the Data > DynDOLOD folder and the DynDOLOD > Edit Scripts > DynDOLOD > Rules folder? 

Looks like both house .ini files, could we install .ini rule files to either folder?

Thanks!

[sheson]

4 hours ago, dzee349 said:

Hi Sheson, 

I was wondering what the difference is between the Data > DynDOLOD folder and the DynDOLOD > Edit Scripts > DynDOLOD > Rules folder? 

Looks like both house .ini files, could we install .ini rule files to either folder?

Thanks!

These things are explained in the DynDOLOD Documentation. From https://dyndolod.info/Mod-Authors#How-to-add-a-rule-file-for-a-plugin:

"Rules shipping with DynDOLOD are in ..\DynDOLOD\Edit Scripts\DynDOLOD\rules\. In addition DynDOLOD first searches for matching rule files in the game data folder ..\DynDOLOD\. This way a mod author can package rule files directly with a mod. Rules found in the game data folder ..\DynDOLOD\ supersede rule files found in ..\DynDOLOD\Edit Scripts\DynDOLOD\rules\ with the same filename."

[dzee349]

6 hours ago, sheson said:

These things are explained in the DynDOLOD Documentation. From https://dyndolod.info/Mod-Authors#How-to-add-a-rule-file-for-a-plugin:

"Rules shipping with DynDOLOD are in ..\DynDOLOD\Edit Scripts\DynDOLOD\rules\. In addition DynDOLOD first searches for matching rule files in the game data folder ..\DynDOLOD\. This way a mod author can package rule files directly with a mod. Rules found in the game data folder ..\DynDOLOD\ supersede rule files found in ..\DynDOLOD\Edit Scripts\DynDOLOD\rules\ with the same filename."

That’s wonderful, thank you!