[WiP] Community shader PBR support

[Exist]

Hi, writing about support for the new Community Shaders PBR assets. Hopefully not much would be needed from your side. I will mention some facts I believe are causing issues with LODs. Because the PBR textures are incompatible with vanilla, we use unique paths (textures/pbr/ prefix) to avoid unintended meshes from using one of them and looking wrong. Meshes that use PBR can be distinguished by the Unused01 property in Shader Flags 2. PBR albedo is brighter than vanilla diffuse and is saved in dds with the sRGB flag, which converts it to linear on the gpu. Now the problems:

1. Some object LODs seem to be using regular textures, for example mountains. Because LODs won't use the PBR shader, using unmodified PBR textures makes it look wrong. This is our issue and I think authors can just generate lower res textures in the vanilla paths that will only be used for these LODs. I don't know how many LODs actually use regular textures but hope not many.
2. TexGen seems to ignore PBR textures. I suppose TexGen always uses vanilla paths and ignores Texture Set records, otherwise I don't know why this would happen. In this case it would be nice to take texture set paths into account, or check if a PBR path exists before vanilla one. For landscapes we could also have authors generate low res versions at vanilla paths, but it's not viable to do this for everything.
3. DynDOLOD uses PBR textures, but probably because of the sRGB flag (which converts them to linear) the LODs are too dark. This happens to tree LODs, objects such as farmhouses and nordic ruins seem good, but not sure. This would probably happen in the textures in the previous point too if they weren't ignored. From our experiments vanilla diffuse is roughly halfway between usual PBR albedo brightness in linear and sRGB. So it would be best to do something like apply power of 1/1.5 to make the brightness consistent with vanilla. Ideally it could be multiplied with ambient occlusion and adjusted based on metalness which are in another texture, but that's not needed.

Hopefully I got the reasons for why it doesn't work right, I will include some comparison screenshots and links to PBR assets so you can try it yourself. Thank you for taking the time to read this and I hope this can be supported. Oh and feel free to ping me or others on CS or Cathedral discord, I might forget to check back here for some time.

https://imgsli.com/Mjg5ODQ5
https://imgsli.com/Mjg5ODUy
https://imgsli.com/Mjg5ODU0
https://imgsli.com/Mjg5ODU1

More info about our PBR implementation: https://github.com/doodlum/skyrim-community-shaders/wiki/True-PBR

Some assets to try:

Trees - https://mega.nz/file/dqdzGLwY#jBJFwPIWv7iX314UEKZnHCRvlITLbXI7saLY-4oV6Nw

Farmhouses - https://mega.nz/file/duUxDKiA#mnzDzjBFXEIDq-MFoucOHRJT55wOmbUNHOLZ5JxG3lY

Lots of other stuff - https://onedrive.live.com/?authkey=!AB5oYH6iqIMDkHM&id=C23FB01B59FA671C!2427&cid=C23FB01B59FA671C

[sheson]

On 8/8/2025 at 1:22 AM, tmwd said:

Link to files, generated using "rename" in PG Json (same as before) on test version of TexGen: https://mega.nz/folder/rYtE2RyA#PYjJDeAF2ZTdMq9CsM1LCg 

Rename results: Exact same results as before (I didn't expect it to change, based on what you said, but I figured it didn't hurt to check anyways.)

Link to files, generated using old texture names on test version of TexGen: https://mega.nz/folder/OVtDCTxD#rTNS8z-XdzHYDkXqO1JEtw 

Old name results: This test with the old texture names did indeed use the correct bark on the lods, but the issue with the snow of the branches being purple on the lods is still present.

I'm not sure if this would be too tall of an ask, but is there a way to have the "renamed" textures be used for the bark? With the way my pbr textures are set up currently, I'd need to include 3+ copies of the same bark texture + normal + rmaos, just renamed, if I were to do it this way. The goal of this pbr mod I'm working on is for it to be used with any meshes (including plain vanilla trees)/mesh replacers that use the vanilla textures & texture paths, so I can't really include pre-patched meshes.

Are there other situations where it wouldn't use the renamed textures or does this only apply to the vanilla tree meshes? 

Sorry, I forgot to include in my previous message that when I generated lods using the textures as entirely vanilla replacers, no PG patching, no pbr path or anything, just right into the vanilla tree texture path, the snow was not purple on the lods.

Upload the json that is used by PGPatcher to patch the full model.

The crown/branch textures are already replaced to their new version of the patched full model. Which is the cause of the tint, sine the patch removes the third texture, which is used by the Soft_Lighting flag of the vanilla full model and its accompanying 3D LOD model. The patched version sets Rim_Lighting instead, which typically also uses the third texture at least in vanilla shaders - no idea if CS PBR shaders would make use of it.

Since the patch does more than the usual full texture replacement dedicated 3D tree LOD assets targeting the patched full model should be made for now:

Currently the CRC32 of the patched full model with the renamed textures is 6EDD0704.

..\Data\DynDOLOD\Render\Billboards\DynDOLOD\LOD\Trees\[mod identifier]\treepineforestsnow05_6EDD0704_trunk.nif

..\Data\Meshes\DynDOLOD\LOD\Trees\[mod identifier]\treepineforestsnow05_6EDD0704passthru_lod.nif

In case the patched full model CRC32 changes, you will need to update the CRC32 in the filenames accordingly.
Replace [mod identifier] with whatever you like that, the initials of the mod for example.
Edit the second 3D LOD model NIF in NifSkope and make sure to update the paths to the trunk textures that TexGen generates from the trunk NIF accordingly.

Use the already provided test version of TexGen to generate the trunk textures and then this test version of DynDOLOD  https://mega.nz/file/ddg12IZS#YVylaDyEVJq5j6a4UXdZuYKv7cyz1BMyADibeHhR_jM to generate the LOD patch.

[jepster]

I have been trying to get LoDs match for many weeks until found out something interesting.

My list is using CS with full PBR landscapes. But LoDs have been too bright for me and I had to use CS ingame sliders to tune them down. However snowdrifts and some similar meshes I could not tune down via the sliders which made it look bad: https://imgur.com/FV0snJZ. 

I had already lowered sRGBGamma to 1.4 and even below, but could not see an effect (finding later explains why it did not have an effect). After some weeks of poking around I noticed that the meshes seem to use textures/pbr/landscape/snow01linear.dds. So I took a look at the texture and darkened it for a test. As part of this I noticed that the texture had been created with SRGB color space. Changing it to linear and darkening it a bit helped me to get it match.

My feeling was the texture should not be in SRGB space. So I tried to understand why it was. I am on VR running with high resolution. So I like to use DXT1 / BC1 as I can get double the resolution for the same VRAM costs. I know not all image tools support all format variations, so I changed it back to BC7. After rerunning Dyndolod I noticed the texture was created in linear space.

TLDR: 

SRGB-to-linear conversion for DXT1 does not seem to be supported (but would be nice if it would). This goes for all three: xLodGen, TexGen and Dyndolod. I have not attached logs, as I do not think it is a very special issue. Probably just an unsupported thing. However, if it helps I am happy to share logs.

 

 

Edited August 27 by jepster

[sheson]

6 hours ago, jepster said:

I have been trying to get LoDs match for many weeks until found out something interesting.

My list is using CS with full PBR landscapes. But LoDs have been too bright for me and I had to use CS ingame sliders to tune them down. However snowdrifts and some similar meshes I could not tune down via the sliders which made it look bad: https://imgur.com/FV0snJZ. 

I had already lowered sRGBGamma to 1.4 and even below, but could not see an effect (finding later explains why it did not have an effect). After some weeks of poking around I noticed that the meshes seem to use textures/pbr/landscape/snow01linear.dds. So I took a look at the texture and darkened it for a test. As part of this I noticed that the texture had been created with SRGB color space. Changing it to linear and darkening it a bit helped me to get it match.

My feeling was the texture should not be in SRGB space. So I tried to understand why it was. I am on VR running with high resolution. So I like to use DXT1 / BC1 as I can get double the resolution for the same VRAM costs. I know not all image tools support all format variations, so I changed it back to BC7. After rerunning Dyndolod I noticed the texture was created in linear space.

TLDR: 

SRGB-to-linear conversion for DXT1 does not seem to be supported (but would be nice if it would). This goes for all three: xLodGen, TexGen and Dyndolod. I have not attached logs, as I do not think it is a very special issue. Probably just an unsupported thing. However, if it helps I am happy to share logs.

Moved to the post to the appropriate thread.

Upload a DXT1 sRGB texture that does not seem to be converted to linear RGB.

Upload the TexGen and DynDOLOD logs and debug logs. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs
Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt.

Make a useful screenshot of a (snow drift?) full model that has too bright snow with more informative console. Also make a screenshot of LOD up close. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots

[jepster]

22 hours ago, sheson said:

Moved to the post to the appropriate thread.

Upload a DXT1 sRGB texture that does not seem to be converted to linear RGB.

Upload the TexGen and DynDOLOD logs and debug logs. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs
Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt.

Make a useful screenshot of a (snow drift?) full model that has too bright snow with more informative console. Also make a screenshot of LOD up close. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots

Taking screenshots in VR is a pain and using free fly camera even more as my Skyrim Freezes regularly when do things in VR desktop mode. So please excuse I cannot really get a better one than above.

When debugging I found one of those meshes with bright snow LoD and looked it up in xEdit. There I saw it uses pbr\landscape\snow01linear.dds. Please see here: https://imgur.com/eI4PtaH

Afterwards I validated around a dozen *linear.dds textures with Nvidia Texture Tools Exporter and they were all BC1 SRGB. Uploaded one as example here: https://limewire.com/d/6gZ7d#GgjZKjx5Na

However, the LoD snow texture standing out is still the case even with bc7 in linear space. I manually darkened it a lot to match, which worked fine. But have not really found out why it does not match.

 

[sheson]

12 hours ago, jepster said:

Taking screenshots in VR is a pain and using free fly camera even more as my Skyrim Freezes regularly when do things in VR desktop mode. So please excuse I cannot really get a better one than above.

When debugging I found one of those meshes with bright snow LoD and looked it up in xEdit. There I saw it uses pbr\landscape\snow01linear.dds. Please see here: https://imgur.com/eI4PtaH

Afterwards I validated around a dozen *linear.dds textures with Nvidia Texture Tools Exporter and they were all BC1 SRGB. Uploaded one as example here: https://limewire.com/d/6gZ7d#GgjZKjx5Na

However, the LoD snow texture standing out is still the case even with bc7 in linear space. I manually darkened it a lot to match, which worked fine. But have not really found out why it does not match.

 

The uploaded texture is reported by Texdiag to use the BC1_UNORM texture format and not the BC1_UNORM_SRGB format. It shows DXT1 in the header.

Upload the actual source PBR diffuse texture ..\textures\PBR\landscape\snow01.dds from which the linear and LOD textures are made from.

Upload the TexGen and DynDOLOD logs and debug logs. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs
Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt.

Make a useful screenshot of a full model that has too bright LOD with more informative console. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots so we know the actual full model, reference and base record to look up in the logs.

Then make a screenshot like https://imgur.com/FV0snJZ but this time with all LOD disabled via console tll. I expect the too bright snow LOD in that screenshot to also be toggled off, which would mean they are not dynamic LOD and do not use the base record shown in the xEdit screenshots.

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#xEdit-Screenshots how not to trim anything from the xEditscreenshots. The base record will most likely have a Reference By tab at the bottom, which lists the references using it. I expect this not to be more than a handful, maybe a dozen dynamic LOD references unless you did something odd with the meshes mask rules or settings.

The object LOD for the snow drift should typically use the object LOD texture atlas generated by DynDOLOD which should be made with ..\textures\lod\snow01pbr_lod.dds from the TexGen output. So upload the that texture as well.

[tmwd]

On 8/8/2025 at 2:09 PM, sheson said:

Upload the json that is used by PGPatcher to patch the full model.

The crown/branch textures are already replaced to their new version of the patched full model. Which is the cause of the  tint, sine the patch removes the third texture, which is used by the Soft_Lighting flag of the vanilla full model and its accompanying 3D LOD model. The patched version sets Rim_Lighting instead, which typically also uses the third texture at least in vanilla shaders - no idea if CS PBR shaders would make use of it.

Since the patch does more than the usual full texture replacement dedicated 3D tree LOD assets targeting the patched full model should be made for now:

Currently the CRC32 of the patched full model with the renamed textures is 6EDD0704.

..\Data\DynDOLOD\Render\Billboards\DynDOLOD\LOD\Trees\[mod identifier]\treepineforestsnow05_6EDD0704_trunk.nif

..\Data\Meshes\DynDOLOD\LOD\Trees\[mod identifier]\treepineforestsnow05_6EDD0704passthru_lod.nif

In case the patched full model CRC32 changes, you will need to update the CTC32 in the filenames accordingly.
Replace [mod identifier] with whatever you like that, the initials of the mod for example.
Edit the second 3D LOD model NIF in NifSkope and make sure to update the paths to the trunk textures that TexGen generates from the trunk NIF accordingly.

Use the already provided test version of TexGen to generate the trunk textures and then this test version of DynDOLOD  https://mega.nz/file/9FBARASR#pwrzcPP2PZeB8zxXkOr_NpPOWTk9wlKwvCLszXZWmpc to generate the LOD patch.

Sorry for the delay on getting back to you on this, and for jumping in while you're helping with another issue - I needed to step away from trying to resolve this for a bit. 

Here are the jsons used for the branches and bark:treepineforestbranchcompsnow.json treepineforestbarkcompsnow.json

And just for the sake of confirming ahead of time - I did try without using the rename function in the json, and it did still result in the same issue with the purple snow. Without the rename, it did use the correct bark, that was the only difference. I also did try with setting the subsurface flag to false, and it had the same results.

Do you see something that'd cause this issue? My understanding is that PG should patch the meshes, and the ParallaxGen_Diff.json *should* mean it won't have any issues creating lods the standard way. With the goal of this mod, it's not really feasible for me to create and ship lod meshes, because the goal is for this to just be a vanilla pbr texture replacer, shipping lod meshes would mean that I'd need to create them for any mod that replaces the vanilla meshes, but keeps the vanilla textures, as well. So if there is a way to resolve this without doing that, that would be much more ideal.

[xianhuajuaner]

I'd like to ask a question. Since my English is not very good, I don't understand many things very well. I would like to ask if this tool can generate textured terrain for PBR landscapes? I have tried many times, but each time I have not been successful. The textures are always incorrect when the distance is far, and the textures will load correctly when the distance is closer. So I would like to know how to correctly generate landscape texture terrain with PBR materials.

[sheson]

On 9/2/2025 at 6:19 AM, xianhuajuaner said:

I'd like to ask a question. Since my English is not very good, I don't understand many things very well. I would like to ask if this tool can generate textured terrain for PBR landscapes? I have tried many times, but each time I have not been successful. The textures are always incorrect when the distance is far, and the textures will load correctly when the distance is closer. So I would like to know how to correctly generate landscape texture terrain with PBR materials.

Moved to the appropriate thread for PBR. See posts above.

See https://dyndolod.info/Mods/Community-Shaders#PBR and https://dyndolod.info/Help/xLODGen#Terrain-LOD-Textures-Brightness

If the distant terrain is too bright, lower the gamma setting in xLODGen. For example to 0.7 as a start.

Use the specific chunk option to generate a specific area only for quicker testing. See Terrain-LOD-Readme.txt in the xLODGen folder.

[jepster]

On 8/29/2025 at 9:20 AM, sheson said:

The uploaded texture is reported by Texdiag to use the BC1_UNORM texture format and not the BC1_UNORM_SRGB format. It shows DXT1 in the header.

Upload the actual source PBR diffuse texture ..\textures\PBR\landscape\snow01.dds from which the linear and LOD textures are made from.

Upload the TexGen and DynDOLOD logs and debug logs. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs
Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt.

Make a useful screenshot of a full model that has too bright LOD with more informative console. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots so we know the actual full model, reference and base record to look up in the logs.

Then make a screenshot like https://imgur.com/FV0snJZ but this time with all LOD disabled via console tll. I expect the too bright snow LOD in that screenshot to also be toggled off, which would mean they are not dynamic LOD and do not use the base record shown in the xEdit screenshots.

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#xEdit-Screenshots how not to trim anything from the xEditscreenshots. The base record will most likely have a Reference By tab at the bottom, which lists the references using it. I expect this not to be more than a handful, maybe a dozen dynamic LOD references unless you did something odd with the meshes mask rules or settings.

The object LOD for the snow drift should typically use the object LOD texture atlas generated by DynDOLOD which should be made with ..\textures\lod\snow01pbr_lod.dds from the TexGen output. So upload the that texture as well.

Sorry for the late reply, family business :-)

I hope I got everything together here: https://limewire.com/d/Nw8an#vQlSDvtUOL

[sheson]

2 hours ago, jepster said:

Sorry for the late reply, family business :-)

I hope I got everything together here: https://limewire.com/d/Nw8an#vQlSDvtUOL

Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt.

Make a useful screenshot of a full model that has too bright LOD with more informative console. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots: Use Mfg Console or More Informative Console to show additional information when opening the console and clicking an object. Keep the selected object visible to the side, so it is not covered by the informative panels. Also try to make a useful screenshot with more informative console of one if the dynamic LOD models in the distance. Try to get closer with tcl. If that proofs too difficult, the DynDOLOD_SSE_Object_Report.txt hopefully tells me what I need to know.

The upload full source snow01.dds is BC7 sRGB and not BC1 sRGB. I thought you reported a problem with source textures being BC1 SRGB?

You reported earlier, that setting 1.4 gamma had no effect. The log however shows that sRGBGamma was still default 2.2? The generated snow01pbr_lod.dds looks as one would expect with the default gamma and alpha channel removed. If you want it darker, lower the sRGBGamma setting in the TexGen and DynDOLOD INI. See https://dyndolod.info/Mods/Community-Shaders#PBR

The snow01linear.dds you upload earlier looks like it was generated from a different snow01.dds.

[jepster]

17 hours ago, sheson said:

Also upload ..\DynDOLOD\Logs\DynDOLOD_SSE_Object_Report.txt.

Make a useful screenshot of a full model that has too bright LOD with more informative console. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots: Use Mfg Console or More Informative Console to show additional information when opening the console and clicking an object. Keep the selected object visible to the side, so it is not covered by the informative panels. Also try to make a useful screenshot with more informative console of one if the dynamic LOD models in the distance. Try to get closer with tcl. If that proofs too difficult, the DynDOLOD_SSE_Object_Report.txt hopefully tells me what I need to know.

The upload full source snow01.dds is BC7 sRGB and not BC1 sRGB. I thought you reported a problem with source textures being BC1 SRGB?

You reported earlier, that setting 1.4 gamma had no effect. The log however shows that sRGBGamma was still default 2.2? The generated snow01pbr_lod.dds looks as one would expect with the default gamma and alpha channel removed. If you want it darker, lower the sRGBGamma setting in the TexGen and DynDOLOD INI. See https://dyndolod.info/Mods/Community-Shaders#PBR

The snow01linear.dds you upload earlier looks like it was generated from a different snow01.dds.

The screenshot is really difficult to take. To activate the console in VR I need to jump to 'Desktop Mode'. But then very quickly the Virtual Desktop Streamer freezes. So I can move a bit via keyboard, but usually with my view to the ground as the headset is disconnected.

But I uploaded the report, hoping it helps: https://limewire.com/d/1S6sP#I9u0GxBcWT

The upload full source snow01.dds is BC7 sRGB and not BC1 sRGB. I thought you reported a problem with source textures being BC1 SRGB?
>> The snow01.dds is the file from the landscape texture pack. This is BC7. TexGen and Dyndolod settings were set to create BC1 textures. But there is no snow01.dds from both.

You reported earlier, that setting 1.4 gamma had no effect. The log however shows that sRGBGamma was still default 2.2?
>> I have uploaded the unaltered .ini files also. You can see that sRGBgamma has been set to 1.4. Not sure why it is being ignored. Hope I am not making a mistake.

The snow01linear.dds you upload earlier looks like it was generated from a different snow01.dds.
>> Yes, I noted this too. I am not sure why it looks so different from actual snow textures. Could it be sRGB conversions?

[sheson]

On 9/4/2025 at 6:35 PM, jepster said:

The screenshot is really difficult to take. To activate the console in VR I need to jump to 'Desktop Mode'. But then very quickly the Virtual Desktop Streamer freezes. So I can move a bit via keyboard, but usually with my view to the ground as the headset is disconnected.

But I uploaded the report, hoping it helps: https://limewire.com/d/1S6sP#I9u0GxBcWT

The upload full source snow01.dds is BC7 sRGB and not BC1 sRGB. I thought you reported a problem with source textures being BC1 SRGB?
>> The snow01.dds is the file from the landscape texture pack. This is BC7. TexGen and Dyndolod settings were set to create BC1 textures. But there is no snow01.dds from both.

You reported earlier, that setting 1.4 gamma had no effect. The log however shows that sRGBGamma was still default 2.2?
>> I have uploaded the unaltered .ini files also. You can see that sRGBgamma has been set to 1.4. Not sure why it is being ignored. Hope I am not making a mistake.

The snow01linear.dds you upload earlier looks like it was generated from a different snow01.dds.
>> Yes, I noted this too. I am not sure why it looks so different from actual snow textures. Could it be sRGB conversions?

TexGen typically (with a few exception regarding glow maps and non alpha textures) generates LOD textures from full textures. Thus they have the lod.dds ending.
DynDOLOD generates the linear versions on demand if a LOD NIF with a normal shader would otherwise end using a sRGB texture.

sRGBGamma=1.0 ; 2.2 in Texgen_SSE.ini or DynDOLOD_SSE.ini is not going to work. The line should not contain a comment separated by ; it should just be:
sRGBGamma=1.0

The conversion changes brightness of all color channels equally. The different looking snow01linear.dds must have been generated from a different snow01.dds at that time.

Fix the last / mesh mask rule to Level0 for LOD 4 instead of Level1. Do not set anything to Level 32 unless you intent to actually generate it for the map. That should always be the case when clicking low, medium, high to populate the rules for the current load order. If not, reinstall the DynDOLOD Standalone to make the included rules files default again.

[sheson]

On 8/30/2025 at 5:24 AM, tmwd said:

Sorry for the delay on getting back to you on this, and for jumping in while you're helping with another issue - I needed to step away from trying to resolve this for a bit.

Here are the jsons used for the branches and bark:treepineforestbranchcompsnow.json treepineforestbarkcompsnow.json

And just for the sake of confirming ahead of time - I did try without using the rename function in the json, and it did still result in the same issue with the purple snow. Without the rename, it did use the correct bark, that was the only difference. I also did try with setting the subsurface flag to false, and it had the same results.

Do you see something that'd cause this issue? My understanding is that PG should patch the meshes, and the ParallaxGen_Diff.json *should* mean it won't have any issues creating lods the standard way. With the goal of this mod, it's not really feasible for me to create and ship lod meshes, because the goal is for this to just be a vanilla pbr texture replacer, shipping lod meshes would mean that I'd need to create them for any mod that replaces the vanilla meshes, but keeps the vanilla textures, as well. So if there is a way to resolve this without doing that, that would be much more ideal.

You did not upload any assets that you referred to in your post or provided any logs, so the explanation for the cause of tint still applies:
The crown/branch textures are already replaced to their new version of the patched full model. Which is the cause of the tint, sine the patch removes the third texture, which is used by the Soft_Lighting flag of the vanilla full model and its accompanying 3D LOD model. The patched version sets Rim_Lighting instead, which typically also uses the third texture at least in vanilla shaders - no idea if CS PBR shaders would make use of it.

If you do not want to create a dedicated LOD model with the appropriate shader settings that does not require a 3rd texture. You could try setting the 3rd texture with PG, either to the diffuse texture or just black.dds for example.

You seem to expect tools (and by proxy the tool makers) to automatically account for your mod and do extra work. Right now PG just exports CRC32s without information about any changes made to the full model. I have explained how to create dedicated LOD models that target the modified full models that are not vanilla anymore. That is the standard way at the moment. I will see what I can do about a trunk NIF that was made for specific full models to automatically use the changed texture filenames for full models changed by PG. Check if it works with the next alpha release.

[jepster]

On 9/7/2025 at 9:38 AM, sheson said:

TexGen typically (with a few exception regarding glow maps and non alpha textures) generates LOD textures from full textures. Thus they have the lod.dds ending.
DynDOLOD generates the linear versions on demand if a LOD NIF with a normal shader would otherwise end using a sRGB texture.

sRGBGamma=1.0 ; 2.2 in Texgen_SSE.ini or DynDOLOD_SSE.ini is not going to work. The line should not contain a comment separated by ; it should just be:
sRGBGamma=1.0

The conversion changes brightness of all color channels equally. The different looking snow01linear.dds must have been generated from a different snow01.dds at that time.

Fix the last / mesh mask rule to Level0 for LOD 4 instead of Level1. Do not set anything to Level 32 unless you intent to actually generate it for the map. That should always be the case when clicking low, medium, high to populate the rules for the current load order. If not, reinstall the DynDOLOD Standalone to make the included rules files default again.

Thanks you so much for your help, Sheson! This finally helped to resolve this. I spent so much time pulling the wrong levers and in the end it is just me wrongly assuming inline comments would be fine.

After removing those and changing the mesh rule the gamma correction finally has an effect. And what is even better, I can also adjust brightness of the snowpiles via CS sliders which until then had no effect.

LoD finally looks great. For me who is playing this to enjoy the views it is really wonderful :-)

[sheson]

2 hours ago, jepster said:

Thanks you so much for your help, Sheson! This finally helped to resolve this. I spent so much time pulling the wrong levers and in the end it is just me wrongly assuming inline comments would be fine.

After removing those and changing the mesh rule the gamma correction finally has an effect. And what is even better, I can also adjust brightness of the snowpiles via CS sliders which until then had no effect.

LoD finally looks great. For me who is playing this to enjoy the views it is really wonderful :-)

That's great. Enjoy.