DynDOLOD 3.00 Alpha 182

[Mousetick]

I made another test. I edited DynDOLOD_NG_Tamriel.txt and removed all [Object] entries except those associated with 'Environs - Whiterun Watchtower.esp'. 7D3022EC was successfully disabled and re-enabled on fast-travel. Upon coming back from the fast-travel roundtrip and looking at the watchtower with its cell(s) attached, all the dynamic LOD associated with EWWDSB was correctly disabled. I don't know what happened to it while fast-travelling back and forth since DynDOLOD.log only logs one ref at a time, but I'm assuming it was disabled and re-enabled successfully like 7D3022EC.

My DynDOLOD_NG_Tamriel.txt is fairly large. There are 6237 [Objects] entries in total. EWWDSB alone has 142 entries. That's quite a few references to keep track of. Is it possible we're hitting some kind of limit, or a performance bottleneck? My PC is a potato by today's standards.

Also, is it possible that DynDOLOD.log is not telling the truth when it says "Disable XYZ" or "Enable XYZ", and internally DynDOLOD.dll actually tries to disable/enable some bogus non-existent reference for whatever reason?

Thanks.

[sheson]

3 hours ago, Mousetick said:

Disables are not logged anymore:

Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Worlds.txt
Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Tamriel.txt
Enable - Reference 7D3022EC Base 5A231849 Flags 40010C08/00000040 lod\clutter\stockade\stockadegate01_lod_0.nif
Enable - Reference 7D3022EC Base 5A231849 Flags 48010C08/00000040 lod\clutter\stockade\stockadegate01_lod_0.nif
# There should be one Disable here
Enable - Reference 7D3022EC Base 5A231849 Flags 40010C0A/00000040 lod\clutter\stockade\stockadegate01_lod_0.nif
# There should be at least one Disable here

Despite there not being a log message, is the dynamic reference disabled?

1 hour ago, Mousetick said:

I made another test. I edited DynDOLOD_NG_Tamriel.txt and removed all [Object] entries except those associated with 'Environs - Whiterun Watchtower.esp'. 7D3022EC was successfully disabled and re-enabled on fast-travel. Upon coming back from the fast-travel roundtrip and looking at the watchtower with its cell(s) attached, all the dynamic LOD associated with EWWDSB was correctly disabled. I don't know what happened to it while fast-travelling back and forth since DynDOLOD.log only logs one ref at a time, but I'm assuming it was disabled and re-enabled successfully like 7D3022EC.

My DynDOLOD_NG_Tamriel.txt is fairly large. There are 6237 [Objects] entries in total. EWWDSB alone has 142 entries. That's quite a few references to keep track of. Is it possible we're hitting some kind of limit, or a performance bottleneck? My PC is a potato by today's standards.

Also, is it possible that DynDOLOD.log is not telling the truth when it says "Disable XYZ" or "Enable XYZ", and internally DynDOLOD.dll actually tries to disable/enable some bogus non-existent reference for whatever reason?

Thanks.

Set debug=true to show log messages for all dynamic references.

Use this version https://mega.nz/file/ZBZ23LyY#mch6Mk67b0l2RwRbf4qaT9FQ3At7B2Pm61uClGCtLnw which should log the intent to disable dynamic references again. The test would be to see if there is any change with specific references not being disabled.

[Mousetick]

8 hours ago, sheson said:

Despite there not being a log message, is the dynamic reference disabled?

Not in the second instance (after fast travel). So no change from previous. But you can ignore that, because the results from the latest test version are much more interesting.

8 hours ago, sheson said:

Use this version https://mega.nz/file/ZBZ23LyY#mch6Mk67b0l2RwRbf4qaT9FQ3At7B2Pm61uClGCtLnw which should log the intent to disable dynamic references again. The test would be to see if there is any change with specific references not being disabled.

I switched to debug=true which produces much bigger logs so I'm attaching them rather than copying them inline here:

DynDOLOD TEST1.7zDynDOLOD TEST2.7zDynDOLOD TEST3.7z

• Test 1: Load clean save. Exit Whiterun meadery. Fast travel to Windhelm stables.
• Test 2: Load clean save. Exit Whiterun meadery. Run in a large circle around Whiterun. Stop in front of the meadery.
• Test 3: Use DynDOLOD_NG_Tamriel.txt edited to contain only EWWDSB entries. Load clean save. Exit Whiterun meadery. Fast travel to Windhelm stables.

My comments/observations on the logs:

• In Test 1, after landing at Windhelm stables, all the enables/disables initially succeed. Then one disable fails (7D30226D, which happens to be associated with EWWDSB). Then all the following disables fail, affecting dynamic LOD references from multiple sources, but mostly from EWWDSB. The last one in the first failure sequence (7D3022F7) is associated with a vanilla reference from Skyrim.esm (0D3F85). Then everything works again, until it doesn't. This repeats a few times. At one point the failure sequence affects both enables and disables equally, again from multiple sources, including vanilla references. For example, 7D3020C6 is the dynamic LOD of 0E94A9 and it fails to enable.
• In Test 2, everything looks good mostly. Except at one point there is a string of continuous enable failures. Some or all, I didn't check, of these references were already enabled earlier.
• In Test 3, the log is clean.
• The failures followed by successes followed by failures and so on, each happening in continuous "bursts", make me think the issue could be DynDOLOD.dll might be trying to enable/disable references when the engine is busy or in a state incompatible with manipulating references "behind its back" so to speak (e.g. Papyrus VM running).
• I had "Autosave on travel" enabled. I disabled it but it made no difference.
• I don't think another mod could be interfering. It can't be a plugin. Nothing overwrites DynDOLOD.esp. It can't be a Papyrus script, as if it were, it would fall into the "Papyrus VM running" category.
• It could very well be another SKSE plugin that's interfering. I have a boat load of them. So my next test is going to disable all of them. Although I don't think I can disable Engine Fixes. The game probably can't even start without it (too many open files).

Suggestions for DynDOLOD.log in debug mode, if possible:

• Print the cell FormID or X,Y coordinates of the current cell on each cell change to make it easier to understand the flow. Or print the cell FormID or X,Y coordinates of the cells that attach and detach. Or both  Whichever is easier / you prefer.
• Print the type of event received.
• Print the EditorID of each enabled/disabled dynamic LOD reference. This would be mostly useful for you to read the logs since you don't have my load order to look up the reference IDs in xEdit: without the EditorID you can't tell what the reference ID corresponds to.

Thanks.

Edited October 31, 2023 by Mousetick

[Jonado]

It seems like Seasonal LOD does not work correctly for objects swapped with Base Object Swapper (tested on Alpha-152, but nothing in the changelog suggests that this has been fixed). BOS will swap the base objects, so seasonal form swaps act on the swapped objects, which works perfectly fine. However, as far as I can tell, the LOD objects for these meshes do not get updated with seasons. Specifically, I am using the mods Simple Snow Improvements - Skyrim Fixes and Simple Snow Improvements - Snow Forts (and the rest too, but that doesn't matter for the report), which swap Vanilla non-snowy objects in snowy areas with snowy objects. I am also using Seasonal Landscapes - Unfrozen, so for this I have created a patch.

I am attaching both the relevant SWAP file for snow forts and the seasonal swap file for summer. As you can see, the SWAP file swaps all Imperial fort assets at Fort Snowhawk with snowy variants, whereas the SUM file swaps them back to the regular variants during summer. Here is a screenshot close-up:

Looks as you would expect. However, looking towards Fort Snowhawk from a distance, forcing the LOD meshes to load, it will look like this:

Not so nice - the fort is covered with snow. I have experienced this for a couple of other BOS swapped objects as well. What I suspect is that the swaps have been executed in the wrong order. For Seasons of Skyrim, BOS swaps are are applied first, whereas seasonal form swaps are applied afterwards. If doing it the other way round, the seasonal form swaps will start by doing nothing, because the base objects are already snow free. Then BOS will swap the object with a snowy variant, yielding the observed result.

This should be all information you need, really. If you want me to attach a log file, I want to know exactly which information from them that you actually need. If you want to try to reproduce this yourself, you have the links to the mods and the attached ini files to play with. If you want the full Unfrozen patch (but you won't need the esp for testing), it is available here: Seasonal Landscapes - Unfrozen - More Patches.

Simple Snow Improvements - Snow Forts_SWAP.ini Unfrozen - Simple Snow Improvements_SUM.ini

[sheson]

8 hours ago, Mousetick said:

Not in the second instance (after fast travel). So no change from previous. But you can ignore that, because the results from the latest test version are much more interesting.

I switched to debug=true which produces much bigger logs so I'm attaching them rather than copying them inline here:

DynDOLOD TEST1.7zDynDOLOD TEST2.7zDynDOLOD TEST3.7z

• Test 1: Load clean save. Exit Whiterun meadery. Fast travel to Windhelm stables.
• Test 2: Load clean save. Exit Whiterun meadery. Run in a large circle around Whiterun. Stop in front of the meadery.
• Test 3: Use DynDOLOD_NG_Tamriel.txt edited to contain only EWWDSB entries. Load clean save. Exit Whiterun meadery. Fast travel to Windhelm stables.

My comments/observations on the logs:

• In Test 1, after landing at Windhelm stables, all the enables/disables initially succeed. Then one disable fails (7D30226D, which happens to be associated with EWWDSB). Then all the following disables fail, affecting dynamic LOD references from multiple sources, but mostly from EWWDSB. The last one in the first failure sequence (7D3022F7) is associated with a vanilla reference from Skyrim.esm (0D3F85). Then everything works again, until it doesn't. This repeats a few times. At one point the failure sequence affects both enables and disables equally, again from multiple sources, including vanilla references. For example, 7D3020C6 is the dynamic LOD of 0E94A9 and it fails to enable.
• In Test 2, everything looks good mostly. Except at one point there is a string of continuous enable failures. Some or all, I didn't check, of these references were already enabled earlier.
• In Test 3, the log is clean.
• The failures followed by successes followed by failures and so on, each happening in continuous "bursts", make me think the issue could be DynDOLOD.dll might be trying to enable/disable references when the engine is busy or in a state incompatible with manipulating references "behind its back" so to speak (e.g. Papyrus VM running).
• I had "Autosave on travel" enabled. I disabled it but it made no difference.
• I don't think another mod could be interfering. It can't be a plugin. Nothing overwrites DynDOLOD.esp. It can't be a Papyrus script, as if it were, it would fall into the "Papyrus VM running" category.
• It could very well be another SKSE plugin that's interfering. I have a boat load of them. So my next test is going to disable all of them. Although I don't think I can disable Engine Fixes. The game probably can't even start without it (too many open files).

Suggestions for DynDOLOD.log in debug mode, if possible:

• Print the cell FormID or X,Y coordinates of the current cell on each cell change to make it easier to understand the flow. Or print the cell FormID or X,Y coordinates of the cells that attach and detach. Or both  Whichever is easier / you prefer.
• Print the type of event received.
• Print the EditorID of each enabled/disabled dynamic LOD reference. This would be mostly useful for you to read the logs since you don't have my load order to look up the reference IDs in xEdit: without the EditorID you can't tell what the reference ID corresponds to.

Thanks.

In test 1, what does "Then everything works again" mean? Do the affected references disable/enable properly again?
In test 2, do the affected reference disable/enable properly?

In case they are not, does using console command resetreference has any effect on them?

Add debuglevel=1 to the DynDOLOD_NG_Worlds.txt if you want log messages about cells etc.

Test with this version https://mega.nz/file/gQ50RbCC#jpW0MPs6riX0JKUigX9vazVVIi93nLXWgfKUJS2rPWg
There won't be any failed messages in any case regardless of what is happening.

[sheson]

10 hours ago, Jonado said:

It seems like Seasonal LOD does not work correctly for objects swapped with Base Object Swapper (tested on Alpha-152, but nothing in the changelog suggests that this has been fixed). BOS will swap the base objects, so seasonal form swaps act on the swapped objects, which works perfectly fine. However, as far as I can tell, the LOD objects for these meshes do not get updated with seasons. Specifically, I am using the mods Simple Snow Improvements - Skyrim Fixes and Simple Snow Improvements - Snow Forts (and the rest too, but that doesn't matter for the report), which swap Vanilla non-snowy objects in snowy areas with snowy objects. I am also using Seasonal Landscapes - Unfrozen, so for this I have created a patch.

I am attaching both the relevant SWAP file for snow forts and the seasonal swap file for summer. As you can see, the SWAP file swaps all Imperial fort assets at Fort Snowhawk with snowy variants, whereas the SUM file swaps them back to the regular variants during summer. Here is a screenshot close-up:

Looks as you would expect. However, looking towards Fort Snowhawk from a distance, forcing the LOD meshes to load, it will look like this:

Not so nice - the fort is covered with snow. I have experienced this for a couple of other BOS swapped objects as well. What I suspect is that the swaps have been executed in the wrong order. For Seasons of Skyrim, BOS swaps are are applied first, whereas seasonal form swaps are applied afterwards. If doing it the other way round, the seasonal form swaps will start by doing nothing, because the base objects are already snow free. Then BOS will swap the object with a snowy variant, yielding the observed result.

This should be all information you need, really. If you want me to attach a log file, I want to know exactly which information from them that you actually need. If you want to try to reproduce this yourself, you have the links to the mods and the attached ini files to play with. If you want the full Unfrozen patch (but you won't need the esp for testing), it is available here: Seasonal Landscapes - Unfrozen - More Patches.

Simple Snow Improvements - Snow Forts_SWAP.ini 2.84 kB · 0 downloads Unfrozen - Simple Snow Improvements_SUM.ini 12.46 kB · 0 downloads

As explained on the first post and https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-the-Latest-Versions, always use the latest version.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire DynDOLOD log and debug to upload.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make useful screenshots with more informative console for at least one affected full model.

[Mousetick]

1 hour ago, sheson said:

In test 1, what does "Then everything works again" mean? Do the affected references disable/enable properly again?

Sorry for being vague. In TEST1.log, starting at line # 1004, disables are all reported as failed, until line # 1155, when enables and disables of other references are not reported as failed anymore. At line # 1668, disables are all reported as failed again. But it looks like those are retries of the same previously failed ones starting at line # 1004.

The affected references that fail to disable never work properly again.

Ever since we started this troubleshooting, and in all my tests, I always check the state of 7D3022EC (which is one of the references that fails to disable, but not the only one) in the console at each step. It has never been disabled after fast travelling, as shown in the console, with any test version of DynDOLOD.dll so far. Except in the cases where I "hacked" DynDOLOD_NG_Tamriel.txt to change the list of [Objects], as I reported before.

If 7D3022EC is successfully disabled after fast travel to Windhelm in one future test, you can be sure this will be the first thing I'll tell you.

I have a small human brain so I can only keep track of 7D3022EC in the console. There are dozens of dynamic LOD references that are enabled and disabled after fast travel. I look at DynDOLOD.log to get an idea of what happens to the other references.

2 hours ago, sheson said:

In test 2, do the affected reference disable/enable properly?

Yes.

2 hours ago, sheson said:

Add debuglevel=1 to the DynDOLOD_NG_Worlds.txt if you want log messages about cells etc.

Test with this version https://mega.nz/file/gQ50RbCC#jpW0MPs6riX0JKUigX9vazVVIi93nLXWgfKUJS2rPWg
There won't be any failed messages in any case regardless of what is happening.

Ok, thanks. Let me give it a try, I'll keep you posted. I'll also try resetreference if needed, as you suggested.

[Mousetick]

3 hours ago, sheson said:

Test with this version https://mega.nz/file/gQ50RbCC#jpW0MPs6riX0JKUigX9vazVVIi93nLXWgfKUJS2rPWg

SUCCESS!

Whatever was changed in this version, has fixed it.

I fast travelled back and forth between Whiterun and Windhelm a couple times, approached the watchtower by foot in between fast travels, and fast travelled from Whiterun to Markarth. 7D3022EC was disabled at the fast travel destination, when coming back to Whiterun, it was enabled again, it disabled properly when approaching the watchtower and re-enabled when moving away. The other dynamic LOD references that were failing before along with 7D3022EC all appeared to work properly (just visually looking at the EWWDSB objects at the watchtower, I can tell the dynamic LODs are properly fading when the watchtower cells attach). I didn't check them exhaustively but there is no reason to believe they all wouldn't be fixed as well.

Log for info: DynDOLOD.7z

Thanks. Glad you were able to nail it.

[Jonado]

12 hours ago, sheson said:

As explained on the first post and https://dyndolod.info/Official-DynDOLOD-Support-Forum#Use-the-Latest-Versions, always use the latest version.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which entire DynDOLOD log and debug to upload.

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make useful screenshots with more informative console for at least one affected full model.

I did read those, but I still don't understand why you want a full debug log with almost entirely unrelated information, when I have a quite good idea of what could be causing this. I can confirm myself that the object IDs of the affected models are all listed in the SWAP file I attached, no need to use More Informative Console for that. As an example, the centre tower has the model ImpExtTower01 (this is clearly affected, and on the list).

In any case, I would have to regenerated all LOD to be able to produce meaningful log files, since last time I used DynDOLOD, I had to repeat the process for a smaller, unrelated worldspace. I always find it a hassle to generate LOD, so this is something I would rather avoid doing too frequently (also the reason why I would rather not update DynDOLOD just to get three versions ahead). If it is of any use for you, the limited debug file I have gives the following entries when searching for ImpExtTower01, but honestly, I think the interesting things would happen further ahead:

[00:35] [ProcessSeasonFile] <Debug: Season SUM, swapping record Simple Snow Improvements - Snow Forts.esp ImpExtTower01snow [STAT:FE2BE804] to Skyrim.esm ImpExtTower01 [STAT:0003F1F9]>

(loaded twice)
  
...
  
[01:19] [BuildBaseRecords] <Debug: Looking for impexttower01 for Skyrim.esm ImpExtTower01 [STAT:0003F1F9]>

...
  
[01:19] [AddModel] <Debug: Meshes\dungeons\imperial\exterior\impexttower01.nif L1_Windows Shader Flags 1: Specular | Environment_Mapping | Recieve_Shadows | Cast_Shadows | Own_Emit | Remappable_Textures | External_Emittance | ZBuffer_Test Skyrim.esm ImpExtTower01 [STAT:0003F1F9]>
[01:19] [AddModel] <Debug: Meshes\dungeons\imperial\exterior\impexttower01.nif L1_Windows Shader Flags 2: ZBuffer_Write | Vertex_Colors | EnvMap_Light_Fade Skyrim.esm ImpExtTower01 [STAT:0003F1F9]>

(a bunch of other similar entries)
  
...
  
[02:45] [BuildBaseRecords] <Debug: Looking for impexttower01 for Simple Snow Improvements - Snow Forts.esp ImpExtTower01snow [STAT:FE2BE804]>
  
...
  
[03:07] [AddModel] <Debug: Meshes\lod\imperial\impexttower01glow_lod_1.nif L1_Windows Shader Flags 1: Specular | Recieve_Shadows | Cast_Shadows | Own_Emit | Remappable_Textures | Decal | Dynamic_Decal | External_Emittance | ZBuffer_Test Skyrim.esm ImpExtTower01 [STAT:0003F1F9]>
[03:07] [AddModel] <Debug: Meshes\lod\imperial\impexttower01glow_lod_1.nif L1_Windows Shader Flags 2: ZBuffer_Write | No_Fade | EnvMap_Light_Fade Skyrim.esm ImpExtTower01 [STAT:0003F1F9]>
  
...
  
[03:21] [LoadSwaps] <Debug: Location record FortSnowhawkLocation "Fort Snowhawk" [LCTN:00019184]: Swapping Skyrim.esm ImpExtTower01 [STAT:0003F1F9] to ImpExtTower01snow Simple Snow Improvements - Snow Forts.esp ImpExtTower01snow [STAT:FE2BE804]>
  

So it may take a while until I am able to produce all the logs you want, but the report should be clear enough anyway for you to be able to investigate this (and even reproduce it if you have time). If this would have been fixed already, I would expect it to be listed in the changelog, or at least that you would be aware of the issue.

[ButchDiavolo]

Hi Sheson,

I am having an odd situation with TexGen for which I can't find any information forums. I downloaded a 3d LOD mod for Nature of The Wild Lands yesterday. I have been trying to run TexGen and DynDOLOD. For the most part it works fine, except for 2 billboards. TexGen does not give errors after the run, so it just gives the option to close. When I run DynDOLOD with the TexGen output activated, I get a "Texture not Found" report for 2 nifs. The DynDOLOD reports have no information about it, besides that the textures are missing. Checking the TexGen_SSE_Debug_log.txt, I eventually found two notices concerning the missing textures:

[00:10] [TwbRender.SetRenderMax] <Notice: Skipping billboard C:\Games\Tools\DynDOLOD\TexGen_Output\Textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\alnus_forest_shrub02_91ed5863_trunk_1. Not enough opaque pixels 0.01 < 0.01>
[00:10] [TwbRender.SetRenderMax] <Notice: Skipping billboard C:\Games\Tools\DynDOLOD\TexGen_Output\Textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\alnus_forest_shrub06_b0fc1baa_trunk_1. Not enough opaque pixels 0.00 < 0.01>

I have never seen that message before and have no idea what that means/ causes it. Apparently I am (so far) the only one with this error and the mod author has been very helpful in trying to solve it, but he can't replicate it. So I am hoping you can give me some insight in what could cause it and how I can correct it. I have attached only the zipped TexGen logs, since DynDOLOD has no further mention about it beside the textures missing.

Thanks in advance for you help!

 

TexGen Logs.7z

Edited November 2, 2023 by ButchDiavolo

[sheson]

47 minutes ago, ButchDiavolo said:

Hi Sheson,

I am having an odd situation with TexGen for which I can't find any information forums. I downloaded a 3d LOD mod for Nature of The Wild Lands yesterday. I have been trying to run TexGen and DynDOLOD. For the most part it works fine, except for 2 billboards. TexGen does not give errors after the run, so it just gives the option to close. When I run DynDOLOD with the TexGen output activated, I get a "Texture not Found" report for 2 nifs. The DynDOLOD reports have no information about it, besides that the textures are missing. Checking the TexGen_SSE_Debug_log.txt, I eventually found two notices concerning the missing textures:

[00:10] [TwbRender.SetRenderMax] <Notice: Skipping billboard C:\Games\Tools\DynDOLOD\TexGen_Output\Textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\alnus_forest_shrub02_91ed5863_trunk_1. Not enough opaque pixels 0.01 < 0.01>
[00:10] [TwbRender.SetRenderMax] <Notice: Skipping billboard C:\Games\Tools\DynDOLOD\TexGen_Output\Textures\dyndolod\lod\trees\nature of the wild lands 2.0 - deleted 3d lods\alnus_forest_shrub06_b0fc1baa_trunk_1. Not enough opaque pixels 0.00 < 0.01>

I have never seen that message before and have no idea what that means/ causes it. Apparently I am (so far) the only one with this error and the mod author has been very helpful in trying to solve it, but he can't replicate it. So I am hoping you can give me some insight in what could cause it and how I can correct it. I have attached only the zipped TexGen logs, since DynDOLOD has no further mention about it beside the textures missing.

Thanks in advance for you help!

 

TexGen Logs.7z 661.29 kB · 0 downloads

It means the ratio of transparent to opaque pixels is higher than the BillboardDiscardRatio set in TexGen_SSE.INI.

The billboard is mostly just transparent.

It could be a result of the full textures. You should check the preview.

In my quick test with the current version of the mods and default settings (with units per pixel 11 or 5.5) there is no such message or problem.

[ButchDiavolo]

3 hours ago, sheson said:

It means the ratio of transparent to opaque pixels is higher than the BillboardDiscardRatio set in TexGen_SSE.INI.

The billboard is mostly just transparent.

It could be a result of the full textures. You should check the preview.

In my quick test with the current version of the mods and default settings (with units per pixel 11 or 5.5) there is no such message or problem.

Thank you for your reply. Since you also didn't have this issue, I figured something in my set up was wrong. So I decided to reinstall the mods involved and DynDOLOD. I ran TexGen again and had no warnings!

Then I remembered that I had forgotten to change the ini's to what STEP advises and re-ran TexGen, which promptly brought the errors back... Figuring the issue concerns trees, opaque pixels/ transparency (=alpha right?) and STEP advising to set "TreeMSAlphaThreshold=144", I changed that back to the original 96 and it works again. Still no idea why just those two billboards were affected though. I then ran DynDOLOD and again no errors this time.

Thank you for pointing me in the right direction!

[sheson]

2 hours ago, ButchDiavolo said:

Thank you for your reply. Since you also didn't have this issue, I figured something in my set up was wrong. So I decided to reinstall the mods involved and DynDOLOD. I ran TexGen again and had no warnings!

Then I remembered that I had forgotten to change the ini's to what STEP advises and re-ran TexGen, which promptly brought the errors back... Figuring the issue concerns trees, opaque pixels/ transparency (=alpha right?) and STEP advising to set "TreeMSAlphaThreshold=144", I changed that back to the original 96 and it works again. Still no idea why just those two billboards were affected though. I then ran DynDOLOD and again no errors this time.

Thank you for pointing me in the right direction!

As I suggested, check the preview. Comparing them might show a difference, though it is possible the TreeMSAlphaThreshold setting is only really visible in the generated billboard. The billboards most likely have a high transparent to opaque pixel ratio and by changing the threshold it will be over the BillboardDiscardRatio. You could lower it to have the billboards still be generated and then check the result.

The settings of modding guides typically apply to the specific mods and setup of the guide. It would be a good idea to learn what settings do before changing them for custom load orders.

[SkyKatarsis]

В 26.10.2023 в 11:22, Шесон сказал:

Завершите или не устанавливайте мусорное ПО от AMD, как описано на https://dyndolod.info/FAQ#Long-running-time-or-output-several-GB-in-file-size . странице
Известно, что мусорное ПО, установленное вместе с графическими драйверами, увеличивает время работы. Выполняйте чистую установку только последней рекомендованной или официальной версии драйвера. Не устанавливайте поставку ненужного ПО вместе с драйверами и не прекращайте ее работу перед запуском инструментов.

Рассмотрите возможность установки .NET Runtime 7, как описано на   https://dyndolod.info/Downloads#Additional-Requirements . странице

Thanks for the answer.  But I don’t understand why lodes were generated before, but now they are not.  Runtime 7 is installed.  I'm not a native speaker and didn't quite understand about junk software.  Please clarify.  I killed a few days, but I couldn’t make lods like before.  Once, by some miracle, the logs were still generated and quickly, but I forgot about the ini I needed in Markarth, so that the suburb could be seen from the patio of my house.  From that moment on, several days of unsuccessful attempts and wasted time. The generation lods simply freezes and does not move for a large number of hours.

[sheson]

11 hours ago, SkyKatarsis said:

Thanks for the answer.  But I don’t understand why lodes were generated before, but now they are not.  Runtime 7 is installed.  I'm not a native speaker and didn't quite understand about junk software.  Please clarify.  I killed a few days, but I couldn’t make lods like before.  Once, by some miracle, the logs were still generated and quickly, but I forgot about the ini I needed in Markarth, so that the suburb could be seen from the patio of my house.  From that moment on, several days of unsuccessful attempts and wasted time. The generation lods simply freezes and does not move for a large number of hours.

https://dyndolod.info/FAQ#Long-running-time-or-output-several-GB-in-file-sizehttps://dyndolod.info/FAQ#Long-running-time-or-output-several-GB-in-file-size
Crapware installed with graphics drivers is known to prolong running times. Do a clean install of the latest recommended or official driver only. Do not install crapware shipping with the drivers or terminate it before running the tools.

Make a driver only installation or terminate all programs that were installed with the graphics driver. https://imgur.com/14VpsWk