DynDOLOD 3.00 Alpha 182

[godescalcus]

14 minutes ago, z929669 said:

I also use Sniff for this work. Note that you don't need to alter the root node: BsLeafAnimNode is fine, for example.

 

I think we agree that Sniff is a jewel, and zilav is a scholar  I'm feeling like starting from scratch and trying out your workflow, because even with Sniff, processing crowns and trunks separately as I did on my "learn as you go" process "might" lead to unexpected results...

[zer0haiku2077]

https://imgur.com/a/CFRsXq8 this is from my test modlist, not the problem right now but im on the way to another modlist, i think this is because i didn't know how to tweak the snowdrift settings in dyndolod settings but i could be wrong, because in my old modlist(2022), i can click the snowdrift to remove it since the place i only have that problem is in immersive fort dawnguard, i have since remove IFD temporarily since i don't know how to tweak the snowdrift. and secondly, how do i tweak the LODGenThreadSplit? i want generating to be fast but i don't want my pc freezing when generating dyndolod, i have it now at 3 and its not freezing but not really fast either, i have a big load order so i wanna keep testing first before i start playing. my specs are r5 3600, 3070 16gb and playing at 1080p. thanks

[godescalcus]

2 hours ago, z929669 said:

1. Manually optimize crowns larger than ~500 Kb using a 3D app
   1. # triangles is a better cutoff reference (≥ 15,000 tris), but file size seems to be a good-enough indicator.

This is my attempt at reducing file size (and polygon count) in Blender. Brings it down from 22000 triangles to 8000, and I reckon it shows the difference. I didn't remove triangles, instead applied the decimate modifier twice, first pass unsubdividing triangles, second pass uniting triangles with a common side and angle under 15º. Probably the second step is the destructive one? Anyways, would you say the edited crown would be acceptable for a lod? What would you consider to be the optimal compromise between limiting pop-ins, and performance?

File size is still over 500Mb but since the polygon count was so drastically reduced by almost 2/3, I'm willing to suggest it's a good compromise - but I can also use this as a rule for now, check in game, and adjust...

[z929669]

4 minutes ago, godescalcus said:

This is my attempt at reducing file size (and polygon count) in Blender. Brings it down from 22000 triangles to 8000, and I reckon it shows the difference. I didn't remove triangles, instead applied the decimate modifier twice, first pass unsubdividing triangles, second pass uniting triangles with a common side and angle under 15º. Probably the second step is the destructive one? Anyways, would you say the edited crown would be acceptable for a lod? What would you consider to be the optimal compromise between limiting pop-ins, and performance?

File size is still over 500Mb but since the polygon count was so drastically reduced by almost 2/3, I'm willing to suggest it's a good compromise - but I can also use this as a rule for now, check in game, and adjust...

That should be fine for LOD. Just check in game to verify. Both are more/less destructive, but that is the point.

You can also look at the UV map and delete tris not used commonly or if associated with inner branches. You can also delete the polys that may not show much like those lower ones near the trunk or anything underground, etc.

[sheson]

2 hours ago, z929669 said:

Question: I always convert BSLODTriShape to BsTrishape in the full model before making hybrids. Is this advised or even necessary?

The tools will always use all triangles of a BSLODTriShape. Converting them does the same and makes it clear for whoever might look at the NIF.

[sheson]

2 hours ago, zer0haiku2077 said:

https://imgur.com/a/CFRsXq8 this is from my test modlist, not the problem right now but im on the way to another modlist, i think this is because i didn't know how to tweak the snowdrift settings in dyndolod settings but i could be wrong, because in my old modlist(2022), i can click the snowdrift to remove it since the place i only have that problem is in immersive fort dawnguard, i have since remove IFD temporarily since i don't know how to tweak the snowdrift. and secondly, how do i tweak the LODGenThreadSplit? i want generating to be fast but i don't want my pc freezing when generating dyndolod, i have it now at 3 and its not freezing but not really fast either, i have a big load order so i wanna keep testing first before i start playing. my specs are r5 3600, 3070 16gb and playing at 1080p. thanks

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

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots how to make meaningful screenshots.

Read the explanations in the INI above the LODGenThreadSplit setting. You will have to experiment with settings yourself to see what works best in your case while keeping an eye on max memory consumption of LODGen to make sure everything currently running doesn't consume all available physical memory.

[godescalcus]

I'm failing to get DynDOLOD_CRC32Gen.pas to work.

I copied it to xEdit\Edit scripts, open the mod in xEdit and run the script on its tree base records. Set the origin and output folders as such:

const
  source = 'H:\SteamLibrary\steamapps\common\Skyrim Special Edition\Data\meshes\';
  output = 'C:\modding_tools\DynDOLOD\docs\trees.ultra\tools\hybrids\input\ulvenwald\';

(on a previous run I set the source to 'C:\modding_tools\DynDOLOD\docs\trees.ultra\tools\hybrids\input\ulvenwald_origin\' - which is a folder where I copied the entire set of tree meshes contained in the mod).

Clearly this isn't how it's used, but I'm guessing since I can't find instructions anywhere. Searched this forum, googled, looked into documentation for the older DynDOLOD, seems like if there were instructions, they're gone now? Last night I spent 4 hours using 7zip to get the CRC32, then manually add it to hundreds of filenames, it would be great to avoid having to do that again...

Also found re-uv.bat and merge.bat that could help make it quicker to process the original mesh into a static mesh, before further processing and splitting - but also can't find instructions on how to use them. Are these in older DynDOLOD files that have not been included in the most recent versions? Any way to reach?

[z929669]

1 hour ago, godescalcus said:

I'm failing to get DynDOLOD_CRC32Gen.pas to work.

I copied it to xEdit\Edit scripts, open the mod in xEdit and run the script on its tree base records. Set the origin and output folders as such:

const
  source = 'H:\SteamLibrary\steamapps\common\Skyrim Special Edition\Data\meshes\';
  output = 'C:\modding_tools\DynDOLOD\docs\trees.ultra\tools\hybrids\input\ulvenwald\';

(on a previous run I set the source to 'C:\modding_tools\DynDOLOD\docs\trees.ultra\tools\hybrids\input\ulvenwald_origin\' - which is a folder where I copied the entire set of tree meshes contained in the mod).

Clearly this isn't how it's used, but I'm guessing since I can't find instructions anywhere. Searched this forum, googled, looked into documentation for the older DynDOLOD, seems like if there were instructions, they're gone now? Last night I spent 4 hours using 7zip to get the CRC32, then manually add it to hundreds of filenames, it would be great to avoid having to do that again...

Also found re-uv.bat and merge.bat that could help make it quicker to process the original mesh into a static mesh, before further processing and splitting - but also can't find instructions on how to use them. Are these in older DynDOLOD files that have not been included in the most recent versions? Any way to reach?

This is how I set it up. I just use the folder structure expected by the script and run xEdit via MO. The output will be a meshes folder in the xEdit Output adjacent to DynDOLOD-Source.

Right click the Tree node in xEdit for each relevant plugin, and the renamed tree NIF will all be generated. If your tree mod replaces vanilla trees and those trees don't have references in the mod plugin, you need to be certain full tree meshes from your mod exist under DynDOLOD-Source folder "as-is" but renamed like "TreeFile01_passthru_lod.nif" and you will need to also run this on the vanilla Tree nodes for each vanilla plugin (Skyrim, Hearthfires, Dawnguard, Dragonborn, TreeModPlugin ... all of them to be sure).

When finished, all trees with LOD from your mod will have the CRC32 under the meshes output folder. These are the only ones that need to be made into hybrids, and the file names are accurate. Be certain all of the base models are 'final' before you do it or the CRC will be wrong later after edit of the base NIFs.

[DarthVitrial]

Got an Assertion Failure message in Alpha-127.

Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505) while processing Glenmoril.esm [REFR:1C00DE69] (places NorTempleExterior01Base [STAT:00026FDE] in GRUP Cell Temporary Children of GHKyneTemple02 [CELL:1C00DE64] (in zGHWitchForestWorld "Vahdin Holt" [WRLD:1C00DE4D] at 0,2))
Error: Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505) while processing Glenmoril.esm [REFR:1C00DE69] (places NorTempleExterior01Base [STAT:00026FDE] in GRUP Cell Temporary Children of GHKyneTemple02 [CELL:1C00DE64] (in zGHWitchForestWorld "Vahdin Holt" [WRLD:1C00DE4D] at 0,2))
User says "Exit DynDOLOD"

 

log and bugreport attached.

Debug log (it's big): https://mega.nz/file/F1NChSxb#HZkBC1X-UVLWwNiNBgEgMhH5aG8wAZ0CbKi8ezQqesA

 

 

I also found the following in my Event Log:

Description: A .NET application failed.
Application: LODGenx64Win.exe
Path: E:\Dyndolod\Edit Scripts\LODGenx64Win.exe
Message: You must install or update .NET to run this application.

App: E:\Dyndolod\Edit Scripts\LODGenx64Win.exe
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '6.0.0' (x64)
.NET location: C:\Program Files\dotnet\

The following frameworks were found:
  7.0.4 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

If this is the same issue, does that mean LodGen doesn't work with .Net 7? I always thought .Net 6 onward was backward compatible (actually doesn't installing 7 remove 6?) but if not I'll roll back to .net 6 and try again. (I'm certain I've used DynDoLod/LodGen with .Net 7 before with no issues though, as recently as two months ago, which is odd. Maybe the two errors are unrelated?)

bugreport.txt DynDOLOD_SSE_log.txt

Edited May 11, 2023 by DarthVitrial

[sheson]

7 hours ago, godescalcus said:

I'm failing to get DynDOLOD_CRC32Gen.pas to work.

I copied it to xEdit\Edit scripts, open the mod in xEdit and run the script on its tree base records. Set the origin and output folders as such:

const
  source = 'H:\SteamLibrary\steamapps\common\Skyrim Special Edition\Data\meshes\';
  output = 'C:\modding_tools\DynDOLOD\docs\trees.ultra\tools\hybrids\input\ulvenwald\';

(on a previous run I set the source to 'C:\modding_tools\DynDOLOD\docs\trees.ultra\tools\hybrids\input\ulvenwald_origin\' - which is a folder where I copied the entire set of tree meshes contained in the mod).

Clearly this isn't how it's used, but I'm guessing since I can't find instructions anywhere. Searched this forum, googled, looked into documentation for the older DynDOLOD, seems like if there were instructions, they're gone now? Last night I spent 4 hours using 7zip to get the CRC32, then manually add it to hundreds of filenames, it would be great to avoid having to do that again...

Also found re-uv.bat and merge.bat that could help make it quicker to process the original mesh into a static mesh, before further processing and splitting - but also can't find instructions on how to use them. Are these in older DynDOLOD files that have not been included in the most recent versions? Any way to reach?

You can find instructions for DynDOLOD_CRC32Gen.pas in the DynDOLOD 2 download archive ..\DynDOLOD\Docs\trees.ultra\tools\DynDOLOD_CreateStaticTree.html

To make creating CRC32 filenames easier, copy DynDOLOD_CRC32Gen.pas to xEdit\Edit Scripts and use it to generate the LOD filename for a full model tree. It expects a *_passthru_lod.nif in ..\SteamLibrary\SteamApps\common\skyrim\Data\DynDOLOD-Source\*_passthru_lod.nif and will copy it to -o:OUTPUT Path + \meshes\DynDOLOD\lod\trees\*_XXXXXXXXpassthru_lod.nif.

Start xEdit.exe, unfold TREEs, mark trees you want to work on and then apply script DynDOLOD_CRC32Gen.pas. It will either log source file not found for a desitnation or print a line when it copies from source -> destination. If copying files is not required just copy the CRC32 filename from the log to rename a file manually.

I suggest to use 3D tools / Simplygon to re-uv for stitched object LOD textures created by TexGen. 

As usual, with xEdit/xLODGen/DynDOLOD or any other tool, always set a dedicated outputput folder outside Steam, game, mod manager folders etc. Otherwise there will be issues with existing files being replaced in their mod folder or potentially file access issues.

[sheson]

2 hours ago, DarthVitrial said:

Got an Assertion Failure message in Alpha-127.

Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505) while processing Glenmoril.esm [REFR:1C00DE69] (places NorTempleExterior01Base [STAT:00026FDE] in GRUP Cell Temporary Children of GHKyneTemple02 [CELL:1C00DE64] (in zGHWitchForestWorld "Vahdin Holt" [WRLD:1C00DE4D] at 0,2))
Error: Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505) while processing Glenmoril.esm [REFR:1C00DE69] (places NorTempleExterior01Base [STAT:00026FDE] in GRUP Cell Temporary Children of GHKyneTemple02 [CELL:1C00DE64] (in zGHWitchForestWorld "Vahdin Holt" [WRLD:1C00DE4D] at 0,2))
User says "Exit DynDOLOD"

 

log and bugreport attached.

Debug log (it's big): https://mega.nz/file/F1NChSxb#HZkBC1X-UVLWwNiNBgEgMhH5aG8wAZ0CbKi8ezQqesA

 

 

I also found the following in my Event Log:

Description: A .NET application failed.
Application: LODGenx64Win.exe
Path: E:\Dyndolod\Edit Scripts\LODGenx64Win.exe
Message: You must install or update .NET to run this application.

App: E:\Dyndolod\Edit Scripts\LODGenx64Win.exe
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '6.0.0' (x64)
.NET location: C:\Program Files\dotnet\

The following frameworks were found:
  7.0.4 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

If this is the same issue, does that mean LodGen doesn't work with .Net 7? I always thought .Net 6 onward was backward compatible (actually doesn't installing 7 remove 6?) but if not I'll roll back to .net 6 and try again. (I'm certain I've used DynDoLod/LodGen with .Net 7 before with no issues though, as recently as two months ago, which is odd. Maybe the two errors are unrelated?)

bugreport.txt 302.72 kB · 0 downloads DynDOLOD_SSE_log.txt 383.65 kB · 0 downloads

I take it the assertion is not repeatable?

The x64 version of .NET Runtime 7 works for me (it is also included in the .NET Desktop Runtime)

[DarthVitrial]

9 hours ago, sheson said:

I take it the assertion is not repeatable?

The x64 version of .NET Runtime 7 works for me (it is also included in the .NET Desktop Runtime)

It's repeatable. Different cell, same error.

Same error in the event log too. I have the x64 version of the .Net Runtime 7 installed (with the Desktop Runtime, yes).

Bugreport and log attached.

Debug log: https://mega.nz/file/g9chHZRR#z3flhjM-b6rKAQsX8eRsrddQgbPMEEkQi7273i-D2pQ

bugreport.txt DynDOLOD_SSE_log.txt

[sheson]

31 minutes ago, DarthVitrial said:

It's repeatable. Different cell, same error.

Same error in the event log too. I have the x64 version of the .Net Runtime 7 installed (with the Desktop Runtime, yes).

Bugreport and log attached.

Debug log: https://mega.nz/file/g9chHZRR#z3flhjM-b6rKAQsX8eRsrddQgbPMEEkQi7273i-D2pQ

bugreport.txt 307.19 kB · 0 downloads DynDOLOD_SSE_log.txt 396.37 kB · 0 downloads

If it is different records, worldspaces etc. it is random.

Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 16418)
and
Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505)
are different errors with different call stacks.

Check what happens with this test version https://mega.nz/file/kZwkBLLb#t83YYfTIHUW4u67ngZwQj_eSLblhS5YWiwB-O1lz11M

Reinstall/Repair the .NET installation. If that does not help ask MS support.

[DarthVitrial]

52 minutes ago, sheson said:

If it is different records, worldspaces etc. it is random.

Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 16418)
and
Assertion failure (C:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 17505)
are different errors with different call stacks.

Check what happens with this test version https://mega.nz/file/kZwkBLLb#t83YYfTIHUW4u67ngZwQj_eSLblhS5YWiwB-O1lz11M

Reinstall/Repair the .NET installation. If that does not help ask MS support.

That build seems to have fixed it.

The .net error still showed up in the event log but LodGen finished with no issues, no assertions or error messages in the log.

Mind if I ask what you changed in that test build?

DynDOLOD_SSE_log.txt

Edited May 11, 2023 by DarthVitrial

[sheson]

1 hour ago, DarthVitrial said:

That build seems to have fixed it.

The .net error still showed up in the event log but LodGen finished with no issues, no assertions or error messages in the log.

Mind if I ask what you changed in that test build?

DynDOLOD_SSE_log.txt 1.69 MB · 0 downloads

Adding critical sections to the 2 procedures in wbImplementation where the race conditions occurred.

https://dyndolod.info/Help/LODGen
LODGen.exe/LODGenx64.exe require .NET Framework 4.8 to be installed, which is typically included in Windows 10/11. LODGenWin.exe/LODGenx64Win.exe require .NET Runtime 6 to be installed. The higher .NET Runtime 6 version is preferred. A check at startup determines if it can be used or else automatically falls back to the .Net Framework 4.8 version. To know which version is being used, check the log for the line:
External: C:\Modding\DynDOLOD\Edit Scripts\[LODGen|LODGenx64|LODGenWin|LODGenx64Win].exe

So it falls back to the 4.8 Framework version for you.

In my case the LODGen log reports .NET 6.0.16 being used despite only having .NET 7.0.5 x64 installed