[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

[Exist]

Ah maybe this is two issues then. The new build doesn't change anything about this Logs.7z

EDIT: Weirdly, I don't notice this with converted NotWL (https://mega.nz/file/dqNFBaLB#X0qUrtCO3D0Ll6YTdOyEPnNHwThkxPi0hh87eTQ1gAE) 

Edited April 17 by Exist

[tmwd]

  On 4/17/2025 at 6:52 AM, sheson said:

The pixels turning white has to do with some shapes having the specular flag set together with the PBR Specular Strength value meaning something else than for the vanilla shader and not old vanilla shader specular map/channel being available. So for now TexGen will just ignore the setting in this case.

Try this test version https://mega.nz/file/FYIXUA6A#-RkJI7fyFzLGw5fN9i7YFjUeC8w1f-UotvaHuzSMMjk

Expand  

The test version seems to work great for the issue I was having.

I'll have to tweak the colors a bit so it matches up better, but thats an issue with Aspens Ablaze PBR, cause the NoTWL PBR that I'm using matches up nearly perfectly now and it was also having this issue before.

Thanks for looking into this!

[sheson]

  On 4/16/2025 at 9:16 PM, Exist said:

Logs.7z 328.63 kB · 0 downloads

I've been able to reproduce this with my PBR HLT ( https://mega.nz/file/YrkyQQhb#h3BcZFp0oQYLQ_JKiUCxy-YDKgMSnJtIzS6zL5wf5ec ). My guess is that this has to do with how direct light in texgen interacts with double-sided meshes, like it always considered direction the primary side is facing, instead of whichever side is facing the light. The ambient light is fine. Last picture is a view of the backfaces in Blender.

This happens both with meshes patched from the original HLT and those I edited by hand. I feel this might be reproducible with non-pbr meshes too, but I'm not sure what I'm seeing because the light can't go that strong when previewing them.

Expand  

What you see is the result of normal vectors pointing weird ways. It looks like ParallaxGen might be doing something to them. They are not the same as the original full modelon the left.

Note that TexGen ignores the skinned shapes and just uses the static ones, the second NiNode child of the NiSwitchNode.

The double side flag does not change anything about normal vector / direct sun light in the vanilla game shaders . The back side is darker unless the back light flag, which utilizes the 8th texture slot to define the intensities. The flags soft, rim together with lighting effect 1/2 shader settings and 3rd texture also affect it. That is what is usually used by tree leaves. Check vanilla trees. Back light flag is not yet supported by TexGen since I have have no seen a full model tree make use of that. The 8th texture slot is used for something else in PBR.

Note that - technically - the diffuse texture of HD billboards should simply be 100 diffuse and 0 direct light, since they also have a rendered normal map texture for the direct light in the game. But then they look rather flat in the game. The direct/ambient light option in TexGen help to give more definition/highlights as well. Note that the rendered normal map textures of HD billboards only has positive vectors, since the game does not support negative ones

Note that billboards in the game using the rendered textures might use the double sided flag as well and depending on the method/NIF can use bend vectors that either point upwards or are "sphered".  https://dyndolod.info/Help/Ultra-Tree-LOD#Internal-Billboards-and-External-Billboards. The included billboards used by ultra tree LOD also set the soft lighting flag and 3rd texture.

If CS makes significant changes to how double sided, soft, rim, back light are rendered in the game for PBR, I would appreciate a pointer to the shader file/lines.

We can certainly add options to the OpenGL shader like flipping vectors for diffuse rendering. At some point I might add a simple poor man version of a PBR shader if I ever find the time.

In any case, normals/tangents/bitangents vectors being (unintentionally?) changed is the reason for the lighting looking strange.

[Dmail]

Switched Complex Parallax for PBR Textures, but now DynDOLOD freezes while generating textures. There's no log for me to post, because I can't find one update (all I have is from previous runs). Task Manager shows "Taking Your First Born" with 0% CPU Usage but consuming memory.

Edited April 17 by Dmail

[Dmail]

I can't edit the original post anymore, but here a screenshot of my third attempt. https://i.imgur.com/VAdQryh.png

[z929669]

  On 4/17/2025 at 10:00 PM, Dmail said:

I can't edit the original post anymore, but here a screenshot of my third attempt. https://i.imgur.com/VAdQryh.png

Expand  

Set ` realtimelog=1 ` at the end of your DynDOLOD_SSE.ini to yield an uploadable log of what you are posting about.

[sheson]

  On 4/17/2025 at 9:03 PM, Dmail said:

Switched Complex Parallax for PBR Textures, but now DynDOLOD freezes while generating textures. There's no log for me to post, because I can't find one update (all I have is from previous runs). Task Manager shows "Taking Your First Born" with 0% CPU Usage but consuming memory.

Expand  

https://dyndolod.info/Generation-Instructions#Prerequisites:
In case ParallaxGen is used, run it before TexGen and DynDOLOD, as they will use information from its ParallaxGen_Diff.json file in the data folder to properly match certain LOD models. ParallaxGen output should overwrite the full models included in DynDOLOD Resources. Leave the default setting of ParallaxGen to ignore meshes in ..\LOD\.. folder. See Community-Shaders - PBR for more.

See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Copy-and-Paste-Text and https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs how to enable the realtime log.

See answers for https://dyndolod.info/FAQ#TexGen-DynDOLOD-stuck-while-creating-textures

[izzybinbizzy]

Hello sheson, 

I'm using the new test build of texgen that was released in this forum and got this bug 

Error: OpenGL: invalid value for textures\landscape\frozenmarshice01.dds.

Oddly enough, it didn't generate any new logs from what i can see, my texgenlog.sse is still from my previous generation so i just copied from the screen if you need anything else lmk. This doesn't happen with the nexus version of dyndolod. https://paste.ee/p/BAvKe0tu

For the record it's not just that file either, ran again and got this error and ctd.

OpenGL: invalid value for textures\pbr\landscape\reachmossyrocks01_n.dds

 

plugins.txtFetching info... loadorder.txtFetching info...

Edited April 18 by izzybinbizzy

[sheson]

  On 4/18/2025 at 1:56 PM, izzybinbizzy said:

Hello sheson, 

I'm using the new test build of texgen that was released in this forum and got this bug 

[Window Title]
TexGen

[Main Instruction]
Error: OpenGL: invalid value for textures\landscape\frozenmarshice01.dds.

[Content]

Click on this link for additional explanations and help for this message

Clean install the latest recommended/WHQL (not optional and not beta) graphics drivers only without any bloatware.

If the issue persists, posts a problem report on the official DynDOLOD support forum.

[OK] [Exit TexGen]

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

Oddly enough, it didn't generate any new logs from what i can see, my texgenlog.sse is still from my previous generation so i just copied from the screen if you need anything else lmk. This doesn't happen with the nexus version of dyndolod. https://paste.ee/p/BAvKe0tu

 

plugins.txt 49.91 kB · 0 downloads loadorder.txt 50.62 kB · 0 downloads

Expand  

https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs
..\DynDOLOD\bugreport.txt - if it exists
The log and debug log are saved when the program shuts down. Do not interrupt the shut down process so it can write the log files. While the new log is appended to older logs, the debug log is replaced every time. Keep a copy somewhere else for future references if required.

Close TexGen so it can save the logs and upload them and the bugreport.txt if it exists.

[izzybinbizzy]

TexGen_SSE_log.txtFetching info...

TexGen_SSE_Debug_log.7zFetching info...

And this is from my second run, no bugreport.txt

TexGen_SSE_Debug_log.7zFetching info...

[sheson]

  On 4/18/2025 at 2:07 PM, izzybinbizzy said:

TexGen_SSE_log.txt 2.75 MB · 1 download

TexGen_SSE_Debug_log.7z 1.35 MB · 1 download

And this is from my second run, no bugreport.txt

TexGen_SSE_Debug_log.7z 1.46 MB · 1 download

Expand  

Edit C:\Games\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.ini. Add these settings under [TexGen]
GLDebug=1
RenderSingle=1
StitchThreads=1

Delete old logs. Run. Upload new logs.

[izzybinbizzy]

  On 4/18/2025 at 6:28 PM, sheson said:

Edit C:\Games\Modding\Tools\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.ini. Add these settings under [TexGen]
GLDebug=1
RenderSingle=1
StitchThreads=1

Delete old logs. Run. Upload new logs.

Expand  

Okay sorry I’m unable to right now when I get off work I will upload 

[izzybinbizzy]

Idk if this was intended but it did run through to completion this time. Apologies it took so long busy day today...anyways hope this helps.

TexGen_SSE_log.7zFetching info...

[sheson]

  On 4/19/2025 at 1:49 AM, izzybinbizzy said:

Idk if this was intended but it did run through to completion this time. Apologies it took so long busy day today...anyways hope this helps.

TexGen_SSE_log.7z 1.71 MB · 1 download

Expand  

Well yes. You can use the output and continue as usual.

if time permits, could you run with this test version https://mega.nz/file/9QRCWKhT#Oa7KmQjKNXkjPIZd_wWDQv2uYPkP0Rvjx5reKquJJQI with the RenderSingle=0 and StitchThreads=0 (or the settings removed) and just GLDebug=1 and upload the new log and debug? It would still expected to fail, it is about gathering additional information.

[izzybinbizzy]

TexGen_SSE_Debug_log.7zFetching info...

 

Apologies again long day. No crash again. 

Edited April 19 by izzybinbizzy