DynDOLOD 3.00 Alpha 198

[ToughPaper22]

I have this error and it is driving me crazy. DynDOLOD with Open Cities.

The bug: When I'm about to enter Whiterun it looks like in the photo then when I go through the gate it loads the textures.

I do the installation as explained in the tutorial, I deactivate all the open cities plugins to generate the trees and objects, then I edit the ini "WarnModFileName=Open-Cities-Skyrim ;Open-Cities-Skyrim "by "xOpen Cities Skyrim;Open -Cities-Skyrim" and activate the open cities plugins. I open the DynDOLOD and generate the dynamic LOD. But even though it loads, this happens to me in Whiterun. Does anyone have the solution?

Version of game : Skyrim AE 640. 

Version of DynDOLOD alpha 11

 

[sheson]

47 minutes ago, ToughPaper22 said:

I have this error and it is driving me crazy. DynDOLOD with Open Cities.

The bug: When I'm about to enter Whiterun it looks like in the photo then when I go through the gate it loads the textures.

I do the installation as explained in the tutorial, I deactivate all the open cities plugins to generate the trees and objects, then I edit the ini "WarnModFileName=Open-Cities-Skyrim ;Open-Cities-Skyrim "by "xOpen Cities Skyrim;Open -Cities-Skyrim" and activate the open cities plugins. I open the DynDOLOD and generate the dynamic LOD. But even though it loads, this happens to me in Whiterun. Does anyone have the solution?

Version of game : Skyrim AE 640. 

Version of DynDOLOD alpha 11

 

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

Why do you believe this has anything to do with DynDOLOD? What rudimentary troubleshooting have you done to come to that conclusion?

The issue description sounds like placed occlusion places/boxes, like a patch for eFPS is missing.

[ToughPaper22]

27 minutes ago, sheson said:

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

Why do you believe this has anything to do with DynDOLOD? What rudimentary troubleshooting have you done to come to that conclusion?

The issue description sounds like placed occlusion places/boxes, like a patch for eFPS is missing.

You are a genious! It was the damn eFPS boost, I don't know why I related it to the dynDOLOD. I think it was because I installed the lods before trying only open cities. Thank you. my head was burned. 

Closed thread. Problem = eFPS

[battosai295]

keep getting Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 7686

DynDOLOD_SSE_log.txt

[sheson]

1 hour ago, battosai295 said:

keep getting Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 7686

DynDOLOD_SSE_log.txt 1.51 MB · 2 downloads

Read the first post of this DynDOLOD 3 Alpha thread which debug log and bugreport.txt (if it exists) to also upload when making posts.

Use the "Click on this link for additional explanations and help for this message" https://dyndolod.info/Messages/Exceptions#Assertion-failure as explained on the first post.

[Mousetick]

Alpha 111 with Resources A30

• Got the following error:

<Error: File not saved [...]\DynDOLOD_Output\Meshes\DynDOLOD\NoHavok\slighthousefireoff_nohavok.nif: Range check error>

I suspect it's linked to the new feature added in Alpha 107 "create on-demand no havok models for dynamic LOD". I looked at the log of the previous generation I made with Alpha 108, and it contains the same failure, which I hadn't noticed at the time. There are successfully generated meshes in \DynDOLOD\NoHavok, it's just this one which fails.

The failure occurs during generation of dynamic LOD for the ssLightHouseWorld02 worldspace of this mod: Nebarra.

Architecture\Solitude\Clutter\SlighthouseFireOff.nif is used by an activator (xx955BF7 ssgwaSlighthouseActivatorOFF) placed into that worldspace. The source mesh slighthousefireoff.nif is provided by this mod: Embers XD (Lite version).

Full logs here: https://drive.google.com/file/d/1WfsuvihMBi-fYfSuF4w2VsMkpjS5u2ul/view

 

• Trying to understand the source and purpose of a bunch of PlaneMarker references overwrites by DynDOLOD.esm in the SolitudeWorld worldspace.

I can see traces of them in the debug log, such as:

[00:08] [ApplyPatches] <Debug: Overwrite=skyrim.esm;0010c315>
[00:08] [ApplyPatches] <Debug: [1] Source Skyrim.esm [REFR:0010C315] (places PlaneMarker [STAT:00000017] in GRUP Cell Temporary Children of SolitudeOrigin [CELL:00037EE9] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -16,25))>
[00:08] [CopyMainRecordToFile] <Debug: 0 Skyrim.esm [REFR:0010C315] (places PlaneMarker [STAT:00000017] in GRUP Cell Temporary Children of SolitudeOrigin [CELL:00037EE9] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -16,25)) --> 53 Occ_Skyrim_Tamriel.esp [REFR:0010C315] (places PlaneMarker [STAT:00000017] in GRUP Cell Temporary Children of SolitudeOrigin [CELL:00037EE9] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -16,25))>
[00:08] [CopyMainRecordToFile] <Debug: Processing DynDOLOD.esm Occ_Skyrim_Tamriel.esp [REFR:0010C315] (places PlaneMarker [STAT:00000017] in GRUP Cell Temporary Children of SolitudeOrigin [CELL:00037EE9] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -16,25))>
[00:08] [ApplyPatches] <Debug: [4] Destination DynDOLOD.esm [REFR:0010C315] (places PlaneMarker [STAT:00000017] in GRUP Cell Temporary Children of SolitudeOrigin [CELL:00037EE9] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -16,25))>

but I can't find any traces of them in [...]\DynDOLOD\Edit Scripts\DynDOLOD\Configs or Rules, when I look them up by Ref ID.

It looks like DynDOLOD is patching PlaneMarker references blindingly without any regards to any other changes? It's overwriting edits by mods such as eFPS or Legacy of the Dragonborn. Why is it doing that, is this the intended behavior and if so, what is its purpose, particularly in regards to LODs?

See previous link for full logs.

Thanks.

[sheson]

2 hours ago, Mousetick said:

Alpha 111 with Resources A30

• Got the following error:

<Error: File not saved [...]\DynDOLOD_Output\Meshes\DynDOLOD\NoHavok\slighthousefireoff_nohavok.nif: Range check error>

I suspect it's linked to the new feature added in Alpha 107 "create on-demand no havok models for dynamic LOD". I looked at the log of the previous generation I made with Alpha 108, and it contains the same failure, which I hadn't noticed at the time. There are successfully generated meshes in \DynDOLOD\NoHavok, it's just this one which fails.

The failure occurs during generation of dynamic LOD for the ssLightHouseWorld02 worldspace of this mod: Nebarra.

Architecture\Solitude\Clutter\SlighthouseFireOff.nif is used by an activator (xx955BF7 ssgwaSlighthouseActivatorOFF) placed into that worldspace. The source mesh slighthousefireoff.nif is provided by this mod: Embers XD (Lite version).

Full logs here: https://drive.google.com/file/d/1WfsuvihMBi-fYfSuF4w2VsMkpjS5u2ul/view

 

• Trying to understand the source and purpose of a bunch of PlaneMarker references overwrites by DynDOLOD.esm in the SolitudeWorld worldspace.

I can see traces of them in the debug log, such as:

[00:08] [ApplyPatches] <Debug: Overwrite=skyrim.esm;0010c315>
[00:08] [ApplyPatches] <Debug: [1] Source Skyrim.esm [REFR:0010C315] (places PlaneMarker [STAT:00000017] in GRUP Cell Temporary Children of SolitudeOrigin [CELL:00037EE9] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -16,25))>
[00:08] [CopyMainRecordToFile] <Debug: 0 Skyrim.esm [REFR:0010C315] (places PlaneMarker [STAT:00000017] in GRUP Cell Temporary Children of SolitudeOrigin [CELL:00037EE9] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -16,25)) --> 53 Occ_Skyrim_Tamriel.esp [REFR:0010C315] (places PlaneMarker [STAT:00000017] in GRUP Cell Temporary Children of SolitudeOrigin [CELL:00037EE9] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -16,25))>
[00:08] [CopyMainRecordToFile] <Debug: Processing DynDOLOD.esm Occ_Skyrim_Tamriel.esp [REFR:0010C315] (places PlaneMarker [STAT:00000017] in GRUP Cell Temporary Children of SolitudeOrigin [CELL:00037EE9] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -16,25))>
[00:08] [ApplyPatches] <Debug: [4] Destination DynDOLOD.esm [REFR:0010C315] (places PlaneMarker [STAT:00000017] in GRUP Cell Temporary Children of SolitudeOrigin [CELL:00037EE9] (in SolitudeWorld "Solitude" [WRLD:00037EDF] at -16,25))>

but I can't find any traces of them in [...]\DynDOLOD\Edit Scripts\DynDOLOD\Configs or Rules, when I look them up by Ref ID.

It looks like DynDOLOD is patching PlaneMarker references blindingly without any regards to any other changes? It's overwriting edits by mods such as eFPS or Legacy of the Dragonborn. Why is it doing that, is this the intended behavior and if so, what is its purpose, particularly in regards to LODs?

See previous link for full logs.

Thanks.

Probably another bug in the xEdit NIF writer code. Will check.
Regardless of that error, that NIF from Embers XD should be optimized in NifSkope for example (collapse link arrays, remove unused strings etc.)

The source of patches are always *.patch files. Scroll upwards until you find the the logline with the notice what patch the patches are from:
[00:07] [ApplyPatches] <Notice: Processing 67 patches from dyndolod\solitudeexterior_tamriel.patch>

DynDOLOD does not do anything "blindly, especially when doing optional things the user has to install on purpose. The Solitude Exterior esp (now patch) is an optional patch that exists since May/June 2016 before Skyrim Special Edition came out. The planes/boxes are adjusted so there are no issues when watching outside while being on the walls/roofs. No issues with the Solitude Exterior patch have been reported since then AFAIK.

[Zanderat]

Having trouble with the latest version v111.  It's been close to seven hours and DynDOLOD is still running.  Only error I am getting is [code]<Error: File not saved C:\DynDOLOD\DynDOLOD_Output\Meshes\DynDOLOD\NoHavok\mgmagicfirepillar01_nohavok.nif: Range check error>[/code] No other errors, except a bunch of large reference warnings.  Never had this happen before.  Usually takes around 2 hours.   Could be user error, I suppose.  Suggested troubleshooting areas to look at?  Thanks.

Edited January 23, 2023 by Zanderat

[sheson]

4 minutes ago, Zanderat said:

Having trouble with the latest version v111.  It's been close to seven hours and DynDOLOD is still running.  Only error I am getting is [code]<Error: File not saved C:\DynDOLOD\DynDOLOD_Output\Meshes\DynDOLOD\NoHavok\mgmagicfirepillar01_nohavok.nif: Range check error>[/code] No other errors, except a bunch of large reference warnings.  Never had this happen before.  Usually takes around 2 hours.   Could be user error, I suppose.  Suggested troubleshooting areas to look at?  Thanks.

Read the first post which log, debug log and bbugreport.txt (if it exists) to upload when making posts.

https://dyndolod.info/FAQ "Long running time or output several GB in file size"

[Zanderat]

Thanks, @sheson  I forgot to check the FAQ.  I did add a new grass mod, Veydosebrom with complex grass option.  So maybe that could account for the lengthy time.  Anyway, I will leave it running while I am at work.  If it's not done by then, I will post a more formal question with logs, etc.

[Mousetick]

8 hours ago, sheson said:

The source of patches are always *.patch files. Scroll upwards until you find the the logline with the notice what patch the patches are from:
[00:07] [ApplyPatches] <Notice: Processing 67 patches from dyndolod\solitudeexterior_tamriel.patch>

Yes I saw it and went to look for it inside the DynDOLOD package (Rules subdirectory) among the other *.patch files there, but couldn't find it, which made the patching even more mysterious and puzzling.

I got really confused when you mentioned it's optional, as there are no optional components when installing DynDOLOD. But then I realized you were talking about DynDOLOD Resources: it's the Solitude Exterior visual option, d'oh!

I used "blindly" in the sense that it appears the patch is applied to the load order indiscriminately even though it's probably designed to work on vanilla Solitude, overriding Skyrim.esm, not some other mod plugins. My Solitude is vanilla too, except for the LotD museum, so it's probably mostly fine, but I'd imagine it might mess things up with city overhauls, no?

Anyway, I've been bothered by a visual glitch for a long time that I presume is caused by occlusion plane(s) along the Solitude walls, but I'm not sure and I can't easily troubleshoot it by looking in the console, as there's nothing to click on.

Far view from inside Solitude worldspace > Closer view from inside Solitude worldspace

Close view from outside Solitude worldspace > Close view from inside Solitude worldspace

Any idea what may be causing this, do you think it looks like a PlaneMarker issue too? Any advice for troubleshooting the issue?

Thanks.

[sheson]

11 hours ago, Mousetick said:

Yes I saw it and went to look for it inside the DynDOLOD package (Rules subdirectory) among the other *.patch files there, but couldn't find it, which made the patching even more mysterious and puzzling.

I got really confused when you mentioned it's optional, as there are no optional components when installing DynDOLOD. But then I realized you were talking about DynDOLOD Resources: it's the Solitude Exterior visual option, d'oh!

I used "blindly" in the sense that it appears the patch is applied to the load order indiscriminately even though it's probably designed to work on vanilla Solitude, overriding Skyrim.esm, not some other mod plugins. My Solitude is vanilla too, except for the LotD museum, so it's probably mostly fine, but I'd imagine it might mess things up with city overhauls, no?

Anyway, I've been bothered by a visual glitch for a long time that I presume is caused by occlusion plane(s) along the Solitude walls, but I'm not sure and I can't easily troubleshoot it by looking in the console, as there's nothing to click on.

Far view from inside Solitude worldspace > Closer view from inside Solitude worldspace

Close view from outside Solitude worldspace > Close view from inside Solitude worldspace

Any idea what may be causing this, do you think it looks like a PlaneMarker issue too? Any advice for troubleshooting the issue?

Thanks.

If there were problems with anything then there would have been a report in the past 7 years.

What troubleshooting with the disappearing tree LOD have you done to check if this has something to do with DynDOLOD?

Use CK to visualize occlusion planes and boxes.

[Mousetick]

3 hours ago, sheson said:

What troubleshooting with the disappearing tree LOD have you done to check if this has something to do with DynDOLOD?

Well that's the thing: none to imply anything either way, at this point I'm just shooting in the dark.

3 hours ago, sheson said:

Use CK to visualize occlusion planes and boxes.

Ok I checked and there are no occlusion planes from any plugin touching those cells, that would obstruct the view in that direction. They're all in the west- and south-facing walls. On second thought it can't be an occlusion plane issue anyway, as if it were, there would be a void where the view is blocked? Which is not the case here, as the mountain cliffs (000DEEB7 & 000DEEB8) and the landscape are still visible.

So I'm stumped.

I have some ideas to investigate, I'll let you know if I find anything relevant. But first, I'd like to ask some clarification if you don't mind. How does rendering work in cells outside the child worldspace? Are LODs only shown? Are those cells and their references and full models never loaded, no matter if they are in the near grid (but outside the child worldspace)? What about large references, I'd assume the full model would be loaded as expected.

I'm asking because it looks to me as if the tree LODs (handled as object LODs by DynDOLOD in my case) are unloaded when the player gets closer, but the full models are not loaded in their place. On the other hand, the mountain cliff objects don't disappear because they're large references.

I'm going to check in the console if those tree and mountain cliff references in question are loaded or not...

Thanks in advance for your input.

[sheson]

3 hours ago, Mousetick said:

Well that's the thing: none to imply anything either way, at this point I'm just shooting in the dark.

Ok I checked and there are no occlusion planes from any plugin touching those cells, that would obstruct the view in that direction. They're all in the west- and south-facing walls. On second thought it can't be an occlusion plane issue anyway, as if it were, there would be a void where the view is blocked? Which is not the case here, as the mountain cliffs (000DEEB7 & 000DEEB8) and the landscape are still visible.

So I'm stumped.

I have some ideas to investigate, I'll let you know if I find anything relevant. But first, I'd like to ask some clarification if you don't mind. How does rendering work in cells outside the child worldspace? Are LODs only shown? Are those cells and their references and full models never loaded, no matter if they are in the near grid (but outside the child worldspace)? What about large references, I'd assume the full model would be loaded as expected.

I'm asking because it looks to me as if the tree LODs (handled as object LODs by DynDOLOD in my case) are unloaded when the player gets closer, but the full models are not loaded in their place. On the other hand, the mountain cliff objects don't disappear because they're large references.

I'm going to check in the console if those tree and mountain cliff references in question are loaded or not...

Thanks in advance for your input.

Either the problem only happens with DynDOLOD/Occlusion plugin enabled or not.

Occlusion planes/boxes hide things that they fully occluded. So it depends on the "size" (often the axis aligned bounding box AABB) of the model. E.g. smaller things are disabled, while large things may be not.

[Shotdie]

Hi Seson!

I´ve been having a problem recently, suddenly when I generate seasons, in winter, near Riften there is a lot of totally grey slopes, it didn´t happen before.

It seems that, somehow, dyndolod is putting the wrong mountain slope and applying the snow shader making it grey.

It´s a bug or something on my end?

Thanks in advance

 

Edited January 24, 2023 by Shotdie
typo