Dynamic Distant Objects LOD - DynDOLOD for Skyrim and Enderal 2.98

[XenolithicYardZone]

If this is true tree LOD (goes away when typing tll in console) and this is in a parent world space (not inside a walled city), then this happens because the load order of plugins adding tree references changed after generating tree LOD. Simply generate tree LOD for the load order.

 

If this is dynamic LOD object (has a form id in console, can be disabled, does not happen when starting new game), then this is because the clean save routine was not properly followed when updating. This only applies to Skryim atm.

 

 

FAQ: Tree LOD: LOD trees show in loaded cells

 

A: Make sure all plugins with ITM or deleted references are cleaned. See https://ck.uesp.net/wiki/TES5Edit_Cleaning_Guide_-_TES5Edit

 

A: If the load order / priority of mods adding or changing tree references was changed, generate tree LOD again so it matches the new load order.

 

 

FAQ: Skyrim: Out of place objects / flickering full models

 

A: Test with new game, if successful the updating of existing save game with old DynDOLOD.esp went wrong. Follow instructions how to update save game with a new DynDOLOD.esp. RTFM, watch the video or check DynDOLOD SkyUI MCM.

Yeah, it can be toggled on/off with tll, has no id and is in a parent world (outside Whiterun). Do you mean re-run DynDOLOD with DynDOLOD.esp selected/unselected and only generate tree LODs the second time? Cause I tried doing that with DynDOLOD.esp both enabled/disabled but those unsightly LODs are still there. 

 

Checked the mod in TES5Edit before posting and its clean. No, not updating a current save. Haven't started a playthrough yet. Was using coc whiterun straight from the main menu. Also tried starting a new game using Alternate Start but the problem persists. 

Edited October 9, 2017 by XenolithicYardZone

[sheson]

Yeah, it can be toggled on/off with tll, has no id and is in a parent world (outside Whiterun). Do you mean re-run DynDOLOD with DynDOLOD.esp selected/unselected and only generate tree LODs the second time? Cause I tried doing that with DynDOLOD.esp both enabled/disabled but those unsightly LODs are still there. 

 

Checked the mod in TES5Edit before posting and its clean. No, not updating a current save. Haven't started a playthrough yet. Was using coc whiterun straight from the main menu. Also tried starting a new game using Alternate Start but the problem persists. 

 

It does not matter if there is a DynDOLOD.esp already in the load order. 

 

When tree LOD is generated it will write a 

 

You should also generate/update object LOD, since it will add those excluded trees as object LOD.

Edited October 10, 2017 by sheson

[XenolithicYardZone]

It does not matter if there is a DynDOLOD.esp already in the load order. 

 

When tree LOD is generated it will write a <Warning: x duplicate FormID numbers of trees references were detected, excluded from LOD>

 

You should also generate/update object LOD, since it will add those excluded trees as object LOD.

Ah dammit! No matter what I do, those LODs simply won't go away. :(

 

1 - Re-ran DynDOLOD with the esp activated, selected Generate tree LOD and Generate DynDOLOD, clicked 'Save and Exit' in the end. No luck. 

2 - Next time, re-ran the program and selected only 'Exit' so no new esp was created but same story.

3 - Also tried re-running DynDOLOD fully with the previous output folder/esp disabled in MO but it still won't take. 

 

If I disable the tree on top of one of them, this is what I get:

https://imgur.com/dvpwXCs

No ids so can't even disable them. If I tfc from far away, they look like any of the other tree LODs, only they don't disappear like the others when the cell is fully loaded. 

 

A few eye sores ruining an otherwise beautifully DynDOLOD'ed landscape. :( 

Edited October 10, 2017 by XenolithicYardZone

[sheson]

Ah dammit! No matter what I do, those LODs simply won't go away. :(

 

1 - Re-ran DynDOLOD with the esp activated, selected Generate tree LOD and Generate DynDOLOD, clicked 'Save and Exit' in the end. No luck. 

2 - Next time, re-ran the program and selected only 'Exit' so no new esp was created but same story.

3 - Also tried re-running DynDOLOD fully with the previous output folder/esp disabled in MO but it still won't take. 

 

If I disable the tree on top of one of them, this is what I get:

https://imgur.com/dvpwXCs

No ids so can't even disable them. If I tfc from far away, they look like any of the other tree LODs, only they don't disappear like the others when the cell is fully loaded. 

 

A few eye sores ruining an otherwise beautifully DynDOLOD'ed landscape. :( 

Check that none of the generated tree LOD files in Meshes\Terrain\Tamriel\Trees\*.btt is overwritten by other mods or something in MO overwrite folder.

[XenolithicYardZone]

Check that none of the generated tree LOD files in Meshes\Terrain\Tamriel\Trees\*.btt is overwritten by other mods or something in MO overwrite folder.

Nope, TexGen and DynDOLOD output folders are at the very bottom in MO and nothing's overwriting them. Strange why its just those 6-7 LODs (ones I have spotted) that are the problem. All other tree LODs are fine. 

[sheson]

Nope, TexGen and DynDOLOD output folders are at the very bottom in MO and nothing's overwriting them. Strange why its just those 6-7 LODs (ones I have spotted) that are the problem. All other tree LODs are fine.

Was there a in the log? Edited October 10, 2017 by sheson

[XenolithicYardZone]

Was there a <Warning: x duplicate FormID numbers of trees references were detected, excluded from LOD> in the log?

Yes, one instance in the log. Fresh run of DynDOLOD. [00:00:18.240] <Warning: 1 duplicate FormID numbers of trees references were detected, excluded from LOD>. 

 

Tried reinstalling EVT with Vurts foliage textures and billboards this time but those few trees still have LODs stuck in them. Like I said, I've been using coc commands straight from the main menu or new saves. Even tried fast travelling to other locations and back but didn't help. 

 

Load order is setup like you suggested (Resources, Indistinguishable vanilla billboards, EVT, EVT billboards with TexGen & DynDOLOD o/p folders at the very bottom) and given all other tree LODs in my game are fine including ones generated for most of this mod's trees, I am guessing my load order isn't the issue?

 

Anything else I can do other than removing Whiterun Forest altogether? 

Edited October 10, 2017 by XenolithicYardZone

[sheson]

Yes, one instance in the log. Fresh run of DynDOLOD. [00:00:18.240] . 

 

Tried reinstalling EVT with Vurts foliage textures and billboards this time but those few trees still have LODs stuck in them. Like I said, I've been using coc commands straight from the main menu or new saves. Even tried fast travelling to other locations and back but didn't help. 

 

Load order is setup like you suggested (Resources, Indistinguishable vanilla billboards, EVT, EVT billboards with TexGen & DynDOLOD o/p folders at the very bottom) and given all other tree LODs in my game are fine including ones generated for most of this mod's trees, I am guessing my load order isn't the issue?

 

Anything else I can do other than removing Whiterun Forest altogether?

1 duplicate form id should mean only one such tree exists, or maybe several different plugins use the same form id for tree references. So this seems odd. I only really know of these two engine limitations (duplicate form ids, trees inside cities) reasons for tree LOD to do this. Could be something new in Skryim SE. In any case, make sure that all plugins are cleaned of UDRs and ITMs.

 

This bug is about tree references, not tree mods like EVT that only changes tree base records / changes meshes. Also the order of billboards is irrelevant.

 

Those known bugs are all about the references that are then used to create the data in the *.btt files.

 

Lets do some tests

 

(1) Disable the generated object LOD by renaming/hiding the Meshes\Terrain\Tamriel\Objects folder. If the error then still happens, unhide the objects folder and hide Meshes\Terrain\Tamriel\Trees folder. If wrong LOD trees are now gone continue.

 

(2) Disable all output from DynDOLOD and generated tree LOD with SSELODGen. Use the -o:"c:\output" command line argument so it doesn't generate into the data folder. Then just install as you would out put from DynDOLOD. Check how many duplicate trees it reports. Check if the problem happens too or not. Maybe my multithreading update to that code is doing things. If the wrong tree LOD also happen with SSELODGen then continue.

 

(3) Look up which mods add or change the trees themselves for which this happens. Open console and click on the full model and take note of the form id. First two numbers are load order ID of plugin in hex. You can also look the form id up in xEdit. Do this for all trees where this happens, since the tree generation in xEdit is supposed to not create LOD for duplicate form id of trees this will not necessarily discover all form ids / mods, but for now lets see what mods you find.

[XenolithicYardZone]

1 duplicate form id should mean only one such tree exists, or maybe several different plugins use the same form id for tree references. So this seems odd. I only really know of these two engine limitations (duplicate form ids, trees inside cities) reasons for tree LOD to do this. Could be something new in Skryim SE. In any case, make sure that all plugins are cleaned of UDRs and ITMs.

 

This bug is about tree references, not tree mods like EVT that only changes tree base records / changes meshes. Also the order of billboards is irrelevant.

 

Those known bugs are all about the references that are then used to create the data in the *.btt files.

 

Lets do some tests

 

(1) Disable the generated object LOD by renaming/hiding the Meshes\Terrain\Tamriel\Objects folder. If the error then still happens, unhide the objects folder and hide Meshes\Terrain\Tamriel\Trees folder. If wrong LOD trees are now gone continue.

 

(2) Disable all output from DynDOLOD and generated tree LOD with SSELODGen. Use the -o:"c:\output" command line argument so it doesn't generate into the data folder. Then just install as you would out put from DynDOLOD. Check how many duplicate trees it reports. Check if the problem happens too or not. Maybe my multithreading update to that code is doing things. If the wrong tree LOD also happen with SSELODGen then continue.

 

(3) Look up which mods add or change the trees themselves for which this happens. Open console and click on the full model and take note of the form id. First two numbers are load order ID of plugin in hex. You can also look the form id up in xEdit. Do this for all trees where this happens, since the tree generation in xEdit is supposed to not create LOD for duplicate form id of trees this will not necessarily discover all form ids / mods, but for now lets see what mods you find.

I am modding classic Skyrim. I know, EVT and its billboards aren't at fault here - was just trying something different for the heck of it. :P

 

Ok give some time. I'll try out what you've suggested and get back to you. Btw, since this is classic Skyrim and SSELOGGen isn't applicable here, how should I proceed? Apply the command line argument to change o/p directory to DynDOLOD's exe in MO? 

[sheson]

I am modding classic Skyrim. I know, EVT and its billboards aren't at fault here - was just trying something different for the heck of it. :P

 

Ok give some time. I'll try out what you've suggested and get back to you. Btw, since this is classic Skyrim and SSELOGGen isn't applicable here, how should I proceed? Apply the command line argument to change o/p directory to DynDOLOD's exe in MO? 

SSELODGen.exe = renamed xEdit.exe = renamed TES5LODGen.exe

 

Just get the latest xEdit, then start the *.exe with -tes5 -lodgen -o:"c:\output" 

Or rename *.exe to TES5LODGen.exe -o:"c:\output"

same thing.

 

Edited October 10, 2017 by sheson

[XenolithicYardZone]

1 duplicate form id should mean only one such tree exists, or maybe several different plugins use the same form id for tree references. So this seems odd. I only really know of these two engine limitations (duplicate form ids, trees inside cities) reasons for tree LOD to do this. Could be something new in Skryim SE. In any case, make sure that all plugins are cleaned of UDRs and ITMs.

 

This bug is about tree references, not tree mods like EVT that only changes tree base records / changes meshes. Also the order of billboards is irrelevant.

 

Those known bugs are all about the references that are then used to create the data in the *.btt files.

 

Lets do some tests

 

(1) Disable the generated object LOD by renaming/hiding the Meshes\Terrain\Tamriel\Objects folder. If the error then still happens, unhide the objects folder and hide Meshes\Terrain\Tamriel\Trees folder. If wrong LOD trees are now gone continue.

 

(2) Disable all output from DynDOLOD and generated tree LOD with SSELODGen. Use the -o:"c:\output" command line argument so it doesn't generate into the data folder. Then just install as you would out put from DynDOLOD. Check how many duplicate trees it reports. Check if the problem happens too or not. Maybe my multithreading update to that code is doing things. If the wrong tree LOD also happen with SSELODGen then continue.

 

(3) Look up which mods add or change the trees themselves for which this happens. Open console and click on the full model and take note of the form id. First two numbers are load order ID of plugin in hex. You can also look the form id up in xEdit. Do this for all trees where this happens, since the tree generation in xEdit is supposed to not create LOD for duplicate form id of trees this will not necessarily discover all form ids / mods, but for now lets see what mods you find.

Ok here are the test results: :D

 

1- Since they are tree LODs, hiding Meshes\Terrain\Tamriel\Trees folder makes them go away. 

 

2 - Downloaded xEdit from the link you posted and ran it with the command line argument pointing to MO's overwrite folder but unfortunately those LODs still stay put. Btw, observed a couple of things while generating tree LODs with xEdit that might interest you:

i - The color mismatch I was previously having with LODs generated for Pines of Whiterun (colors didn't exactly match because they were object LODs instead of actual tree LODs, weather mods/ENB aggravated the problem, needed to increase FlatLODLightingEffect value - post 61) isn't happening with xEdit. Its a proper match with other pine tree LODs.

ii - On the flipside, lots and lots of persistent LODs once I actually enter Whiterun which doesn't happen with DynDOLOD. 

 

3 - Looked up the id in the console and they all start with the same number which MO's mod index tells me belongs to Whiterun Forest as expected. Maybe something about these handful of trees added by the mod that none of the tree LOD generating programs like?  

Edited October 11, 2017 by XenolithicYardZone

[sheson]

Ok here are the test results: :D

 

1- Since they are tree LODs, hiding Meshes\Terrain\Tamriel\Trees folder makes them go away. 

 

2 - Downloaded xEdit from the link you posted and ran it with the command line argument pointing to MO's overwrite folder but unfortunately those LODs still stay put. Btw, observed a couple of things while generating tree LODs with xEdit that might interest you:

i - The color mismatch I was previously having with LODs generated for Pines of Whiterun (colors didn't exactly match because they were object LODs instead of actual tree LODs, weather mods/ENB aggravated the problem, needed to increase FlatLODLightingEffect value - post 61) isn't happening with xEdit. Its a proper match with other pine tree LODs.

ii - On the flipside, lots and lots of persistent LODs once I actually enter Whiterun which doesn't happen with DynDOLOD. 

 

3 - Looked up the id in the console and they all start with the same number which MO's mod index tells me belongs to Whiterun Forest as expected. Maybe something about these handful of trees added by the mod that none of the tree LOD generating programs like?  

Also make sure to disable all LOD generated by DynDOLOD for the test. Overwrite folder *should* work, but please verify that LOD generated by DynDOLOD is not in the load order at all.

We want to be sure tree LOD generated by latest xEdit and DynDOLOD match. It is the same routines, i just made them multithreaded.

 

Since LOD trees generated by xEdit are only using the tree LOD engine, all their lighting reaction will be same. Since there are no rules and settings like in DynDOLOD preventing trees in Whiterun to be done as tree LOD, that engine limitation shows up again. That was to be expected of this test.

 

What numbers is report for the duplicate form ids in the xEdit log?

 

Can you give me some of those form ids? I will then install that mod and see if I can replicate.

Edited October 11, 2017 by sheson

[XenolithicYardZone]

Also make sure to disable all LOD generated by DynDOLOD for the test. Overwrite folder *should* work, but please verify that LOD generated by DynDOLOD is not in the load order at all.

We want to be sure tree LOD generated by latest xEdit and DynDOLOD match. It is the same routines, i just made them multithreaded.

 

Since LOD trees generated by xEdit are only using the tree LOD engine, all their lighting reaction will be same. Since there are no rules and settings like in DynDOLOD preventing trees in Whiterun to be done as tree LOD, that engine limitation shows up again. That was to be expected of this test.

 

What numbers is report for the duplicate form ids in the xEdit log?

 

Can you give me some of those form ids? I will then install that mod and see if I can replicate.

No nothing's overwriting the LODs generated by xEdit. I disabled the DynDOLOD o/p folder completely before running xEdit. 

 

Ok I see. That's why. 

 

Same thing in the xEdit log - <Warning: 1 duplicate FormID numbers of trees references were detected, excluded from LOD>

 

I'll note the ids of most trees that I can find with this issue and post back in a little while. 

Edited October 11, 2017 by XenolithicYardZone

[XenolithicYardZone]

Can you give me some of those form ids? I will then install that mod and see if I can replicate.

Form ids:

1600597d

16005925

16005926

16005954

16005928

16005929

1600aae5

1600591b

1600592a

 

Pics with ids:

https://imgur.com/a/n5ZEv

 

Note: Whiterun Forest adds a lot of trees outside Whiterun so most probably I have missed some of these afflicted trees but I am guessing a common issue plagues them all so hopefully these ids are enough to help you figure out what's going on.

Edited October 11, 2017 by XenolithicYardZone

[sheson]

 

Form ids:

1600597d

16005925

16005926

16005954

16005928

16005929

1600aae5

1600591b

1600592a

 

Pics with ids:

https://imgur.com/a/n5ZEv

 

Note: Whiterun Forest adds a lot of trees outside Whiterun so most probably I have missed some of these afflicted trees but I am guessing a common issue plagues them all so hopefully these ids are enough to help you figure out what's going on.

 

Using just a simply setup with this mod does not cause any problems here, also no duplicate form id reported. That probably means that most likely another plugins is required to reproduce this.

 

The other plugin(s) also add trees in the same or adjacent (5x5 uGrids) cells where this is happening. You could try this to compile a hopefully short list of potential plugins:

 

Enter any of the form ids into xEdit top left FormID field and press enter.

In the right window where it shows all the reference data of that tree, find the top row "Cell", CTRL+CLICK the entry in the whiteforest.esp column [CELL:xxxxxx] (in Tamriel "Skyrim" [WRLD:0000003C] at... and once in the Cell data shows, take note of all other plugins than the vanilla+DLC or unofficial patch.

 

You can also click the cell entry in the left tree view and if no other plugin is listed in the particular cell record find adjacent cells by looking at the coordinates in the Name column. 

 

You also could just quickly click or arrow key through all couple dozen cells whiterunforest changes in the same Sub-Blocks and note any other plugin. There probably won't be many.

Edited October 11, 2017 by sheson