DynDOLOD 3.00 Alpha 182

[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!

[PegasusKoga]

I have two questions, one for me and another for a friend of mine.

Are there any special steps i need to take into account when i've overhauled the Commonwealth into a winter wasteland with Icepick Overhaul and some added pine trees?  Icepick Overhaul is packaged into a BA2 if that matters.

And a friend of mine has mistakenly pressed the Generate LodGen button in Fo4Edit and now his game is kinda messed up.  Can someone help the fellow by telling me which files he needs to remove from his data folder so he can get his Mad Max desert Commonwealth back?

[DoubleYou]

Relevant files are probably in textures/terrain and meshes/terrain. Check file modified stamps to see which ones. 

[sheson]

12 hours ago, PegasusKoga said:

I have two questions, one for me and another for a friend of mine.

Are there any special steps i need to take into account when i've overhauled the Commonwealth into a winter wasteland with Icepick Overhaul and some added pine trees?  Icepick Overhaul is packaged into a BA2 if that matters.

And a friend of mine has mistakenly pressed the Generate LodGen button in Fo4Edit and now his game is kinda messed up.  Can someone help the fellow by telling me which files he needs to remove from his data folder so he can get his Mad Max desert Commonwealth back?

xLODGen generates LOD for the plugins and assets found in the load order / data folder. Generate LOD for the load order and in case something doesn't work as expected, make a post with the detailed information and ask specific questions. If a mod requires extra steps depends on the mod. Check its description/instructions. Follow a modding guide if you require others testing mods/setups for you.

The log prints lines with the paths where meshes and textures are generated to. Those are the folders/files to delete.

Always use the -o command line parameter to set an output path outside of game and mod manager folders.

[mattski123]

Logs: https://ufile.io/n41v5fse

Hey, how do I fix this? It only came up nearing the end of the run.

[Main Instruction]
Checking for errors failed Access violation at address 000000000041A1A8 in module 'DynDOLODx64.exe'.

[Content]
Read of address 0000000000000000 for arnima.esm [REFR:1324715B] (places TreeDeadShrub [TREE:000A731C] in GRUP Cell Temporary Children of [CELL:13008426] (in arnimaDUPLICATE003 "The Reach" [WRLD:13000D62] at 2,-8))

[Exit DynDOLOD]

Also, these CMD exes were hanging for ages (5-10+ minutes after selecting exit dyndolod). Not moving but going up and down in performance on task manager.

Also, notice how my log files are HUGE! Like, what? Also also, seeing as precaching grass isnt working for AE, what's your suggested workaround?

[sheson]

43 minutes ago, mattski123 said:

Logs: https://ufile.io/n41v5fse

Hey, how do I fix this? It only came up nearing the end of the run.

I think that is a race condition. Is that repeatable? Also when only generating for arnimaDUPLICATE003 "The Reach"?

Will fix for next version.

43 minutes ago, mattski123 said:

Also, these CMD exes were hanging for ages (5-10+ minutes after selecting exit dyndolod). Not moving but going up and down in performance on task manager.

If LODGen uses CPU it is working on something. The more ultra tree LOD, the more full models, the more grass LOD, the more high resolution terrain LOD meshes the longer, the higher teh memory requirements. Just let them run and they should finish eventually.

https://dyndolod.info/Help/Grass-LOD#LODGen-takes-a-long-time-or-uses-a-lot-of-memory
https://dyndolod.info/Help/LODGen#Out-of-Memory
https://dyndolod.info/FAQ "DynDOLOD/TexGen Questions / High memory usage"

43 minutes ago, mattski123 said:

Also, notice how my log files are HUGE! Like, what? Also also, seeing as precaching grass isnt working for AE, what's your suggested workaround?

https://dyndolod.info/Help/Grass-LOD
No Grass In Objects is currently only available for Skyrim Special Edition runtime version 1.5.x. The grass LOD generation however does not care about the runtime version, so the grass cache files can still be used to generate grass LOD with the runtime 1.6.x.

As explained several times already, the only option is to generate grass cache with a 1.5.x.

[mattski123]

1 hour ago, sheson said:

I think that is a race condition. Is that repeatable? Also when only generating for arnimaDUPLICATE003 "The Reach"?

Will fix for next version.

If LODGen uses CPU it is working on something. The more ultra tree LOD, the more full models, the more grass LOD, the more high resolution terrain LOD meshes the longer, the higher teh memory requirements. Just let them run and they should finish eventually.

https://dyndolod.info/Help/Grass-LOD#LODGen-takes-a-long-time-or-uses-a-lot-of-memory
https://dyndolod.info/Help/LODGen#Out-of-Memory
https://dyndolod.info/FAQ "DynDOLOD/TexGen Questions / High memory usage"

https://dyndolod.info/Help/Grass-LOD
No Grass In Objects is currently only available for Skyrim Special Edition runtime version 1.5.x. The grass LOD generation however does not care about the runtime version, so the grass cache files can still be used to generate grass LOD with the runtime 1.6.x.

As explained several times already, the only option is to generate grass cache with a 1.5.x.

It wasn't repeatable no. Thanks man!