DynDOLOD 3.00 Alpha 196

[Meridiano]

6 hours ago, sheson said:

1. This will be fixed properly in the next version. Until then you could add a mesh mask rule for whmarket01lod02.nif and set it to use the full model for the object LOD levels 4, 8, 16.

2. windhelmbridge_lod_2.nif is the vanilla LOD model using the vanilla rendered object LOD texture. Add a mesh mask rule for windhelmbridge.nif and set LOD Level 16 to use the LOD model for Level1 in order to use the better LOD model I created so it is used for the map as well.

3. The LOD models define textures\landscape\snow01.dds, which means it should be using textures\lod\snow01lod.dds generated by TexGen, which should be on the object LOD texture atlas created by DynDOLOD. Basically just all the other object LOD models using that snow texture. If this is the only object using that snow texture looking like that, check the BTO and compare it to the other objects using the same snow texture.

1. Cool, thank you a lot.

2. Will try that.

3. Yes, it seems all my objects with landscape/snow01.dds are very bright. Too few of them, didn't notice, sorry for confusing. I know my snow textures are bright so I reduce snow LOD material color to 160;160;160 to match xLODGen output. This doesn't affect the real snow of course, this is expected, this is why my objects with snow01.dds are so bright. If I increase my snow LOD material color they match (and give me all objects blinding, huh). A question then, maybe I can tell TexGen "you know, my snow is bright, apply 0.X mult to its brightness please" somehow?

[sheson]

49 minutes ago, Meridiano said:

1. Cool, thank you a lot.

2. Will try that.

3. Yes, it seems all my objects with landscape/snow01.dds are very bright. Too few of them, didn't notice, sorry for confusing. I know my snow textures are bright so I reduce snow LOD material color to 160;160;160 to match xLODGen output. This doesn't affect the real snow of course, this is expected, this is why my objects with snow01.dds are so bright. If I increase my snow LOD material color they match (and give me all objects blinding, huh). A question then, maybe I can tell TexGen "you know, my snow is bright, apply 0.X mult to its brightness please" somehow?

Create a new text file in a (new) mod folder so it ends up in the game data folder like ..\Data\DynDOLOD\DynDOLOD_SSE_TexGen_noalpha_updateesm.txt

You can change "updateesm" in the filename to any plugin filename in the load order as long as it is not "skyrimesm", "dawnguard", "dragonborn", "wyrmstoothesp".
In case snow01.dds comes with a mod that has a plugin, use its filename.

Add these 4 lines:

0	1	1	1	textures\landscape\snow01.dds	0.5	0.5	0	0	textures\lod\snow01lod.dds	1	1
0	1	1	1	textures\landscape\snow01.dds	0.5	0.5	0.5	0	textures\lod\snow01lod.dds	1	1
0	1	1	1	textures\landscape\snow01.dds	0.5	0.5	0	0.5	textures\lod\snow01lod.dds	1	1
0	1	1	1	textures\landscape\snow01.dds	0.5	0.5	0.5	0.5	textures\lod\snow01lod.dds	1	1

The first 0 in each line has the same function as the tree LOD brightness setting, e.g. set it to -10 or -20 for all rows to create a darker version of the LOD texture whenever TexGen runs.

See https://dyndolod.info/Help/TexGen-Configuration#Stitched-Object-LOD-Textures and https://dyndolod.info/Mod-Authors#How-to-add-LOD-textures-creation-rules-to-TexGen for more details.

[Meridiano]

16 minutes ago, sheson said:

See https://dyndolod.info/Help/TexGen-Configuration#Stitched-Object-LOD-Textures and https://dyndolod.info/Mod-Authors#How-to-add-LOD-textures-creation-rules-to-TexGen for more details.

Thank you again. Time to play with values!

[DoubleYou]

TexGen for Fallout 4 appears to not be reading BC5 ATI2 correctly. For this test case to reproduce, I used my Make Like a Tree with the no leaves option, which has BC5 ATI2 normals and speculars. Logs: https://mega.nz/file/INZwmLyI#9nJ6qYcHYgXcCAym6ATAMkusuFa-_2mxZJbfXF7cjGs

The resultant normal and specular lod textures are bugged (Note that the BastedForestTrunksLOD texture is vanilla BC5U in both of these cases):

Resaving the normals and speculars as BC5U instead of ATI2 allowed TexGen to process it correctly. Logs: https://mega.nz/file/hNRCTJZC#dwMRdhqZf_7b6JpG2T93YpIgf2Y1WPXofowIXUAPRqs

[sheson]

6 hours ago, DoubleYou said:

TexGen for Fallout 4 appears to not be reading BC5 ATI2 correctly. For this test case to reproduce, I used my Make Like a Tree with the no leaves option, which has BC5 ATI2 normals and speculars. Logs: https://mega.nz/file/INZwmLyI#9nJ6qYcHYgXcCAym6ATAMkusuFa-_2mxZJbfXF7cjGs

The resultant normal and specular lod textures are bugged (Note that the BastedForestTrunksLOD texture is vanilla BC5U in both of these cases):

Resaving the normals and speculars as BC5U instead of ATI2 allowed TexGen to process it correctly. Logs: https://mega.nz/file/hNRCTJZC#dwMRdhqZf_7b6JpG2T93YpIgf2Y1WPXofowIXUAPRqs

Check and confirm that the test version from the linked post works as expected https://stepmodifications.org/forum/topic/20153-error-opengl-framebuffer-objects-unsupported/page/2/#findComment-282545

[mostwanted11]

Tree lods are extremely dark, namely Treepineforest05 and 04, and only those. I modified the leaves texture to be desaturated on the pine forest ones and they work fine, nothing dark or whatever. But the dead ones seem to be weird when the lod is generated. https://imgur.com/a/SykNhwt  https://ufile.io/h0fmpkqw

In fact, any modifications to the file causes the lods to be dark.. So is it an issue with how I'm saving it? I'm saving it with PS + nvidia texture tools with mipmap scale 80 to match the alpha node of the mesh which is 80. Or is it an issue with the mesh? Can I solve it somehow myself?

Edited January 16 by mostwanted11

[z929669]

6 hours ago, mostwanted11 said:

Tree lods are extremely dark, namely Treepineforest05 and 04, and only those. I modified the leaves texture to be desaturated on the pine forest ones and they work fine, nothing dark or whatever. But the dead ones seem to be weird when the lod is generated. https://imgur.com/a/SykNhwt  https://ufile.io/h0fmpkqw

In fact, any modifications to the file causes the lods to be dark.. So is it an issue with how I'm saving it? I'm saving it with PS + nvidia texture tools with mipmap scale 80 to match the alpha node of the mesh which is 80. Or is it an issue with the mesh? Can I solve it somehow myself?

Generally, these are the settings you should use for most diffuse DDS textures when resaving (when the alpha is 'correct' and as the mod author intended).

 

Note that for foliage in particular, you need to scale the alpha for mipmap coverage. DynDOLOD should already do this automatically unless 'usemipmaps' is in the NIF branch shape name. In that case, the original mipmaps of the texture are used. Again, this shape string should be used only when the texture mipmap alpha is scaled correctly, which sometimes isn't the case, which is why DonDOLOD does it by default.

By matching the threshold to the NIF NiAlphaProperty, you are probably capturing the (black) background in your mipmaps. Scale using 127 or 128 as a starting point always. Then test the result and add/subtract 16 to fine tune.

[mostwanted11]

42 minutes ago, z929669 said:

Generally, these are the settings you should use for most diffuse DDS textures when resaving (when the alpha is 'correct' and as the mod author intended).

 

Note that for foliage in particular, you need to scale the alpha for mipmap coverage. DynDOLOD should already do this automatically unless 'usemipmaps' is in the NIF branch shape name. In that case, the original mipmaps of the texture are used. Again, this shape string should be used only when the texture mipmap alpha is scaled correctly, which sometimes isn't the case, which is why DonDOLOD does it by default.

By matching the threshold to the NIF NiAlphaProperty, you are probably capturing the (black) background in your mipmaps. Scale using 127 or 128 as a starting point always. Then test the result and add/subtract 16 to fine tune.

Thanks for the reply, i will try with different numbers but I only settled with 80 because otherwise the trees would appear skinny from afar which bothered me a lot so I figured scaling it to the alpha property is the way to go since it resolved that issue.. Can I somehow land on a number that somehow mitigates BOTH issues? Also my nvidia tools looks a bit different than yours, am I using an outdated version and will that change anything?

Edited January 17 by mostwanted11

[z929669]

5 minutes ago, mostwanted11 said:

Thanks for the reply, i will try with different numbers but I only settled with 80 because otherwise the trees would appear skinny from afar which bothered me a lot so I figured scaling it to the alpha property is the way to go since it resolved that issue.. Can I somehow land on a number that somehow mitigates BOTH issues?

PineAtlas.dds obviously works properly until you resave it, so you are either changing the alpha or saving it incorrectly.

Are you ticking Cutout Alpha when resaving?

[mostwanted11]

Just now, z929669 said:

PineAtlas.dds obviously works properly until you resave it, so you are either changing the alpha or saving it incorrectly.

Are you ticking Cutout Alpha when resaving?

I wasn't doing that before, and the issue of skinny trees was resolved (even with my edited texture) when I was using scale 80. I will try to use cutout alpha and let you know. Thanks for your help.

[z929669]

Just now, mostwanted11 said:

I wasn't doing that before, and the issue of skinny trees was resolved (even with my edited texture) when I was using scale 80. I will try to use cutout alpha and let you know. Thanks for your help.

No, don't use cutout alpha. I figured you were using it. Try replicating all the settings I posted.

Iteratively subtract 16 from the threshold and retest if trees are too skinny.

[mostwanted11]

37 minutes ago, z929669 said:

No, don't use cutout alpha. I figured you were using it. Try replicating all the settings I posted.

Iteratively subtract 16 from the threshold and retest if trees are too skinny.

Ok I tried 128, 112, 96 and 64. Only 64 had no skinny trees issue but obviously it had the lod issue. Attached a picture of the settings I used because my texture tools is a bit different than yours idk why. Idk what am I doing wrong :/ The skinny trees issue happens with any Pineatlas replacer I've found on the nexus as well. My current workaround is that since I'm modifying only the green pines and the dead ones not the center part of Pineatlas is that I have the trees with lod issues use a basic PineAtlas and the ones I'm modifying use the modified PineAtlas.

[sheson]

8 hours ago, mostwanted11 said:

Tree lods are extremely dark, namely Treepineforest05 and 04, and only those. I modified the leaves texture to be desaturated on the pine forest ones and they work fine, nothing dark or whatever. But the dead ones seem to be weird when the lod is generated. https://imgur.com/a/SykNhwt  https://ufile.io/h0fmpkqw

In fact, any modifications to the file causes the lods to be dark.. So is it an issue with how I'm saving it? I'm saving it with PS + nvidia texture tools with mipmap scale 80 to match the alpha node of the mesh which is 80. Or is it an issue with the mesh? Can I solve it somehow myself?

Also upload the DynDOLOD and TexGen log.

What is the tree mod? Why are you editing full textures to begin with? Just edit the alpha threshold of the full/LOD model instead.
When editing textures, make sure the transparent parts - especially adjacent to visible pixels - have matching color and brightness. Make sure to use an alpha channel.

[mostwanted11]

1 minute ago, sheson said:

Also upload the DynDOLOD and TexGen log.

What is the tree mod? Why are you editing full textures to begin with? Make sure the transparent parts especially adjacent to visible pixels have matching color and brightness. Make sure to use an alpha channel.

Currently generating dyndolod so I won't be able to provide the files you ask but it's Happy Little Trees and I'm editing the texture because its colors are way off with my setup. I am recoloring the nearby area as a whole because I think those include mipmaps. What's an alpha channel? you mean scaling Alpha or am I misunderstanding? Sorry not knowledgeable on the topic

[sheson]

27 minutes ago, mostwanted11 said:

Currently generating dyndolod so I won't be able to provide the files you ask but it's Happy Little Trees and I'm editing the texture because its colors are way off with my setup. I am recoloring the nearby area as a whole because I think those include mipmaps. What's an alpha channel? you mean scaling Alpha or am I misunderstanding? Sorry not knowledgeable on the topic

OK, in this case TexGen is irrelevant, since the 3D tree LOD model uses the full texture.

A texture is an image that can have up to 4 channels, red, green, blue and alpha. Depending on the texture compression format or save options, the alpha channel can work the same as the color channels (from fully transparent to fully opaque) or a simply be transparency on/off. A "full" alpha channel is preferred for everything to work properly.

Read intro of https://dyndolod.info/Help/3D-Tree-LOD-Model.

If you only wanted to change thinness/thickness of the full or 3D tree LOD models, then you can change the NiAlphaProperty Threshold in the NIFs without changing textures. However remember that editing the full model NIF means its CRC32 changes, so you will need to update the CRC32 part of the filename of 3D tree LOD model accordingly. The bold part of treepineforestdead05_7B6546E1passthru_lod.nif

The mipmaps of the full texture do not matter in this context, as the 3D tree LOD models does not set "usemipmaps", the mipmaps of the object LOD texture atlas used by the LOD will be generated. If you want to use the 3D tree LOD to use the mipmaps of the full texture add that to the shape names of 3D tree LOD NIF. "TreePineForest05_1:1 Crown" to "TreePineForest05_1:1 Crown UseMipMaps" See https://dyndolod.info/Help/3D-Tree-LOD-Model#Shape-Names

Now, the problem that only a particular branch is too dark compared to the other ones from the the same texture can be because of the branches being surrounded by to dark pixels. Even if they are transparent, their color information might be used for sampling lower resolutions/mipmaps.

Compare the fill around the "dead" branch in the middle of DeadAtlas.dds left, PineAtlas.dds right:

You could try filling the almost black background fill around the dead branch in the middle with a more appropriate color that matches the actual branch more closely similar to the other branches. If the background were complete black, DynDOLOD would will the area automatically with the average color of the entire texture, which in case of "atlas" textures like this could be off as well. This applies to when the texture is added to the object texture atlas.

See https://dyndolod.info/Updating
In case a new mod only updates textures ...  Start DynDOLOD in expert mode, select all or only the affected worldspaces and click the Rebuild Atlas button to update the atlas textures. Then install the DynDOLOD output, overwriting the existing DynDOLOD output.