DynDOLOD 3.00 Alpha 198

[captainlei1993]

It would be better to patch that word wall on your end(exe I guess) so we can keep its dynamic LOD as well as having its LOD showing on map without removing its enable parent then regenerating LODs. The enable parent is only used by the "traveling back through time" scene after reading the elder scroll, during which the player is stuck in first person and can't open the map so the dynamic LOD doesn't really matter 99% the time.

[captainlei1993]

I can't rerun the test version of DynDOLOD you shared today:

[Window Title]
DynDOLOD

[Main Instruction]
This shared free alpha version of DynDOLOD is several months old and long outdated!

[Content]
Download and use the latest shared free alpha version to continue participating in the alpha test to help find and report any bugs or issues to the official DynDOLOD support forum to recive help for problems and to improve the tools for everyone.

Updating while keeping existing settings takes only a couple minutes. Do not install over older versions. Follow the update instructions:

Click on this link for additional explanations and help for this message
https://dyndolod.info/Updating

For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum.

[Exit DynDOLOD]

[Footer]
Online Help | Support Forum | Copy message to clipboard

 

 

[sheson]

1 hour ago, captainlei1993 said:

It would be better to patch that word wall on your end(exe I guess) so we can keep its dynamic LOD as well as having its LOD showing on map without removing its enable parent then regenerating LODs. The enable parent is only used by the "traveling back through time" scene after reading the elder scroll, during which the player is stuck in first person and can't open the map so the dynamic LOD doesn't really matter 99% the time.

The reason is a game engine limitation/bug in the game causing CTD which I will address at some point.

Not seeing the LOD seems to be an issue unique to ACMOS users. Test if adding the enable parent form ID to C:\Games\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_xesplod.txt has the desired effect.

Skyrim.esm;0005EACB;MQ206statePresent

[sheson]

9 minutes ago, captainlei1993 said:

I can't rerun the test version of DynDOLOD you shared today:

[Window Title]
DynDOLOD

[Main Instruction]
This shared free alpha version of DynDOLOD is several months old and long outdated!

[Content]
Download and use the latest shared free alpha version to continue participating in the alpha test to help find and report any bugs or issues to the official DynDOLOD support forum to recive help for problems and to improve the tools for everyone.

Updating while keeping existing settings takes only a couple minutes. Do not install over older versions. Follow the update instructions:

Click on this link for additional explanations and help for this message
https://dyndolod.info/Updating

For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum.

[Exit DynDOLOD]

[Footer]
Online Help | Support Forum | Copy message to clipboard

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

Works as expected here. It should be good for several months as usual. There is a new test version.

[captainlei1993]

1 hour ago, sheson said:

The reason is a game engine limitation/bug in the game causing CTD which I will address at some point.

Not seeing the LOD seems to be an issue unique to ACMOS users. Test if adding the enable parent form ID to C:\Games\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_xesplod.txt has the desired effect.

Skyrim.esm;0005EACB;MQ206statePresent

It seems DynDOLOD showed that "using the outdated version" prompt because I set cpoverride english to utf8 in sseviewsettings for xEdit. Anyway your method works. Now I can see the word wall on the map. Thanks for your effort!

Edited Thursday at 05:24 PM by captainlei1993

[sheson]

18 minutes ago, captainlei1993 said:

It seems DynDOLOD showed that "using the outdated version" prompt because I set cpoverride english to utf8 in sseviewsettings for xEdit. Anyway your method works. Now I can see the word wall on the map. Thanks for your effort!

Requests logs were not provided.

TexGen/DynDOLOD typically do not access the xEdit viewsettings files and instead use INI files in the DynDOLOD Standalone installation folder.
The log reports it like this:
Using settings file: C:\Games\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD.ini

[z929669]

11 hours ago, sheson said:

Get the latest test version.

Compare its generate alpha atlas texture matches the one you got with CPUMipMaps=1. It won't be equal, but they should hopefully look very close. Average background if black or existing background should be kept. Report results.

The latest test versions seems to have resolved the persistent black background issue. I ran DynDOLOD without any of the test settings you had me use earlier, and the diffuse backgrounds of all textures appear to be using the average RGB except the aspen branch. Strangely, this branch is using the source mips rather than DynDOLOD's as if aspen shape names have `usemipmaps` keyword (but that's not the case). I've given this one a blue outline. Similarly, the normal atlas is also using the native normal mips for this branch. If you want to reproduce, download Aspens Ablaze 2.39 main file and use the AA Add-On (Quality option).

You will also notice that the pine textures mod we've been using for testing strangely uses pure black in the RGB matching the alpha mask, which is causing the pine tops to be too bright in LOD ...probably because the shader is getting some mip bleed in the normal mips (DynDOLOD is re-mipping all pine textures). I guess I expected that DynDOLOD would also re-mip the branch normals, but if it is doing that, it is using the invalid source normal with black background (should be 128/128/255 instead of black). This is obviously not a DynDOLOD problem but one of the reasons I am remaking these textures from source. I will share results once finished now that I can test without any keywords in the shape names ...I've been testing my remade versions of the textures with `usemipmaps` to rule out the black background in the DynDOLOD atlases as being a contributing factor to the dark pine tops. I will continue reworking these textures using DynDOLOD's default texture handling.

Here's the logs for the run that produced the fixed backgrounds in the atlas (above screens).

[sheson]

10 hours ago, z929669 said:

The latest test versions seems to have resolved the persistent black background issue. I ran DynDOLOD without any of the test settings you had me use earlier, and the diffuse backgrounds of all textures appear to be using the average RGB except the aspen branch. Strangely, this branch is using the source mips rather than DynDOLOD's as if aspen shape names have `usemipmaps` keyword (but that's not the case). I've given this one a blue outline. Similarly, the normal atlas is also using the native normal mips for this branch. If you want to reproduce, download Aspens Ablaze 2.39 main file and use the AA Add-On (Quality option).

You will also notice that the pine textures mod we've been using for testing strangely uses pure black in the RGB matching the alpha mask, which is causing the pine tops to be too bright in LOD ...probably because the shader is getting some mip bleed in the normal mips (DynDOLOD is re-mipping all pine textures). I guess I expected that DynDOLOD would also re-mip the branch normals, but if it is doing that, it is using the invalid source normal with black background (should be 128/128/255 instead of black). This is obviously not a DynDOLOD problem but one of the reasons I am remaking these textures from source. I will share results once finished now that I can test without any keywords in the shape names ...I've been testing my remade versions of the textures with `usemipmaps` to rule out the black background in the DynDOLOD atlases as being a contributing factor to the dark pine tops. I will continue reworking these textures using DynDOLOD's default texture handling.

Here's the logs for the run that produced the fixed backgrounds in the atlas (above screens).

Test and report if the result closely matches the output of using CPUMipMaps.

You did not say what the texture filename of the highlighted texture is. The average color algorithm is only applied to diffuse textures that have black transparent pixels - unless you enable the force setting.  Have you checked that the mipmap levels on the object LOD atlas texture are actually equal copies from the full texture and not created by DynDOLOD from the lowest mipmap level? Upload the LODGen_SSE_ObjectAtlasMap_Tamriel.lst.

Normal map textures have a specular channel that does not have any relation to the other 3 channels, which represent a vector with a length of 1, that typically should have z >= 0.0 (blue channel > 127). Normal map textures with x, y, z = 0 are just invalid. I suggest to report the invalid textures to the mod author so they can create valid normal map textures.

[z929669]

7 hours ago, sheson said:

Test and report if the result closely matches the output of using CPUMipMaps.

You did not say what the texture filename of the highlighted texture is. The average color algorithm is only applied to diffuse textures that have black transparent pixels - unless you enable the force setting.  Have you checked that the mipmap levels on the object LOD atlas texture are actually equal copies from the full texture and not created by DynDOLOD from the lowest mipmap level? Upload the LODGen_SSE_ObjectAtlasMap_Tamriel.lst.

Normal map textures have a specular channel that does not have any relation to the other 3 channels, which represent a vector with a length of 1, that typically should have z >= 0.0 (blue channel > 127). Normal map textures with x, y, z = 0 are just invalid. I suggest to report the invalid textures to the mod author so they can create valid normal map textures.

Given what you say, there is no issue with the AA textures in the DynDOLOD atlas. DynDOLOD appears to be either using the AA birch03*.dds mips directly or recreating them from the birch03*.dds AA basis. Those textures have no validity issues natively or on the atlas.

The DynDOLOD alpha atlases in general and for the pine branches in particular are nearly identical now with CPUMipMaps=0/1, so I think you nailed it.

Here's the relevant logs and export for the CPUMipMaps tests.

Here's the atlases for both if you want to compare directly.

[sheson]

47 minutes ago, z929669 said:

Given what you say, there is no issue with the AA textures in the DynDOLOD atlas. DynDOLOD appears to be either using the AA birch03*.dds mips directly or recreating them from the birch03*.dds AA basis. Those textures have no validity issues natively or on the atlas.

The DynDOLOD alpha atlases in general and for the pine branches in particular are nearly identical now with CPUMipMaps=0/1, so I think you nailed it.

Here's the relevant logs and export for the CPUMipMaps tests.

Here's the atlases for both if you want to compare directly.

If you compare the 512x512 mipmap of birch03_c.dds to the 512x512 texture on the atlas, you will notice that the black/white transparent parts have been replaced with the average background color as expected and that the alpha channel is a bit more opaque due to the alpha-to-coverage. The 512x512 has been sampled from the 4k mipmap according the the logs.

birch03_c.7z

[aazz]

Hello, I'm having trouble using the mod "Shalidor's Insights - Winterhold Spire Resculpted." When I use this mod and run dyndolod, the LOD for Winterhold Spire disappears.

If you move away from this object for a little while, it will disappear, leaving the College of Winterhold floating in the air. 

Looking at the records with Xedit, it looks like the LOD meshes are linked separately. 

https://mega.nz/file/XZA13YrJ#LJ8u7rdVrQTYryPls41nc34Dwsqx0YAzC3CZUVLIyS0

Here are the dyndolod logs and meshes attached. I'm not sure if this is a problem with the mod or something I did wrong when running dyndolod. If you have time, I'd appreciate some advice.

[PenguinSempy]

hey guys I was wondering if any of you ran into this problem with the new dyndolod. My lod textures are really dark from a distance but my tree and grass lods are fine. https://ibb.co/MWBwGk9

I was thinking this might be because I have a lot of 4k textures but it was working before the update to dyndolod.

[z929669]

7 hours ago, sheson said:

If you compare the 512x512 mipmap of birch03_c.dds to the 512x512 texture on the atlas, you will notice that the black/white transparent parts have been replaced with the average background color as expected and that the alpha channel is a bit more opaque due to the alpha-to-coverage. The 512x512 has been sampled from the 4k mipmap according the the logs.

birch03_c.7z 274.94 kB · 1 download

Ahh yes, I see that now. I was looking at the entire background rather than those black/white areas, and I failed to set up a proper compare rather than eyeballing them. I assume you agree GPU mipmapping is behaving as expected now (at least for my GPU family).

Also the dark pine tops I opened with are looking to be more a factor of the normal faces on the mesh than the textures themselves. Both still have an impact, but normal faces have more influence now that I understand what was happening with those invalid normals with black background in RGB. They were inputting garbage to the shaders that caused the bright tops in LOD, and there is alpha diffuse/normal background bleed in the loaded trees as well.

The odd thing is that the invalid normals actually match better in LOD if I apply `usemipmaps`, but it's not the case with a fixed version of that normal or my own remade diffuse/normals. Here's some screen compares. Ignore any changes to aspens if you notice them. I opportunistically tested `usemipmaps` on them in a couple of the images (the native mips are insufficient).

1. LOD Reference: Scene with TLL
2. Native mod textures: 16K diffuse, 8K (invalid) normal from the mod, no shape name (default DyhnDOLOD treatment) LOGS
3. Mod textures, fixed normal: 16K diffuse, replaced black normal background with 128/128/255 background (8K), no shape name (default DyhnDOLOD treatment) LOGS
4. Native mod textures, usemipmaps: 16K diffuse, 8K (invalid) normal from the mod, `usemipmaps` shape name LOGS
5. Mod textures, fixed normal, usemipmaps: 16K diffuse, replaced black normal background with 128/128/255 background (8K), `usemipmaps` shape name LOGS
6. Remade textures: remade 16K diffuse and normal from source PNG, no shape name (default DyhnDOLOD treatment) LOGS
7. Remade textures, usemipmaps: remade 16K diffuse and normal from source PNG, `usemipmaps` shape name LOGS

LOD Reference   Native mod textures Mod textures, fixed normal  Native mod textures, usemipmaps   Mod textures, fixed normal, usemipmaps

Remade textures Remade textures, usemipmaps

 

To be clear, I don't think this is a DynDOLOD issue at this point. I'm only seeking advice as to why the only matching pine LOD seem to be when using the invalid mod normal and `usemipmaps` in the shape name of the branch meshes. I'm guessing that these LOD 'matching' is just a fluke ...the mod textures lose a bit too much alpha coverage at distance, and the pines are a bit too dark (loaded and LOD) due to alpha bleed. My remade versions have optimal diffuse alpha and no normal alpha (BC7 both). I can share whatever is needed on request if you are interested.