DynDOLOD 3.00 Alpha 173

[MisterMorden]

Hi sheson, I had an error with the latest alpha (99) when using the large reference bug workaround.  Using alpha 99 without the workaround worked (but in my rush to get to work this morning I forgot to get the logs/bug report from the alpha 99 run without the workaround enabled).  I realize there are a metric ton of warnings & errors, however none of these have stopped the generation with an error box in previous generations/alphas...not to say there aren't visual problems, bugs and crashes yet to be discovered in playing.  Anyhoo, here are the logs & bugreport:

Bugreport:

https://ufile.io/723k081q

dyndolod_sse_debug_log:

https://ufile.io/y4etkbff

texgen_sse_debug_log:

https://ufile.io/azrv36a4

texgen_sse_log:

https://ufile.io/ypqk2j7z

dyndolod_sse_log:

https://ufile.io/605098gx

Edited September 30, 2022 by MisterMorden

[sheson]

37 minutes ago, Blackread said:

While I was running around the Whiterun area doing some testing I came across this:

Looks like it's a part of the Pale Hearthfire house. It stayed visible in the large ref grid but disappeared when the cell loaded in. Here are the logs: https://mega.nz/file/xX0TBJAQ#-L1jMJHERaUd7bimCeaqP5xQ1y6TyXxoGf50SVlLUoA I noticed there were some Out of memory errors, maybe they are related.

I also had some trouble with my LOD 4 distance. It seems that there is some lower limit under which it won't go no matter what I set in the ini.

Using the sliders in the DynDOLOD MCM I estimated the distance the LOD 4 is displayed at to be somewhere around 40 000 units. Increasing the distance above that will extend the LOD 4, but dropping it below 40k has no effect. Is there some other setting I also need to adjust to drop it further, or is it somehow tied to near / far grid or the large ref grid size?

Address the memory errors https://dyndolod.info/FAQ "High memory usage / Out of memory" and https://dyndolod.info/Help/Occlusion-Data#Out-of-Memory-while-Generating-Occlusion-Data

Check for errors/messages from the SHESON_DynDOLOD_* scripts in papyrus log in regards to the house.
Should there be any HearthFires buildings at all or was nothing built yet?
Did you speed run (above 500)? You got there by walking from where? Can it be replicated?

fBlockLevel0Distance sets the max distance of the first LOD level 4, e.g. where LOD level 8 starts.
LOD Level 4 is 4x4 cells = 16384 x 16384 game units. It is not entirely clear  what is used as origin for the fBlockLevel0Distance setting, for example center of current cell, edge of active cells. Center would be another 2.5 = 10240 game units.

Since the next LOD level 8 covers 8x8 cells the game can only replace 2 LOD level 4s at a time with a LOD Level 8. See https://dyndolod.info/How-LOD-Works and https://dyndolod.info/Help/Object-LOD#Settings

It should be impossible to have LOD Level 8 touch the active cells. There always has to be a LOD Level 4 next, as it is the only one to contain segments so it can disable object LOD per attached cell.

[sheson]

10 minutes ago, MisterMorden said:

Hi sheson, I had an error with the latest alpha (99) when using the large reference bug workaround.  Using alpha 99 without the workaround worked (but in my rush to get to work this morning I forgot to get the logs/bug report from the alpha 99 run without the workaround enabled).  I realize there are a metric ton of warnings & errors, however none of these have stopped the generation with an error box in previous generations/alphas...not to say there aren't visual problems, bugs and crashes yet to be discovered in playing.  Anyhoo, here are the logs & bugreport:

Bugreport:

https://ufile.io/723k081q

dyndolod_sse_debug_log:

https://ufile.io/y4etkbff

texgen_sse_debug_log:

https://ufile.io/azrv36a4

texgen_sse_log:

https://ufile.io/ypqk2j7z

dyndolod_sse_log:

https://ufile.io/605098gx

See https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-99/?do=findComment&comment=264361

[MisterMorden]

5 minutes ago, sheson said:

See https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-99/?do=findComment&comment=264361

Many thanks sheson!  And I usually keep up with the thread so well...

[darkrain261]

15 minutes ago, sheson said:

Is this running a real Windows?

Did you set an environment variable DOTNET_SYSTEM_GLOBALIZATION_INVARIANT? If this does not mean anything to you, open a command prompt and execute the "set" command and check its ouput.

Unrelated: Read https://dyndolod.info/Generation-Instructions and error check the load order with xEdit and clean plugins before generating LOD. Do not install outdated LOD assets for DynDOLOD 2.x. See https://dyndolod.info/Mods/Majestic-Mountains.

It seems that the output does not mention about DOTNET_SYSTEM_GLOBALIZATION_INVARIANT. Here is the full log: https://paste.ee/p/1wM8i

Thanks for the instruction about Majestic Mountain, it was updated with new LOD Pack. When let the new pack overwriting DynDOLOD Resources SE, it gave the "texture do not match" warnings. If I let the Resource overwrite the pack, the warnings are gone. Hope I'm doing it right.

[sheson]

36 minutes ago, darkrain261 said:

It seems that the output does not mention about DOTNET_SYSTEM_GLOBALIZATION_INVARIANT. Here is the full log: https://paste.ee/p/1wM8i

Thanks for the instruction about Majestic Mountain, it was updated with new LOD Pack. When let the new pack overwriting DynDOLOD Resources SE, it gave the "texture do not match" warnings. If I let the Resource overwrite the pack, the warnings are gone. Hope I'm doing it right.

Something is weird with the OS locale / globalization or .NET setup, since it won't accept en-us for some reason.

Lets try not to use a specific culture at all and see what happens with this test version https://mega.nz/file/FVx32RoY#Lmwwv_fFG-OXlRJAIGk82Ma0AVFIurgx6Su86ZiEmzk, just replace the file in the Edit Script folder.

That DynDOLOD 2.x and DynDOLOD 3.x LOD assets are mixed together in a single download archive is unfortunate and needs to be rectified some time in the future.

[Blackread]

4 hours ago, sheson said:

Address the memory errors https://dyndolod.info/FAQ "High memory usage / Out of memory" and https://dyndolod.info/Help/Occlusion-Data#Out-of-Memory-while-Generating-Occlusion-Data

Check for errors/messages from the SHESON_DynDOLOD_* scripts in papyrus log in regards to the house.
Should there be any HearthFires buildings at all or was nothing built yet?
Did you speed run (above 500)? You got there by walking from where? Can it be replicated?

fBlockLevel0Distance sets the max distance of the first LOD level 4, e.g. where LOD level 8 starts.
LOD Level 4 is 4x4 cells = 16384 x 16384 game units. It is not entirely clear  what is used as origin for the fBlockLevel0Distance setting, for example center of current cell, edge of active cells. Center would be another 2.5 = 10240 game units.

Since the next LOD level 8 covers 8x8 cells the game can only replace 2 LOD level 4s at a time with a LOD Level 8. See https://dyndolod.info/How-LOD-Works and https://dyndolod.info/Help/Object-LOD#Settings

It should be impossible to have LOD Level 8 touch the active cells. There always has to be a LOD Level 4 next, as it is the only one to contain segments so it can disable object LOD per attached cell.

Thank you for the LOD Level explanation, I understand it better now.

I tried to solve the out of memory issue by setting the OcclusionMaxThreadsObjectLOD to 1, but it didn't help. This time there was an access violation. I forgot to copy the error window, but here are the logs along with the bugreport. I looked into other possible solutions too, but the grass LOD is already quite low density, and the 3D trees are from Happy Little Trees which should be adequately optimized I believe. When it comes to other full models in object LOD I'm not entirely sure, the only mod I definitely know to use full models is More Wooden Bridges. I feel like something has maybe changed in the way the height data is calculated from object LOD, because back in the beginning of August I successfully generated a grass LOD with 100 density (with the same grass mod and settings). It took at least 15 minutes for the height data for Tamriel to be calculated and maybe 1.5 hours for the whole generation (Tamriel only), but there were no errors.

The HearthFires building should not be there, I was straight out of the alternate start room. I ran from Honningbrew Meadery along the east side of Whiterun to the whitewatch tower, where I first noticed the misplaced building. It is fully replicable on that LOD generation (I haven't successfully completed another one yet). I hadn't altered my speed mult, it was vanilla (or very close to it at least).

Edit: Forgot to mention, nothing in Papyrus logs.

Edit2: Did another DynDOLOD run without Occlusion just to see if the HearthFires building is still there, and it looks like it is. Logs Seems it is replicable at least on this mod list. Still nothing in Papyrus logs. I'll root out the memory issues when I have the time.

Edited September 30, 2022 by Blackread

[darkrain261]

3 hours ago, sheson said:

Something is weird with the OS locale / globalization or .NET setup, since it won't accept en-us for some reason.

Lets try not to use a specific culture at all and see what happens with this test version https://mega.nz/file/FVx32RoY#Lmwwv_fFG-OXlRJAIGk82Ma0AVFIurgx6Su86ZiEmzk, just replace the file in the Edit Script folder.

That DynDOLOD 2.x and DynDOLOD 3.x LOD assets are mixed together in a single download archive is unfortunate and needs to be rectified some time in the future.

Thank you! The underside mesh is finally generated with the file you sent.

Also, Majestic Mountain's lod pack has been updated so the warning is also fixed. I really appreciate your quick support. Cheers!

[sheson]

11 minutes ago, darkrain261 said:

Thank you! The underside mesh is finally generated with the file you sent.

Also, Majestic Mountain's lod pack has been updated so the warning is also fixed. I really appreciate your quick support. Cheers!

That is great. Thanks for letting us know.

[darikzen]

On 9/30/2022 at 4:40 AM, sheson said:

Read the first post which log, debug log and bugreport.txt to upload when making posts.

Unclear what "tried to pack output myself and load it into the game" is supposed to mean.

No actual information about "a bug with light source causing high density particles near them"

See https://dyndolod.info/Official-DynDOLOD-Support-Forum

logs and bug reports - https://ufile.io/pn1y1h65

modwatch - https://modwat.ch/u/darikzen/plugins

by "tried to pack output myself and load it into the game" I mean that DynDOLOD didn't suggest to zip output and exit after the last error, so I tried to zip it myself

Edited October 1, 2022 by darikzen

[darikzen]

42 minutes ago, darikzen said:

logs and bug reports - https://ufile.io/pn1y1h65

modwatch - https://modwat.ch/u/darikzen/plugins

by "tried to pack output myself and load it into the game" I mean that DynDOLOD didn't suggest to zip output and exit after the last error, so I tried to zip it myself

actually, I've just checked and TexGen contains errors too https://ufile.io/x9yqwzr0

[darkrain261]

10 hours ago, sheson said:

That is great. Thanks for letting us know.

Hello, it's me again. I think I found the source of problem. I'm using Vortex and the newest version of it has something wrong with the variable you said "DOTNET_SYSTEM_GLOBALIZATION_INVARIANT". If I launch DynDOLOD (with original LODGenx64Win.exe - not the one you sent) through Vortex as tool then I got the problem I mentioned. However, if launch DynDOLOD directly, then it works normally.

In addition, adding the environment variable: DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=0 in the DynDOLOD shortcut in Vortex also solves the problem. So it's not my NET runtime but the Vortex itself causing the issue. Once again thanks for your wonderful DynDOLOD and support for players.

[sheson]

13 hours ago, Blackread said:

Thank you for the LOD Level explanation, I understand it better now.

I tried to solve the out of memory issue by setting the OcclusionMaxThreadsObjectLOD to 1, but it didn't help. This time there was an access violation. I forgot to copy the error window, but here are the logs along with the bugreport. I looked into other possible solutions too, but the grass LOD is already quite low density, and the 3D trees are from Happy Little Trees which should be adequately optimized I believe. When it comes to other full models in object LOD I'm not entirely sure, the only mod I definitely know to use full models is More Wooden Bridges. I feel like something has maybe changed in the way the height data is calculated from object LOD, because back in the beginning of August I successfully generated a grass LOD with 100 density (with the same grass mod and settings). It took at least 15 minutes for the height data for Tamriel to be calculated and maybe 1.5 hours for the whole generation (Tamriel only), but there were no errors.

The HearthFires building should not be there, I was straight out of the alternate start room. I ran from Honningbrew Meadery along the east side of Whiterun to the whitewatch tower, where I first noticed the misplaced building. It is fully replicable on that LOD generation (I haven't successfully completed another one yet). I hadn't altered my speed mult, it was vanilla (or very close to it at least).

Edit: Forgot to mention, nothing in Papyrus logs.

Edit2: Did another DynDOLOD run without Occlusion just to see if the HearthFires building is still there, and it looks like it is. Logs Seems it is replicable at least on this mod list. Still nothing in Papyrus logs. I'll root out the memory issues when I have the time.

If you set it single threaded to read the BTO, there is really not much else to do, other than generating Occlusion in a separate step for minimum initial memory foot print.
Check if the mentioned BTO open in NifSkope without error.

Honestly, if generation starts taking hours for Tamriel, then there is just too much stuff being added. How large are the BTO files?

I will see if I can replicate the HearthFires house with the experimental workarounds.

[sheson]

3 hours ago, darikzen said:

logs and bug reports - https://ufile.io/pn1y1h65

modwatch - https://modwat.ch/u/darikzen/plugins

by "tried to pack output myself and load it into the game" I mean that DynDOLOD didn't suggest to zip output and exit after the last error, so I tried to zip it myself

Pay attention to log message https://dyndolod.info/Messages and the summary https://dyndolod.info/Help/Summary-Of-Messages

In this case the issue is probably caused by several plugins adding the same new cells:

[00:48] <Warning: Potentially wild edit cell JKs Skyrim.esp [CELL:27023913] (in RiftenWorld "Riften" [WRLD:00016BB4] at -1,-1)>
[00:48] <Warning: Potentially wild edit cell RLO - Exteriors.esp [CELL:390116D5] (in RiftenWorld "Riften" [WRLD:00016BB4] at -1,-1)>
See https://dyndolod.info/Messages/Potentially-Wild-Edit-Cell

[00:48] <Warning: Duplicate Cell at -1,-1 in JKs Skyrim.esp [CELL:27023913] (in RiftenWorld "Riften" [WRLD:00016BB4] at -1,-1) and RLO - Exteriors.esp [CELL:390116D5] (in RiftenWorld "Riften" [WRLD:00016BB4] at -1,-1)>
See https://dyndolod.info/Messages/Duplicate-Cell

Riften is not near the center of the map, so there is most likely no real reason for any plugin to add new cells at -1,-1 for it.
The cell records can/should probably be removed with xEdit for example.

https://dyndolod.info/Generation-Instructions#2-Generate-The-LOD-Mod-with-DynDOLOD
Pay attention to all log messages. It should end with the log message 'DynDOLOD plugins generated successfully' and lines like 'LODGen generated object LOD for [WORLDSPACE] successfully' for each selected worldspace. Do not use the output if there were errors that stopped the process prematurely.

3 hours ago, darikzen said:

actually, I've just checked and TexGen contains errors too https://ufile.io/x9yqwzr0

https://dyndolod.info/Messages/File-Not-Found-Textures
In case a texture is not found while running TexGen, it will be substituted with the default diffuse (full red color) for *.DDS or the default normal map (flat surface) for *_n.DDS automatically. The first should be very obvious in case the generated object LOD texture or LOD billboard is used in the game and typically needs to be fixed. The flat normal map substitute means the surface of the object will be flat, which might not be a very visible problem if at all.

If the trees / billboards are not used in the game / for LOD generation, then you won't see any visual issues.

[sheson]

1 hour ago, darkrain261 said:

Hello, it's me again. I think I found the source of problem. I'm using Vortex and the newest version of it has something wrong with the variable you said "DOTNET_SYSTEM_GLOBALIZATION_INVARIANT". If I launch DynDOLOD (with original LODGenx64Win.exe - not the one you sent) through Vortex as tool then I got the problem I mentioned. However, if launch DynDOLOD directly, then it works normally.

In addition, adding the environment variable: DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=0 in the DynDOLOD shortcut in Vortex also solves the problem. So it's not my NET runtime but the Vortex itself causing the issue. Once again thanks for your wonderful DynDOLOD and support for players.

Thanks for this insight. This will help dealing with this error message from unsuspecting users, which will most likely be coming up for years unless Vortex is "fixed".