Jump to content

DynDOLOD 3.00 Alpha 171


sheson

Recommended Posts

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:

Screen-Shot302.png

Screen-Shot303.png

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.

Link to comment
Share on other sites

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 by PRieST
Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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 by PRieST
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

18 minutes ago, sheson said:

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.

Thanks for taking care of those trees! Regarding the glacier LOD meshes, touching the UVs was something I tried to avoid, haha. But thanks for making me aware of that! I know about the UV range of 0.0-1.0 for older games like Fallout 3, as the LOD textures were broken if they were outside of that range. Is there any way to take care of that in Blender, without redoing them by hand? Because that sounds like a nightmare...

I checked the draw calls with ENB to make sure the performance impact is minimal, but if possible I would of course optimize them further.

And thanks, I missed that glacierslabreallod.dds (glacierslabreallod_n.dds too I guess) was generated by TexGen. I will change the assigned texture then!

Edited by Phlunder
Link to comment
Share on other sites

2 minutes ago, Phlunder said:

Thanks for taking care of those trees! Regarding the glacier LOD meshes, touching the UVs was something I tried to avoid, haha. But thanks for making me aware of that! I know about the UV range of 0.0-1.0 for older games like Fallout 3, as the LOD textures were broken if they were outside of that range. Is there any way to take care of that in Blender, without redoing them by hand? Because that sounds like a nightmare...

I checked the draw calls with ENB to make sure the performance impact is minimal, but if possible I would of course optimize them further.

No idea about blender since I don't use it. There could be a function or plugin to do it. Simplygon can do it as a step before the optional decimating. It only becomes a problem if there are lots of models with different textures not being able to use the object LOD texture atlas.

Link to comment
Share on other sites

16 minutes ago, sheson said:

No idea about blender since I don't use it. There could be a function or plugin to do it. Simplygon can do it as a step before the optional decimating. It only becomes a problem if there are lots of models with different textures not being able to use the object LOD texture atlas.

Ah, so they are currently not using the atlas, but the glacierslablod textures directly? I thought of the glacier LODs similar to the LOD0 mountain meshes (which I use in all LOD stages with a rule in DynDOLOD) so I assumed that method was okay? Similar to mountainslab, its also just a single tiled texture for the whole object.

I guess, this is a bigger problem with complex meshes like farmhouses or other buildings that use multiple texture sets. And all of them not using the atlas would degrade performance quickly. Simplygon sounds interesting, thanks for mentioning it!

Edited by Phlunder
Link to comment
Share on other sites

1 hour ago, Phlunder said:

Ah, so they are currently not using the atlas, but the glacierslablod textures directly? I thought of the glacier LODs similar to the LOD0 mountain meshes (which I use in all LOD stages with a rule in DynDOLOD) so I assumed that method was okay? Its also just a single texture for the whole object.

I guess, this is a bigger problem with complex meshes like farmhouses or other buildings that use multiple texture sets. And all of them not using the atlas would degrade performance quickly. Simplygon sounds interesting, thanks for mentioning it!

Each shape that can not use the texture atlas can potentially require several distinct shapes in a each BTO, for the different material LOD shaders, large reference or not. A couple dozen BTO files show at the same time. So if one shape requires 2 to 4 shapes in a BTO can become a 100 or more draw calls if it used often. No problem for one type of shader/texture. It can quickly multiply if there are several often used LOD models with different textures.

Link to comment
Share on other sites

Hi again, posting here what I reported to you in cathedral discord:
"I just encountered some strange behaviour when generating lods with dyndolod with this mod https://www.nexusmods.com/skyrimspecialedition/mods/14663?tab=description enabled. Dyndolod.esm has esp of ashbound as a master but I physically can't move ashbound's esp higher"
Debug log is whole 60 mb so I don't know how to upload it

DynDOLOD_SSE_log.txt

Link to comment
Share on other sites

So I have often had grass LOD succesfully done before, but this time I am running into problems with the grass LOD's not appearing beyond the UGridsToLoad setting (NGIO mode to 1 and Dyndolod too). The generation completes successfully with grass lods (I checked the logs as described here https://dyndolod.info/Help/Grass-LOD).

NGIO is succesfully setting the grass to do full render up until ugrids, but after that LOD should appear, which is not happening.

Any clue as to why this might be happening?

When I tfc to outside of ugrids (even without tfc I can see that grass lod is not working):

unknown.png

unknown.png

Link to comment
Share on other sites

2 hours ago, KLRBDN said:

Hi again, posting here what I reported to you in cathedral discord:
"I just encountered some strange behaviour when generating lods with dyndolod with this mod https://www.nexusmods.com/skyrimspecialedition/mods/14663?tab=description enabled. Dyndolod.esm has esp of ashbound as a master but I physically can't move ashbound's esp higher"
Debug log is whole 60 mb so I don't know how to upload it

DynDOLOD_SSE_log.txt 1.12 MB · 1 download

Upload the debug log to a file service as explained on the first post.

Load the load order into xEdit and run the "Report Masters" script on the DynDOLOD.esm and check the ashbound.esp in the list and post/upload the lines the script prints to the message window.

1 hour ago, wdk said:

So I have often had grass LOD succesfully done before, but this time I am running into problems with the grass LOD's not appearing beyond the UGridsToLoad setting (NGIO mode to 1 and Dyndolod too). The generation completes successfully with grass lods (I checked the logs as described here https://dyndolod.info/Help/Grass-LOD).

NGIO is succesfully setting the grass to do full render up until ugrids, but after that LOD should appear, which is not happening.

Any clue as to why this might be happening?

When I tfc to outside of ugrids (even without tfc I can see that grass lod is not working):
 

Read the fist post what log files to upload when making posts.

Go through the https://dyndolod.info/Help/Grass-LOD#No-Grass-LOD-Check-List 

The screenshots seem to show that there is LOD for some grass already. Most likely the other grasses have no billboards because the base records have too small or no object bounds.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

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