Jump to content
  • 0

Dynamic Distant Objects LOD - DynDOLOD 2.21


sheson

Question

DynDOLOD 2.19/2.20 / 2.21 condensed update post | Full Update Post | Skyrim Special Edition

 

What’s New?

 

This updates includes minor speed improvements for DynDOLOD.exe and TexGen.exe, 64 bit executables and visual improvements for billboards used as static LOD (higher LOD levels 8/16) if using the ultra tree LOD option. Of course there are also a few updates for a couple mods.

 

See Full update post for 2.xx update instructions

 


 

64 bit executables

To avoid confusion, this has nothing to do with Skyrim SE being 64 bit. Just going with the flow. There is no requirement for this right now, but it will work natively with 64 bit managers or if executed directly. 64 bit versions are a tiny bit slower due to a couple reasons, but obviously they will allow for more data to be loaded... in the future... for insanely large load orders. Another long term benefit is, that the 64 bit changes are merged back into xEdit sources.

 

Improvements for billboards used as static LOD

When using the ultra tree option and you ever thought far away trees or trees on the map look too dark or too bright, check out the new Trees on the Map section in docs\trees.ultra\DynDOLOD-Trees.html. The new default settings should already result in better lighting behavior. If not try any of the additional tips from the manual. To update an existing save game, it is enough to just do an update generation with the existing DynDOLOD.esp in the load order. Then no clean save cycle is required. Just a save in an interior before updating.

 

Persistent references

There is a new switch Temporary=0/1 in ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5.ini, which instructs the patcher to use less persistent references. This is for users who have so many mods installed and suffer from CTD when clicking new as we discussed recently. The downside is, that by using temporary references more plugins may have to be used as masters and the generated DynDOLOD.esp will be larger, because of additional CELL data that needs to be copied. If you do not have any problems starting the game there should be no reason to use this setting.

 


 

Mods Requiring DynDOLOD

Spice of Life - Orc Strongholds - overwrite meshes from DynDOLOD Resources with the ones included in the mod

 

Verified working out of the box - included rules

Wind's Rest Estate - A Whiterun Tundra Home

Ayleid Palace Remastered

 

Verified working out of the box - added/updated meshes and/or textures

Settlements Expanded

Greater Skaal Village

Whiteraven Manor

Tactical Valtheim

Dwemer Manor

JKs Skaal village

Dolmen Ruins - ESO Dark Anchors

Peak Aspens - Billboards included in versions for DynDOLOD/TES5LODGen in optional files

Fantasy Forest Overhaul - Billboards included in versions for DynDOLOD/TES5LODGen in optional files

 

 


 

DynDOLOD 2.21 - Download from Mega, Nexus

 

DynDOLOD Resources 2.20 - Download from Mega, Nexus

 

DynDOLOD Patches 2.22 - Download from Mega, Nexus

 


 

[spoiler=Changelog DynDOLOD 2.19]DynDOLOD.exe - added xespignore file for XESP markers to ignore instead of the one hardcoded dunCGOutsideClutterMarker from intro scene

DynDOLOD.exe - fixed sometimes not correctly identifying Has Tree LOD flag on base records

DynDOLOD.exe - added settings FlatLODLightingEffect, FlatLODGlowMap and FlatLODLevelLODFlat to DynDOLOD.ini, see docs\trees.ultra\DynDOLOD-Trees.html

DynDOLOD.exe - added a switch Temporary to use less persistent references for overloaded load orders, will result in more plugins required as masters and larger esp

DynDOLOD.exe - added verbose switch for LODGen.exe to DynDOLOD.ini

DynDOLOD.exe - updated reading existing tree LOD to be able to read btt data from BSA

DynDOLOD.exe - some minor performance improvements

DynDOLOD.exe - changed log filename to DynDOLOD_log.txt

DynDOLOD.exe - added a x64 version

TexGen.exe - sync updates with DynDOLOD.exe

TexGen.exe - some minor performance improvements

TexGen.exe - changed log filename to TexGen_log.txt

TexGen.exe - added a x64 version

LODGen.exe - added optional --inputfile path/to/file command line parameter, first parameter just being path/to/file still works too

LODGen.exe - make billboards soft lighting behave more similar to vanilla tree LOD (FlatLODLightingEffect and FlatLODGlowMap)

LODGen.exe - added setting LOD Objects flag for higher LOD levels on billboards (FlatLODLevelLODFlat)

LODGen.exe - added a x64 version

DynDOLOD_Manual.html - updated compatibility information for several mods

DynDOLOD Resources - updated/added meshes for better compatibility with mods

 

 

[spoiler=Changelog DynDOLOD 2.20]

DynDOLOD.exe - fixed a list assignment

TexGen.exe - sync updates with DynDOLOD.exe

DynDOLOD Resources - Papyrus Scripts - fixed a race condition

 

 

[spoiler=Changelog DynDOLOD 2.21]

DynDOLOD.exe - fixed a case of removing entire worlds when removing empty cells

DynDOLOD.exe - added an installation path check

DynDOLOD_Manual.html - updated compatibility information for several mods

DynDOLOD Patches - added script patches for Caranthir Tower Reborn 2.x

 

 

[spoiler=Changelog DynDOLOD 2.22]

DynDOLOD Patches - fixed a typo in Wizard.txt

 

 

 

 

See Full update post for full changelog, fully detailed update instructions and updated compatibility information for Skryim mods.

 

DynDOLOD 2.18

Link to comment
Share on other sites

Recommended Posts

  • 0

ELFX - Exteriors.esp - I went and checked Hjermin and the house to its right (when facing Hjerim's door) and those are touched by ELFX - Exteriors too.

 

That mod should  be covered already.

 

Did you rename ELFX - Exteriors.esp or merged it?

 

Check if this file exists ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_TES5_mod_world_ignore.txt and if it contains a line

ELFX - Exteriors.esp=MarkarthWorld,RiftenWorld,SolitudeWorld,WhiterunWorld,WindhelmWorld

 

I will be testing the mod again, there is always the possibility I broke something.

Link to comment
Share on other sites

  • 0

Not merged or renamed. Screenshot for details: https://i.imgur.com/VBxkBKm.jpg.

 

File you mentioned exists and contains ELFX - Exteriors.esp=MarkarthWorld,RiftenWorld,SolitudeWorld,WhiterunWorld,WindhelmWorld

I haven't found anything wrong yet. It seems to work as intended here. You are generating windows high right?

You could try generating from scratch again, or remove the mod before starting DynDOLOD, then add it afterwards. That *should* work out OK for now.

Link to comment
Share on other sites

  • 0

 

 

Can you post entire log for when you had Tamriel 65640 and it still loaded? I may spot something.

 

I guess we are understanding the problem well enough, it would be just nice to exactly have it down to the last bit of what counts towards the limit and what not.

Nothing jumps out at me right now. I guess I should try such a load order myself. But with SE looming that might be a bit. Though I am curios if we will see the same limit in SE or not.

Edited by sheson
Link to comment
Share on other sites

  • 0

Yes, generating windows high along with fx glow, candles and fake lights in child worlds.

 

Medium rule set but manually setting tree lod4 to static over billboard.

When you started the new game with coc windhelmexterior01, did you wait outside the city until DynDOLOD initialized? I could make it happen when I immediately go into the city before it has a chance to complete its initialization. Which is OK. It then settles eventually when you leave the city/fasttravel and come back, or deactive/activate from MCM.

 

If that is not it, can you you look up the DynDOLOD window reference with the form ID f20046fc from the 1st screenshot in xEdit? Type the form id into the field top left and hit enter. Then in the right window, check the Editor ID which should be something like DynDOLODesp_XXXXXX_DynDOLOD_GLOWLOD.

 

Take the XXXXXX, put f2 in front of it and look up that new form id. It should bring up a reference with the Editor ID Skyrimesm_0383C2_DynDOLOD_TOWN which is the reference form ID from the 2nd screenshot, correct? If you look up 000383C2 it is only changed by ELFX - Exteriors.esp right? No other mods?

Edited by sheson
Link to comment
Share on other sites

  • 0

I did go right in but didn't have the issue.

 

I then went outside windhelm, pressed T and waited until midnight ish and went back in to wander around.

 

I've since rebuilt dydnlod (was going to build without elfx-exteriros but remembered my CR patch depended on it) so refs may have changed but will dig up the details you're asking for.

Link to comment
Share on other sites

  • 0

Ok so had to re-build dyndolod - apparently running it after getting list index out of bounds errors causes incomplete things to happen :D

 

The DynDOLOD ref id's changed but I wound up at the same 383c2 in skyrim esm. Can confirm only ELFX - Exteriors touches it.

Link to comment
Share on other sites

  • 0

Ok so had to re-build dyndolod - apparently running it after getting list index out of bounds errors causes incomplete things to happen :D

If the process does not complete successfully do not use the generated files. The data will not be complete.

 

When you are in Windhelm and deactivate DynDOLOD from MCM, then activate it again, does it show up again?

When you fast travel out of Windhelm and back, any change?

Can you check for similar problems in any of the other walled cities?

 

Open ..\skse\plugins\StorageUtilData\DynDOLOD_Tamriel_Objects.json in note pad and search for WHmarket02. There will be two entries that should like this.

 

"XXXXX":["1","1","1","","","1056722","Skyrim.esm","-1","-1","1","1","WHmarket02:21,WHmarket02:20"],

"YYYYY":["1","1","","","","1056733","Skyrim.esm","-1","-1","1","1","WHmarket02:20,WHmarket02:21"],

 

Can you compare that everything between number XXXXX/YYYY in front and the "WHmarket02 at the end are the same?

 

If that is the case, can you double check the papyrus scripts from DynDOLOD Resources are all not from the latest version?

Link to comment
Share on other sites

  • 0

Okay, as far as I can tell all the walled cities get floating windows - I'm not sure what triggers whole building lod sticking around.

 

An interesting discovery - I'd left my test profile with a save looking at the Windhelm floating window, on loading the game the window slowly faded away. I have been able to replicate this behaviour in the other cities by following these steps:

 

set gamehour to 10pm either with console or wait command.

1. Coc to <city>exterior01

2. Enter city

3. Disable Dyndo from mcm

4. Exit city

5. Wait a bit outside then re-enter

6. Watch lit windows fade away

 

The exception to this is Markarth - I couldn't tell if this was happening at all there. Additionally, Solitude exhibited non-lit floating windows, and after a few cycles of the above procedure, the windows stopped fading out.

I also notice in Solitude flickering lod ground textures for a few moments but this goes away after moving around some.

 

I've not tested all walled cities for this but since windhelm, whiterun and solitude exhibit this, I can't tell with markarth, I'm thinking its safe that Riften will too.

 

DynDO scripts are from resources 2.19 - the only version identifier I could see in the .psc files was if (NewVersion >= 147 && CurrentVersion < 147) from the mcm script.

 

I'm guessing that what should be happening is that DynDO should be replacing unlit windows with lit ones?

 

 

The json lines match your provided examples.

Edited by LordOfLA
Link to comment
Share on other sites

  • 0

Okay, as far as I can tell all the walled cities get floating windows - I'm not sure what triggers whole building lod sticking around.

 

An interesting discovery - I'd left my test profile with a save looking at the Windhelm floating window, on loading the game the window slowly faded away. I have been able to replicate this behaviour in the other cities by following these steps:

 

set gamehour to 10pm either with console or wait command.

1. Coc to exterior01

2. Enter city

3. Disable Dyndo from mcm

4. Exit city

5. Wait a bit outside then re-enter

6. Watch lit windows fade away

 

The exception to this is Markarth - I couldn't tell if this was happening at all there. Additionally, Solitude exhibited non-lit floating windows, and after a few cycles of the above procedure, the windows stopped fading out.

I also notice in Solitude flickering lod ground textures for a few moments but this goes away after moving around some.

 

I've not tested all walled cities for this but since windhelm, whiterun and solitude exhibit this, I can't tell with markarth, I'm thinking its safe that Riften will too.

 

DynDO scripts are from resources 2.19 - the only version identifier I could see in the .psc files was if (NewVersion >= 147 && CurrentVersion

 

I'm guessing that what should be happening is that DynDO should be replacing unlit windows with lit ones?

 

 

The json lines match your provided examples.

OK, there must be something really weird going on with your setup with I can not pinpoint right now. It maybe be memory or INI setting problems. By all accounts the generated data is correct. What you should try next is to generate LOD with only the Legendary / USLEEP and see if that works as it should. If that is the case add ELFX Exterior to that small list and see if that works. This should be easy to do with MO profiles. Ask if you need help.

 

Markarth is different to the other cities since it actually is its own worldspace. But there is also no ELFX meshes the buildings like it does in Windhelm.

 

There is no such thing as lit or unlit windows in this case. They are just windows and their current light depends on weather/time of day settings (external emit). It just so happens that ELFX replaces the buildings with its own meshes. Those windows are part of the buildings and ELFX changes the included windows compared to the vanilla buildings. The LOD windows you see floating are based on the vanilla buildings so they can differ. That is unrelated to the problem.

Edited by sheson
Link to comment
Share on other sites

  • 0

I'll try with just legendary + usleep then add elfx to the mix.

 

Here's the INI tweaks i apply with MOhttps://pastebin.com/pVQQfdnQ

 

The tweaks come mainly from step INI guides with shadow settings taken from the Bleak ENB readme. If anything is likely to cause said issues I'll remove/change values as needed.

 

These are on top of the values from BethINI that you can see at https://modwat.ch/u/ArcaneEntanglement

Link to comment
Share on other sites

  • 0

Hi Sheson, I've been testing 2.20 with Temporary=0 and Temporary=1 and this is showing some great results. BTW, even with Temporary=0 I'm getting only about 56 000 persistant references for Tamriel with my standard load order, which is already about 9000 less than before. Was this expected?

 

With Temporary=1 I get only about 33 500 persistant references for Tamriel which is a HUGE decrease. The ESP is only 1MB larger (7->8) and there aren't any additional masters that I noted in my case, so all in all a very easy trade-off.

 

I haven't gotten around to testing whether I can overload the engine yet however, as I'm dealing with one other problem: 2.20 won't activate even though the MCM is available and seems to work o.k.. I thought I performed the clean save procedure correctly but I may have messed up while swapping various output files between 2.14 and 2.20.

 

Right now I'm looking at rolling back to 2.14 with the save I have from then to redo to upgrade, but â€‹I no longer have the (core) resource files to match 2.14 (definitely my bad). I don't suppose you could drop them on mega so I can reinstall them? In the meantime I'll see if I can't recover the deleted file.

 

Also, I had to generate textures and LOD with the 32bit versions of TexGen and DynDOLOD as the 64bit versions kept throwing a bunch of access violations.

Edited by Sundder
Link to comment
Share on other sites

  • 0

Hi Sheson, I've been testing 2.20 with Temporary=0 and Temporary=1 and this is showing some great results. BTW, even with Temporary=0 I'm getting only about 56 000 persistant references for Tamriel with my standard load order, which is already about 9000 less than before. Was this expected?

Yes, I already reduced the normal version a bit as well.

 

With Temporary=1 I get only about 33 500 persistant references for Tamriel which is a HUGE decrease. The ESP is only 1MB larger (7->8) and there aren't any additional masters that I noted in my case, so all in all a very easy trade-off.

 

I haven't gotten around to testing whether I can overload the engine yet however, as I'm dealing with one other problem: 2.20 won't activate even though the MCM is available and seems to work o.k.. I thought I performed the clean save procedure correctly but I may have messed up while swapping various output files between 2.14 and 2.20.

 

Right now I'm looking at rolling back to 2.14 with the save I have from then to redo to upgrade, but â€‹I no longer have the (core) resource files to match 2.14 (definitely my bad). I don't suppose you could drop them on mega so I can reinstall them? In the meantime I'll see if I can't recover the deleted file.

 

Also, I had to generate textures and LOD with the 32bit versions of TexGen and DynDOLOD as the 64bit versions kept throwing a bunch of access violations.

You can use the newest DynDOLOD Resources with older Standalone versions. Just not the other way around.

 

Did you run the x64 directly or through MO2 - which is quite buggy? The x64 virtual system is not that stable. Anyhow no particular reason to use x64 anyways.

Edited by sheson
Link to comment
Share on other sites

  • 0

I know this is going to come as a shock but I use NMM, so I ran the x64 versions directly through Windows.

 

O.k., I'll try rolling back to my 2.14 output file and save with the 2.19 resources then upgrading again. Maybe I just didn't wait long enough when performing the clean save procedure.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.