DynDOLOD 3.00 Alpha 198

[sheson]

6 hours ago, z929669 said:

I ran without using any shape names. ObjectLODForceAverageColor was default `0`. 

Test logs

The log shows you are using the 8k version again from the Pine Branches Redone, correct? The log also shows that the background color is set to something that is not black.

Please upload C:\Modding\Tools\DynDOLOD\DynDOLOD_Output\textures\DynDOLOD\LOD\DynDOLOD_Tamriel_Alpha.dds that was created around 2026-01-23 17:35:41

Then set ObjectLODAlphaDiffuseFormat=A8R8G8B8 in C:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini to disable the use of Texconv to convert the texture and then generate Tamriel again. Upload that log, debug log and created DynDOLOD_Tamriel_Alpha.dds as well.

[GreenEarings]

Hi, I've been getting a pretty consistent range check error running texgen64, was wondering if i could get some help. I triple checked that I'm on the latest version. The error happens at the same point in the process every time after several runs. I'm on linux running texgen64 through mo2 through proton.

Here are the files:

Bugreport: https://www.mediafire.com/file/sjypl86hp9csqxp/bugreport.txt/file

Debug log: https://www.mediafire.com/file/1tfppoutdsilxop/TexGen_SSE_Debug_log.txt/file

log: https://www.mediafire.com/file/0xscqu3vavb7tyf/TexGen_SSE_log.txt/file

I'll also upload the TexGen_SSE.ini: https://controlc.com/8cd88c66 , since I added some settings at the bottom to address a freezing/crashing error I was having initially:

LockTexconv=1
RenderSingle=1
RenderTexturesSingleThread=1

I also changed the MaxRenderResolution to 4096 per another related suggestion for running on linux. These fixes seemed to help with the freezing and it runs fine up until the range check error now. I looked around at other posts but couldn't find anything to do beyond trying out a test version, but the link to that had expired.  Thanks for any help

[sheson]

47 minutes ago, GreenEarings said:

Hi, I've been getting a pretty consistent range check error running texgen64, was wondering if i could get some help. I triple checked that I'm on the latest version. The error happens at the same point in the process every time after several runs. I'm on linux running texgen64 through mo2 through proton.

Here are the files:

Bugreport: https://www.mediafire.com/file/sjypl86hp9csqxp/bugreport.txt/file

Debug log: https://www.mediafire.com/file/1tfppoutdsilxop/TexGen_SSE_Debug_log.txt/file

log: https://www.mediafire.com/file/0xscqu3vavb7tyf/TexGen_SSE_log.txt/file

I'll also upload the TexGen_SSE.ini: https://controlc.com/8cd88c66 , since I added some settings at the bottom to address a freezing/crashing error I was having initially:

LockTexconv=1
RenderSingle=1
RenderTexturesSingleThread=1

I also changed the MaxRenderResolution to 4096 per another related suggestion for running on linux. These fixes seemed to help with the freezing and it runs fine up until the range check error now. I looked around at other posts but couldn't find anything to do beyond trying out a test version, but the link to that had expired.  Thanks for any help

Restore to the default TexGen_SSE.ini. Delete all old logs and bugreport.txt. Then run TexGen.
If it crashes / has an error message upload new bugreport.txt and logs as usual. If it freezes, try to close it normally with one click to the X top right so it can hopefully save the log and debug log. If that doesn't work enable the realtime log as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs and upload that.

There should be no reason for setting MaxRenderResolution anymore, since current versions should work around NVIDIA Linux drivers consuming all memory. Keep an eye on VRAM memory consumption.

[z929669]

7 hours ago, sheson said:

The log shows you are using the 8k version again from the Pine Branches Redone, correct? The log also shows that the background color is set to something that is not black.

Please upload C:\Modding\Tools\DynDOLOD\DynDOLOD_Output\textures\DynDOLOD\LOD\DynDOLOD_Tamriel_Alpha.dds that was created around 2026-01-23 17:35:41

Then set ObjectLODAlphaDiffuseFormat=A8R8G8B8 in C:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini to disable the use of Texconv to convert the texture and then generate Tamriel again. Upload that log, debug log and created DynDOLOD_Tamriel_Alpha.dds as well.

Here's the file. It still has the black alpha for the branches in question. 

I did use the unmodified 8k version with black backgrounds.

You will notice that this also is an issue with aspen branch birch03_c.dds

That one is from Aspens Ablaze 2.39

[z929669]

I will generate the new test momentarily.

[z929669]

Here's those logs + alpha.

[sheson]

35 minutes ago, z929669 said:

Here's those logs + alpha.

Please upload C:\Modding\Tools\DynDOLOD\Edit Scripts\Export\LODGen_SSE_ObjectAtlasMap_Tamriel.lst from the last generation.

[z929669]

1 minute ago, sheson said:

Please upload C:\Modding\Tools\DynDOLOD\Edit Scripts\Export\LODGen_SSE_ObjectAtlasMap_Tamriel.lst from the last generation.

LODGen_SSE_ObjectAtlasMap_Tamriel.7z

[sheson]

1 hour ago, z929669 said:

LODGen_SSE_ObjectAtlasMap_Tamriel.7z 11.66 kB · 2 downloads

Report if there atlas texture is generated any different after adding CPUMipMaps=1 under [DynDOLOD] to C:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

[RainingTacco]

On 1/23/2026 at 7:44 PM, sheson said:

See https://dyndolod.info/Help/Grass-LOD#Updating and https://dyndolod.info/Updating#New-or-Updated-Mods-or-Plugins.
For executing LODGen, which just generates new object LOD BTOs from distinct NIFs, any  existing BTOs are irrelevant.

Generating the millions of grass billboards into the hundreds BTOs files takes time. For me the total is 4 minutes for object, ultra 3D tree and grass LOD for vanilla Tamriel.

https://dyndolod.info/FAQ#Long-running-time-or-output-several-GB-in-file-size
Check ..\DynDOLOD\Logs\DynDOLOD_[GAME MODE]_ModelsUsed_[WORLDSPACE].txt for a list of meshes and their total contribution to the object LOD meshes file sizes. If the total file size for an object exceeds hundreds of MBs, consider creating an optimized LOD model.

Look for 3rd party "LOD" model that need optimizing. They more often then not are the cause for slow LOD generation and also having the worst impact on performance in game apart from grass LOD. Creating better LOD models is where to spend time on to improve things.

 

"To test different grass LOD densities, change the GrassDensity setting in ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_[WORLDSPACE].txt, start DynDOLOD in expert mode, select the desired worldspace and click the Execute LODGen button. Then merge the new output with the existing output, overwriting all older files. Remember to set the same desired Density in the advanced mode options in future LOD generations."

Fire up mo2, fire up dyndolod, change grass density, execute lodgen, load game, grass density didnt change - that is not the expected behavior when changing settings in main window for any sane user. And no, im not going to edit every export file or copy my settings to each of that, because i want to export for all worldspaces. Make your program more user friendly, or signal that execute lodgen does nothing with changed settings, because the settings you have to change are not in the window of the program you have in front of you, but in some files in export folder. That is extremely bad design imho. If you could open your code, i could add such functionality, idk what you use for rendering window but it looks like standard WPF so fairly easy. Why executing lodgen uses separate settings, ok. assume it has to, then make a button in the program to copy the current settings of the main window for executing lodgen, or open export menu where i can set it.

 

Nothing more user "friendly" than doing this stuff everytime

 

Edited 15 hours ago by RainingTacco

[z929669]

32 minutes ago, sheson said:

Report if there atlas texture is generated any different after adding CPUMipMaps=1 under [DynDOLOD] to C:\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_SSE.ini

I added CPUMipMaps=1 and used default ObjectLODAlphaDiffuseFormat=225.

The backgrounds of all textures are now using average color instead of black in DynDOLOD_Tamriel_Alpha.dds.

[sheson]

3 hours ago, RainingTacco said:

 

"To test different grass LOD densities, change the GrassDensity setting in ..\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Export_[WORLDSPACE].txt, start DynDOLOD in expert mode, select the desired worldspace and click the Execute LODGen button. Then merge the new output with the existing output, overwriting all older files. Remember to set the same desired Density in the advanced mode options in future LOD generations."

Fire up mo2, fire up dyndolod, change grass density, execute lodgen, load game, grass density didnt change - that is not the expected behavior when changing settings in main window for any sane user. And no, im not going to edit every export file or copy my settings to each of that, because i want to export for all worldspaces. Make your program more user friendly, or signal that execute lodgen does nothing with changed settings, because the settings you have to change are not in the window of the program you have in front of you, but in some files in export folder. That is extremely bad design imho. If you could open your code, i could add such functionality, idk what you use for rendering window but it looks like standard WPF so fairly easy. Why executing lodgen uses separate settings, ok. assume it has to, then make a button in the program to copy the current settings of the main window for executing lodgen, or open export menu where i can set it.

 

Nothing more user "friendly" than doing this stuff everytime

 

https://dyndolod.info#DynDOLOD-3-Alpha
Certain things may be incomplete, not work as expected or change considerably between versions.
Use the official DynDOLOD support forum to provide feedback

https://dyndolod.info/Official-DynDOLOD-Support-Forum
Report the actual problem or error message or provide feedback without making unverified assumptions or asking leading questions.

For example: "It would be nice if the grass density setting could just be changed in the expert interface when Executing LODGen instead of having to edit the export file."

Let me worry about how to implement things.
The instructions exist, because that is how things work with xEdit and the LODGen command line tool. I have not yet spend any of my free time to make it more convenient for non experts.

If you want to contribute, contribute to  https://github.com/TES5Edit/TES5Edit.

[sheson]

4 hours ago, z929669 said:

I added CPUMipMaps=1 and used default ObjectLODAlphaDiffuseFormat=225.

The backgrounds of all textures are now using average color instead of black in DynDOLOD_Tamriel_Alpha.dds.

Remove or set CPUMipMaps=0 so it uses the GPU instead again.

Get latest test version from https://dyndolod.info/Downloads/Test-Versions

Generate Tamriel only. It will create a bunch of test textures to the root of the dedicated output folder. Please upload all of them.

[z929669]

1 hour ago, sheson said:

Remove or set CPUMipMaps=0 so it uses the GPU instead again.

Get latest test version from https://dyndolod.info/Downloads/Test-Versions

Generate Tamriel only. It will create a bunch of test textures to the root of the dedicated output folder. Please upload all of them.

Here's the results with logs included just in case.

[GreenEarings]

18 hours ago, sheson said:

Restore to the default TexGen_SSE.ini. Delete all old logs and bugreport.txt. Then run TexGen.
If it crashes / has an error message upload new bugreport.txt and logs as usual. If it freezes, try to close it normally with one click to the X top right so it can hopefully save the log and debug log. If that doesn't work enable the realtime log as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs and upload that.

There should be no reason for setting MaxRenderResolution anymore, since current versions should work around NVIDIA Linux drivers consuming all memory. Keep an eye on VRAM memory consumption.

Just wanted to report that I reran with the default ini and realtime logging and it froze again. There were no additional errors in the logs except that the runtime debug showed it got stuck on a texconv thread. I reran with LockTexConv=1 and no other changes and this time it completed successfully. I probably overcorrected when editing the other settings, thanks for the reply