DynDOLOD 3.00 Alpha 182

[sheson]

57 minutes ago, Thaumatarge said:

For some weird unexplicable reason, Solstheim is all buggy when using Seasons of Skyrim, and the issue is related to LODs. Most of the Tree LODs don't work (Some do, especially the snapped trees, I assume this is because they are objects, not trees), and a lot of the various buildings don't want to have LOD either (Miraak's Temple, or the Bulwark, all of the Stones or even the wreck on the south west side of the island, and many other ones, though not the imperial buildings in Raven Rock).

Disabling Seasons of Skyrim seems to fix the issue, making me suspect that it may be an issue with that specific plugin, but despite this, LODs work everywhere else even with the SoS mod enabled (Blackreach, Falmer Valley, Soul Cairn, Apocrypha, and so on all work regardless of the plugins).

I do not know if this is an issue with DynDOLOD failing to generate/load seasonal LODs for Solstheim specifically, or Seasons of Skyrim failing to load/swap them, or the mods failing to fall back on default non-seasonal LODs.

I will be happy to provide any specific Logs or config files as needed, because I do not know what exactly to provide, or if this is even an issue with DynDOLOD. I am using DynDOLOD Resources Alpha 21 and DynDOLOD Alpha 74 and Seasons of Skyrim 1.6.1 (plus some additional things that haven't changed anything when testing).

Read the first post which log and debug log to upload.

Also upload the po3_SeasonsOfSkyrim.ini and every season swap INI.

[Thaumatarge]

16 minutes ago, sheson said:

Read the first post which log and debug log to upload.

Also upload the po3_SeasonsOfSkyrim.ini and every season swap INI.

https://ufile.io/vee505qj I have uploaded all requested files in a ZIP package. 

[sheson]

22 minutes ago, Thaumatarge said:

https://ufile.io/vee505qj I have uploaded all requested files in a ZIP package. 

The DynDOLOD_SSE_log.txt shows that seasons have only been generated for Tamriel.

Make sure that all desired worldspaces have been selected for season generation, e.g. they shows the [Seasons] in the worldspaces list of the advanced options. Doubleclick a worldspace to change toggle it.

See https://dyndolod.info/Help/Seasons.

If there are season object/tree LOD that po3_SeasonsOfSkyrim.dll can switch to they must be left overs from another generation. You probably want to remove those files form the load order.

[Thaumatarge]

9 minutes ago, sheson said:

The DynDOLOD_SSE_log.txt shows that seasons have only been generated for Tamriel.

Make sure to that all desired worldspaces have been selected for season generation, e.g. they shows the [Seasons] in the worldspaces list of the advanced options. Doubleclick a worldspace to change toggle it.

See https://dyndolod.info/Help/Seasons.

Oh! I completely missed that sentence when I was reading that!

[Phlunder]

Hey sheson, thanks for updating so fast to include the new resources for Enderal! They work great!

If you remember, quite a while ago I posted some pics of visual artifacts when using ultra trees in Enderal. You were right back then, it was the fault of some of the custom tree models in Enderal. I was finally able to fix these meshes, so they don't show visual artifacts when fading in from object LOD. The results are great, and I'm happy to finally be able to use ultra trees (Billboard4) in Enderal:

The only thing that still gives me headaches are the tropical trees. There is now great blending for all tree types, but for some reason these are unnaturally glowing. I can't figure out why. I included a shot where you can see other tree LODs that look fine from the same view point. ENB is not used in the shots, and I also tried other weathers (fw 81a) but its always the same result:

 

An example reference would be 11F62D. Logs are here: https://drive.google.com/file/d/1iavFfJ24R-tDT1hqwuxLolyApltIvdPi/view?usp=sharing

Edited February 23, 2022 by Phlunder

[xddfan]

Hi, texgen 3.0 Alpha 74 always crashed when creating texture of wrbuildingslod01

Error: OpenGL: Out of memory

 TexGen SSE log

The debug log is over 3MB, pastebin didnt allow me to paste it. So I put it here. 

[sheson]

8 hours ago, Phlunder said:

Hey sheson, thanks for updating so fast to include the new resources for Enderal! They work great!

If you remember, quite a while ago I posted some pics of visual artifacts when using ultra trees in Enderal. You were right back then, it was the fault of some of the custom tree models in Enderal. I was finally able to fix these meshes, so they don't show visual artifacts when fading in from object LOD. The results are great, and I'm happy to finally be able to use ultra trees (Billboard4) in Enderal:

 

The only thing that still gives me headaches are the tropical trees. There is now great blending for all tree types, but for some reason these are unnaturally glowing. I can't figure out why. I included a shot where you can see other tree LODs that look fine from the same view point. ENB is not used in the shots, and I also tried other weathers (fw 81a) but its always the same result:

 

An example reference would be 11F62D. Logs are here: https://drive.google.com/file/d/1iavFfJ24R-tDT1hqwuxLolyApltIvdPi/view?usp=sharing

Check the normal map of the billboards. Maybe flat due to files not found error.

[sheson]

2 hours ago, xddfan said:

Hi, texgen 3.0 Alpha 74 always crashed when creating texture of wrbuildingslod01

Error: OpenGL: Out of memory

Use a file service for large logs as explained on the first post.

The textures\architecture\whiterun\WRstonebase02.dds has a resolution of 16384 x 8192
Use full textures with more sane resolutions.

Close any other program that uses video memory.

Edit ..\DynDOLOD\Edit Scripts\DynDOLOD\TexGen_SSE.INI and set MaxTextureSize=8192 and if that still doesn't work , set it to 4096

[Phlunder]

31 minutes ago, sheson said:

Check the normal map of the billboards. Maybe flat due to files not found error.

I've seen these errors, unfortunately Enderal has a few of those. I will look into covering those missing normals. I checked the normal map atlas for the tree LOD, and the only thing that stands out is that the trunks of some of the trees have flat normals, the crown is always covered. And two tree types not shown in the screenshots have flat normals too. Here's the output atlas, if it helps: https://drive.google.com/file/d/1EaqpfUik1h8DTPHO3tuy1ap7nF9YG78i/view?usp=sharing 

I thought its maybe something with those trees brightness too, but then again, there are other trees in the game (and in vanilla Skyrim) that are brighter, like snow pines, and they don't have this issue. They are also seen in the screenshot. Near the glaciers.

Edited February 23, 2022 by Phlunder

[sheson]

20 minutes ago, Phlunder said:

I've seen these errors, unfortunately Enderal has a few of those. I will look into covering those missing normals. I checked the normal map for the trees, and the only thing that stands out is that the trunks of some of the trees have flat normals, the crown is always covered. And two tree types not shown in the screenshots have flat normals too. Here's the output atlas, if it helps: https://drive.google.com/file/d/1EaqpfUik1h8DTPHO3tuy1ap7nF9YG78i/view?usp=sharing 

I thought its maybe something with those trees brightness too, but then again, there are other trees in the game (and in vanilla Skyrim) that are brighter, like snow pines, and they don't have this issue. They are also seen in the screenshot. Near the glaciers.

Am I supposed to find the tree(s) on the texture atlas among the hundreds of textures?

Check the billboards generated by TexGen for those trees.
Let me know the base record form ID of those trees.

What the screenshots do not show is how bright or dark the full models are without shadows. I mean, maybe the same trees are in the foreground loaded, but without knowing which tree base record this actually is...

[Phlunder]

13 minutes ago, sheson said:

Am I supposed to find the tree(s) on the texture atlas among the hundreds of textures?

Check the billboards generated by TexGen for those trees.
Let me know the base record form ID of those trees.

What the screenshots do not show is how bright or dark the full models are without shadows. I mean, maybe the same trees are in the foreground loaded, but without knowing which tree base record this actually is...

Sorry, atlas was a bad idea without further info. I also tried several times of day, and yes the trees in the foreground are loaded and of the same type of course, to show the difference. Here are the base IDs, I hope I got them all:

88025
8671B
86726
8671F
86724
8813F
88102

Some better comparisons. I picked a time of day were the issue is most visible. Seems like backlight influence, though Billboard4 is used? The 3rd shot shows such a tropical tree next to a vanilla tree billboard:

  

 

[sheson]

40 minutes ago, Phlunder said:

Sorry, atlas was a bad idea without further info. I also tried several times of day, and yes the trees in the foreground are loaded and of the same type of course, to show the difference. Here are the base IDs, I hope I got them all:

88025
8671B
86726
8671F
86724
8813F
88102

Some better comparisons. I picked a time of day were the issue is most visible. Seems like backlight influence, though Billboard4 is used? The 3rd shot shows such a tropical tree next to a vanilla tree billboard:

Can you upload the LOD Level 4 BTO for that area?

[Phlunder]

52 minutes ago, sheson said:

Can you upload the LOD Level 4 BTO for that area?

Here is the Level 4 BTO file for that area: https://drive.google.com/file/d/16CILX3YKEJiqzqEPEwVeYkGyBO9BwGek/view?usp=sharing 

Indeed, these tree LOD meshes look different even in NifSkope:

Edited February 23, 2022 by Phlunder

[sheson]

34 minutes ago, Phlunder said:

Here is the Level 4 BTO file for that area: https://drive.google.com/file/d/16CILX3YKEJiqzqEPEwVeYkGyBO9BwGek/view?usp=sharing 

Indeed, these tree LOD meshes look different even in NifSkope:

Those palms do not have "tree" anywhere in their path so the "tree" mesh mask rule does not apply. Which means the last "/" rule applies which falls back to Billboard1 by default.

For now just copy the "tree" mesh rule to "tropical" (as not all of them are palms either).

I will fix this this in the next alpha version by having the "tree" mesh rule apply to all TREE base records as well in addition to the mesh mask . Via a new flag.

[Phlunder]

22 minutes ago, sheson said:

Those palms do not have "tree" anywhere in their path so the "tree" mesh mask rule does not apply. Which means the last "/" rule applies which falls back to Billboard1 by default.

For now just copy the "tree" mesh rule to "tropical" (as not all of them are palms either).

I will fix this this in the next alpha version by having the "tree" mesh rule apply to all TREE base records as well in addition to the mesh mask . Via a new flag.

Ahh, that makes sense. Adding the mesh rule fixed it indeed. Thanks for looking into it!