DynDOLOD 3.00 Alpha 190

[d1ebels]

Hi,

in the last days, i tried to generate grass in dyndolod, but i cant get it to show in game. On this way, some things confuse me.

I read on some grass mods pages on Nexus that the generation of grass failes if the grass has "No Object Bound". Is this true? And what does that mean for the popular grass mods like Verdant and Folkvangr? They cant be used until the Mod Authors updates this? I use Verdant, so maybe this is the problem?

Another thing that grinds my gears is the need of Grass LOD. With NGIO, the draw distance could be set to very high values, which would eliminate the need of Grass LOD.

Does Grass LOD has much better performance than the grass from NGIO? Seems obvious, but i just want confirmation on this.

Another thing is: It would help a lot, when some Users who did get Grass LOD to work would upload Pictures as reference. By doing this, the new User would know that it is possible with different LOs and different grass mods. The OPs from you seem to be with a Vanilla Setup.

So now to my Grass LOD generation:

Skyrim 1.5.80

DynDOLODGrassMode = 1

uGridsToLoad = 7

https://ufile.io/f/jzlj3

Result: Grass loaded in loaded Grids, but cuts right after that. No sign of any grass from Grass LOD

[sheson]

21 minutes ago, d1ebels said:

Hi,

in the last days, i tried to generate grass in dyndolod, but i cant get it to show in game. On this way, some things confuse me.

I read on some grass mods pages on Nexus that the generation of grass failes if the grass has "No Object Bound". Is this true? And what does that mean for the popular grass mods like Verdant and Folkvangr? They cant be used until the Mod Authors updates this? I use Verdant, so maybe this is the problem?

Another thing that grinds my gears is the need of Grass LOD. With NGIO, the draw distance could be set to very high values, which would eliminate the need of Grass LOD.

Does Grass LOD has much better performance than the grass from NGIO? Seems obvious, but i just want confirmation on this.

Another thing is: It would help a lot, when some Users who did get Grass LOD to work would upload Pictures as reference. By doing this, the new User would know that it is possible with different LOs and different grass mods. The OPs from you seem to be with a Vanilla Setup.

So now to my Grass LOD generation:

Skyrim 1.5.80

DynDOLODGrassMode = 1

uGridsToLoad = 7

https://ufile.io/f/jzlj3

Result: Grass loaded in loaded Grids, but cuts right after that. No sign of any grass from Grass LOD

Read the second post and the grass LOD manual it links https://dyndolod.info/Help/Grass-LOD.

The entire process is explained with links to further explanations about things, including how TexGen uses the object bounds to decide for which grasses or trees to generate billboards for automatically. It also links to explanations about the objects bounds and how to use the CK to update the object bounds . Search this thread for similar discussions and explanations.

Make sure to read the https://dyndolod.info/Help/Grass-LOD#No-Grass-LOD-Check-List

Of course you can increase the distance of full grass to render as far as you want with  NGIO instead of using grass LOD. However, obviously grass LOD requires less resources and performance than full model grass as explained on https://dyndolod.info/Help/Grass-LOD.

For performance and stability leave uGridsToLoad default.

[d1ebels]

15 minutes ago, sheson said:

Read the second post and the grass LOD manual it links https://dyndolod.info/Help/Grass-LOD.

The entire process is explained with links to further explanations about things, including how TexGen uses the object bounds to decide for which grasses or trees to generate billboards for automatically. It also links to explanations about the objects bounds and how to use the CK to update the object bounds . Search this thread for similar discussions and explanations.

Make sure to read the https://dyndolod.info/Help/Grass-LOD#No-Grass-LOD-Check-List

Of course you can increase the distance of full grass to render as far as you want with  NGIO instead of using grass LOD. However, obviously grass LOD requires less resources and performance than full model grass as explained on https://dyndolod.info/Help/Grass-LOD.

For performance and stability leave uGridsToLoad default.

Alright, seems like the object bounds are at fault.

https://imgur.com/a/w2NzgT3

kinda hard to see, but there are some grass lods, but only for snowy grass. the brown grass seems to have problems. I will try to update it in the CK.

Thanks for support!

 

[d1ebels]

i got it to work by setting the object bounds in the CK for Verdant! Only thing left is the adjustment of the LOD brightness of grass. I have to tinker around. But so far, so good!

[PRieST]

Hey again,
maybe this is an alpha 58 thing, I don't know, but I haven't had this issue prior to version .57 I think.

Sometimes some LODs won't dissappear if I come closer. They will overlapping with the full models until I went in an interior cell and right back outsite. But I could only observe it near villages/towns and not all models are affected. There it is a tree, there a house (but than not all trees ore houses), rocks, etc.

First I thought it has something to do like in this thread, but I had never made this ini setting: uLockedObjectMapLOD=32 (so I assume it was always =16) or could it be helpful to generate again, but this time with Level32=1 and uLockedObjectMapLOD=32?
I did not changed my loadorder since the last generation without the issue - at least I assume so. If I did changed the loadorder and I used the Skyrim SE - Generate Large Reference script via xEdit, is it possible to regenerate them without redownloading the plugin. Maybe there are now references on the wrong position, because the loadorder changed? Or do I misunderstand this?

Here are the logs from the last generation (as I don't exactly know which one you need, I put all in there) - and yes I know, there are some 'overwritten large references' and ' initially disabled references' in the report, but they were never a problem - if they are a problem now): Link to download

And here is a picture as an example what happens (this is from Annekes House in Darkwatercrossing - if I would go from here to Ivarstead, there would be the same result with buildings, trees, etc.):

I looked the building ID up in xEdit, it's only Skyrim related and doesn't get overwritten by anything. uGridsToLoad is set (and has always been) to = 5.

Maybe I did something fundamentally wrong with flagging plugins as .esm and generate the Large References via script. This happened never before. For me it looks as if DynDOLOD 'is not fast enough' to switch from LOD to fullmodel and than both stick at the same place. I observe the 'flicker' while changing often (I know this is engine related) but in these cases the change won't happen.

Let me know if I could do anything else before I try to generate LODs again - or is an updating enough?

Edited December 31, 2021 by PRieST

[sheson]

34 minutes ago, PRieST said:

Hey again,
maybe this is an alpha 58 thing, I don't know, but I haven't had this issue prior to version .57 I think.

Sometimes some LODs won't dissappear if I come closer. They will overlapping with the full models until I went in an interior cell and right back outsite. But I could only observe it near villages/towns and not all models are affected. There it is a tree, there a house (but than not all trees ore houses), rocks, etc.

First I thought it has something to do like in this thread, but I had never made this ini setting: uLockedObjectMapLOD=32 (so I assume it was always =16) or could it be helpful to generate again, but this time with Level32=1 and uLockedObjectMapLOD=32?
I did not changed my loadorder since the last generation without the issue - at least I assume so. If I did changed the loadorder and I used the Skyrim SE - Generate Large Reference script via xEdit, is it possible to regenerate them without redownloading the plugin. Maybe there are now references on the wrong position, because the loadorder changed? Or do I misunderstand this?

Here are the logs from the last generation (as I don't exactly know which one you need, I put all in there) - and yes I know, there are some 'overwritten large references' and ' initially disabled references' in the report, but they were never a problem - if they are a problem now): Link to download

And here is a picture as an example what happens (this is from Annekes House in Darkwatercrossing - if I would go from here to Ivarstead, there would be the same result with buildings, trees, etc.):

I looked the building ID up in xEdit, it's only Skyrim related and doesn't get overwritten by anything. uGridsToLoad is set (and has always been) to = 5.

Maybe I did something fundamentally wrong with flagging plugins as .esm and generate the Large References via script. This happened never before. For me it looks as if DynDOLOD 'is not fast enough' to switch from LOD to fullmodel and than both stick at the same place. I observe the 'flicker' while changing often (I know this is engine related) but in these cases the change won't happen.

Let me know if I could do anything else before I try to generate LODs again - or is an updating enough?

See answer for "Object LOD shows in active exterior cells" and "Out of place or floating objects"" at  https://dyndolod.info/FAQ

The screenshot and post does not seem to mention if the object showing the LOD model is from object LOD that disappears with tll in console or is a reference that has its own form id.

Normally the walkway 00062E56 is not a large reference and should not have dynamic LOD.

So, if it is object LOD that does not unload it is typically the uLockedObjectMapLOD or the fBlockLevel0Distance with a value close to 60,000.
Test with vanilla INI using the High setting for Distant Object Detail.

I can not troubleshoot "maybe flagging plugins as ESM did this" etc. Test with unmodified plugins. Large reference bugs happen outside the active cells.

[Omniguous]

hi again.. just wanted to tie loose ends.

i ran the lodgen "as normal" except i didnt use the 'high trees' plugin at all (removed from load order).

it had ~9,000 files. so, i checked the log. did a search for ERROR. found 1 result. it had to do with "optimize unseen on LOD32"

it recommended running with that OFF or on x64 binary. i tried the x64 binary.

no ERROR in log AND it had ~12,000 files.

going to presume that that error caused the aforementioned 3,000-file discrepancy that i erroneously attributed to the ITM.

thank you for your patience.

PS: i just launched with this fresh LOD and the graphical glitch with the trees isnt happening anymore. dang intermittent glitches.

[PRieST]

On 12/31/2021 at 2:41 PM, sheson said:

See answer for "Object LOD shows in active exterior cells" and "Out of place or floating objects"" at  https://dyndolod.info/FAQ

The screenshot and post does not seem to mention if the object showing the LOD model is from object LOD that disappears with tll in console or is a reference that has its own form id.

Normally the walkway 00062E56 is not a large reference and should not have dynamic LOD.

So, if it is object LOD that does not unload it is typically the uLockedObjectMapLOD or the fBlockLevel0Distance with a value close to 60,000.
Test with vanilla INI using the High setting for Distant Object Detail.

I can not troubleshoot "maybe flagging plugins as ESM did this" etc. Test with unmodified plugins. Large reference bugs happen outside the active cells.

So, first, I regenerated with Level32=1 and uLockedObjectMapLOD=32 -> no difference.
Second, I got rid of FPS Stabilizer as I thought it would cause the issue -> no difference.
I am using fBlockLevel0Distance at 35,000 (I think this is the vanilla/default value?) -> no difference.

I went again from Ivarstead to Darkwater Crossing and made again two screenshots to show, that there are definitely LODs which are staying at the same place as the full models. I used the tll command the the LODs are disappearing as expected:

Everywhere else the LODs and full models are switching correctly, but not in villages/towns if I come close. As said before, as I go into in interior cell and go outside again, the LODs are dissapeared as the should.

I thought about at what time it happened: And I assume it wasn't with version .53 or .54 I could test it in generating LODs with one of these versions to know exactly at what point it happened. Never had this problem before and I changed nothing despite adding/removing mods completely unrelated to landscapes/worldspace edits. It still could be a user error as I did something fundamentally wrong, but maybe it's still a bug in the alpha, I don't know.

Edited January 1, 2022 by PRieST

[sheson]

1 hour ago, PRieST said:

So, first, I regenerated with Level32=1 and uLockedObjectMapLOD=32 -> no difference.
Second, I got rid of FPS Stabilizer as I thought it would cause the issue -> no difference.
I am using fBlockLevel0Distance at 35,000 (I think this is the vanilla/default value?) -> no difference.

I went again from Ivarstead to Darkwater Crossing and made again two screenshots to show, that there are definitely LODs which are staying at the same place as the full models. I used the tll command the the LODs are disappearing as expected:

Everywhere else the LODs and full models are switching correctly, but not in villages/towns if I come close. As said before, as I go into in interior cell and go outside again, the LODs are dissapeared as the should.

I thought about at what time it happened: And I assume it wasn't with version .53 or .54 I could test it in generating LODs with one of these versions to know exactly at what point it happened. Never had this problem before and I changed nothing despite adding/removing mods completely unrelated to landscapes/worldspace edits. It still could be a user error as I did something fundamentally wrong, but maybe it's still a bug in the alpha, I don't know.

The Skyrim.INI setting uLockedObjectMapLOD does not affect LOD generation.

Generating object LOD level 32 does not change anything about LOD Level 4 or how the engine loads and enables /disable LOD for an attached cell.
Same for generating object LOD 4/8/16 again or with different settings. It generally does not affect or change how the engine works.

To test if this has something to do with the generated object LOD, test what happens if you hide the LOD Level 4 file for that area, so it uses the vanilla object LOD file instead.

To test if this has something to do with records in the DynDOLOD plugins, see what happens if you deactivate the DynDOLOD.esp, then the DynDOLOD.esm.

[PRieST]

1 hour ago, sheson said:

The Skyrim.INI setting uLockedObjectMapLOD does not affect LOD generation.

Generating object LOD level 32 does not change anything about LOD Level 4 or how the engine loads and enables /disable LOD for an attached cell.
Same for generating object LOD 4/8/16 again or with different settings. It generally does not affect or change how the engine works.

To test if this has something to do with the generated object LOD, test what happens if you hide the LOD Level 4 file for that area, so it uses the vanilla object LOD file instead.

To test if this has something to do with records in the DynDOLOD plugins, see what happens if you deactivate the DynDOLOD.esp, then the DynDOLOD.esm.

Reverting the Level 4 file (Tamriel.4.28.-12) to vanilla: difficult to tell as it's much difference between both, but as far as I could've seen, the LOD switchted normal to the full model without both overlapping)

Deactivating the DynDOLOD.esp: LODs and Full models are switching normal.

Edit:
Looked it up in xEdit - DynDOLOD.esp isn't affecting this area at all (DarkwaterCrossingExterior01 where the farmhouse is referenced). Only DynDOLOD.esm has one record in this 'cell': Tamriel_Worshipper_29_%9 - DynDOLOD_WorshipperActivator [STAT:XX000926]

Edited January 1, 2022 by PRieST

[sheson]

9 minutes ago, PRieST said:

Reverting the Level file to vanilla: difficult to tell as it's much difference between both, but as far as I could've seen, the LOD switchted normal to the full model without both overlapping)

Deactivating the DynDOLOD.esp: LODs and Full models are switching normal.

That most likely means neither is the actual cause and it is about memory or resource issue, or still an engine setting. That goes along with the fact that going inside/outside resets the problem.

I suggest to test generating LOD for the vanilla game with the same options, vanilla INIs. Then add one mod or groups of mods most likely affecting the area or that you have edited to see if you can maybe pinpoint this to a specific mod or plugin / type of record for the cell or reference in the cell (unlikely though).

[PRieST]

If this is related to a plugin, than I'll have to find out which plugin causes this.
Darkwater Crossing was just an example. Same things happen with all small/big towns or villages so I don't think it is reference specific. But I just don't know how to solve this as the models/records which are affected are from Skyrim.esm and not from any mod.

Edit: To stay with darkwater crossing at the moment.
The only record, which is affected by DynDOLOD in this area is the base record WalkwayStairs3 [STAT:0004D7B0] where DynDOLOD.esp is setting the 'Has Distant LOD' flag.
The rest (of the reference records) is just vanilla.

Edit 2:

For me it's impossible to track it down to a specific plugin. I disabled all what I could what could be interferring with models/LODs in these spots. It's even stranger es some trees are affected, but not all in the Level 4 .bto by Darkwater Crossing. And again, I did not had this problem with earliere versions of DynDOLOD Alpha. Do you mind on giving me v. 53, I just want to test it (I just need the answer for myself).

Also not only switching interior/exterior, making a save and loading is also letting the LODs disappearing.

Edit 3:

Just noticed, is it normal behavior, that if I deactivate DynDOLOD via MCM, that after a few seconds it gets activated again? There is no message box, but in the MCM I can again deactivate it which will also result in the deactivating message box.

Edited January 2, 2022 by PRieST

[sheson]

13 hours ago, PRieST said:

If this is related to a plugin, than I'll have to find out which plugin causes this.
Darkwater Crossing was just an example. Same things happen with all small/big towns or villages so I don't think it is reference specific. But I just don't know how to solve this as the models/records which are affected are from Skyrim.esm and not from any mod.

Edit: To stay with darkwater crossing at the moment.
The only record, which is affected by DynDOLOD in this area is the base record WalkwayStairs3 [STAT:0004D7B0] where DynDOLOD.esp is setting the 'Has Distant LOD' flag.
The rest (of the reference records) is just vanilla.

Edit 2:

For me it's impossible to track it down to a specific plugin. I disabled all what I could what could be interferring with models/LODs in these spots. It's even stranger es some trees are affected, but not all in the Level 4 .bto by Darkwater Crossing. And again, I did not had this problem with earliere versions of DynDOLOD Alpha. Do you mind on giving me v. 53, I just want to test it (I just need the answer for myself).

Also not only switching interior/exterior, making a save and loading is also letting the LODs disappearing.

Edit 3:

Just noticed, is it normal behavior, that if I deactivate DynDOLOD via MCM, that after a few seconds it gets activated again? There is no message box, but in the MCM I can again deactivate it which will also result in the deactivating message box.

Start troubleshooting by generating LOD without grass LOD and then for the vanilla game with vanilla INI.

Do not install or generate billboards for every little shrub and bush. Do not generate LOD for small fauna in LOD8/16 when using ultra tree LOD.

If anything, make sure that the latest version is installed into a new empty folder and generate with default settings.

Yes it is normal that dynamic LOD activates again when entering a new cell

[Phlunder]

Hey sheson. I have to circle back to a conversation from years ago. In recent runs of DynDOLOD, I noticed that a few trees in the Forgotten Vale were missing LOD again. Then I remembered when I worked on Seamless Billboards that I had to include a plugin to give some duplicate winter aspen trees (as statics) the Has Tree LOD flag to be picked up. As I don't use my billboards or the plugin anymore, this just caught my attention. Maybe you could include them? The statics in question are:

DLC1TreeWinterAspenSnow01 [STAT:0200CE13]
DLC1TreeWinterAspenSnow03 [STAT:0200CE11]
DLC1TreeWinterAspenSnow05 [STAT:0200CE12]

I also worked on those replacers for the glacier LOD meshes we talked about a while ago. As you suggested I used the full models and decimated them by hand and with Blender's tools. If you're interested, you can find them here.

[sheson]

29 minutes ago, Phlunder said:

Hey sheson. I have to circle back to a conversation from years ago. In recent runs of DynDOLOD, I noticed that a few trees in the Forgotten Vale were missing LOD again. Then I remembered when I worked on Seamless Billboards that I had to include a plugin to give some duplicate winter aspen trees (as statics) the Has Tree LOD flag to be picked up. As I don't use my billboards or the plugin anymore, this just caught my attention. Maybe you could include them? The statics in question are:

DLC1TreeWinterAspenSnow01 [STAT:0200CE13]
DLC1TreeWinterAspenSnow03 [STAT:0200CE11]
DLC1TreeWinterAspenSnow05 [STAT:0200CE12]

I also worked on those replacers for the glacier LOD meshes we talked about a while ago. As you suggested I used the full models and decimated them by hand and with Blender's tools. If you're interested, you can find them here.

I will add a patch for those trees so they are always flagged.

For the LOD glaciers, it would be advantages if all their UV always stayed between 0.0 and 1.0. For performance of LOD that is usually more important than vertex, triangle count. Don't worry too much about it, though. it is just a thing to keep in mind.

BTW TexGen generates a glacierslabreallod.dds from glacierslab.dds since the vanilla glacierslablod.dds is not a direct derivative from glacierslab.dds.