DynDOLOD 3.00 Alpha 180

[Mousetick]

1 hour ago, sheson said:

https://dyndolod.info/Help/Advanced-Mode#Object-LOD
Max tile size LOD sets the maximum resolution a single object LOD texture can occupy on the object LOD texture atlas. Typically set to match the vertical screen resolution, e.g 1024 for 1080p/1440p, 2048 for 2160p etc.
Max tile size full sets the maximum resolution a single full texture can occupy on the object LOD texture atlas. Typically set to 1/4 of the vertical screen resolution, e.g. 256 for 1080p/1440p, 512 for 2160p etc.

In the case of the downsampled and alpha threshold-adjusted version of treepineforestbranchcomp[snow[l]].dds generated by DynDOLOD for the 3D tree LOD crowns, is this texture considered "a single object LOD texture" or "a single full texture" for adding it to the atlas?

1 hour ago, sheson said:

Similar results can be achieved if all you want is to make textures bit darker or brighter, however TexGen settings only apply to the textures it generates.

Again, the brightness setting in DynDOLOD is the same as from xLODGen. It exists since years before there was TexGen. It applies to all installed billboards.

So my takeaway from all this is that, since 3rd party tree LOD billboards should never be used and tree LOD billboards should always be generated with TexGen, there is no reason to ever use DynDOLOD's brightness setting.

Thanks.

[sheson]

13 minutes ago, Mousetick said:

In the case of the downsampled and alpha threshold-adjusted version of treepineforestbranchcomp[snow[l]].dds generated by DynDOLOD for the 3D tree LOD crowns, is this texture considered "a single object LOD texture" or "a single full texture" for adding it to the atlas?

treepineforestbranchcomp[snow[l]].dds is obviously not a LOD texture since it doesn't have LOD in the filename.

[Mousetick]

10 hours ago, sheson said:

treepineforestbranchcomp[snow[l]].dds is obviously not a LOD texture since it doesn't have LOD in the filename.

Ok. Out of curiosity, I tried Max tile size full = 512 which theoretically is overkill for my vertical resolution (1200). Even though it expectedly resulted in more details in both shape and color in the atlas, it didn't make any perceptible difference in-game (too far to see).

I've increased the alpha threshold up to 224, from the initial 112. This makes the 3D tree LODs almost virtually indistinguishable in-game shape-wise from the full models with regards to skinniness, unless I really focus on them. So I'm pretty happy about the improvement.

I'm now preoccupied with the overall/dominant color of the downscaled treepineforestbranchcomp[snow[l]].dds in the atlas. It seems "off" compared to the full texture, it makes the 3D tree LOD branches look "solid/flat" and "blocky" in-game.

May I ask which resampling algorithm is used to generate the atlas texture?

Comparison: original full 4K | paint.net Bicubic downscale to 256 | DynDOLOD downscale to 256 + alpha filtering

Initially I thought DynDOLOD's version had a "brownish" bias (too much red), but the tints appear to be actually correct. It seems to me the actual issue is that the DynDOLOD version has very little gradation in saturation. Every pixel looks to be max saturated.

RGB Perceptual Histogram: paint.net Bicubic downscale to 256 | DynDOLOD downscale to 256 + alpha filtering

Thanks in advance for your input.

[sheson]

9 hours ago, Mousetick said:

May I ask which resampling algorithm is used to generate the atlas texture?

Lanczos in "myfilter" ..\DynDOLOD\Edit Scripts\DynDOLOD\Shaders\stitched.frag

If you want to replicate/compare the mipmap generation, also change the alpha of the largest resolution and then of every mipmap that is used.

https://dyndolod.info/Help/3D-Tree-LOD-Model
Note that by default mipmaps of textures that are added to the tree LOD or object LOD texture atlas are ignored and instead are generated from the largest resolution with an alpha-to-coverage algorithm so that small details do not fade into full transparency the further away they are. To use the mipmaps of the original texture defined by the LOD model, add the term UseMipMaps to the BSTriShape/NiTriShape name. This should preferably be done for all LOD models using this texture. Use an unique filename for such textures, so there are no problems with other mods modifying the same vanilla filenames.

[Mousetick]

5 hours ago, sheson said:

If you want to replicate/compare the mipmap generation, also change the alpha of the largest resolution and then of every mipmap that is used.

I didn't understand, sorry. Why would I need to change the alpha of the original texture, and what would I need to change it to? I don't have the tools to view/compare mipmaps, so this may be moot anyway.

5 hours ago, sheson said:

Note that by default mipmaps of textures that are added to the tree LOD or object LOD texture atlas are ignored and instead are generated from the largest resolution with an alpha-to-coverage algorithm so that small details do not fade into full transparency the further away they are. To use the mipmaps of the original texture defined by the LOD model, add the term UseMipMaps to the BSTriShape/NiTriShape name. This should preferably be done for all LOD models using this texture. Use an unique filename for such textures, so there are no problems with other mods modifying the same vanilla filenames.

I'd read that before and thought it looked important and relevant to my situation, but most of it flew right over my head. I think it makes more sense now. So the full-on/full-off pixels in DynDOLOD's generated atlas texture are the results of alpha-to-coverage?

The mipmaps of the original texture look ok to me in-game at roughly the same viewing distance as LOD Level 4: the branches of the full models are opaque and don't look "decimated". But perhaps the game itself uses alpha-to-coverage for compositing vegetation at small resolution? If that's the case, I'm screwed.

Let me give the UseMipMaps a try. Back to NifSkope...

So for example, in treepineforest01passthru_lod.nif, I would add UseMipMaps to the crown BSTriShape name:

TreePineForest01_1:1 ScaleXY Crown UseMipMaps

Does it look right?

Thanks.

[sheson]

25 minutes ago, Mousetick said:

I didn't understand, sorry. Why would I need to change the alpha of the original texture, and what would I need to change it to? I don't have the tools to view/compare mipmaps, so this may be moot anyway.

You are comparing a resize without alpha change to a resize with alpha change.

25 minutes ago, Mousetick said:

I'd read that before and thought it looked important and relevant to my situation, but most of it flew right over my head. I think it makes more sense now. So the full-on/full-off pixels in DynDOLOD's generated atlas texture are the results of alpha-to-coverage?

The mipmaps of the original texture look ok to me in-game at roughly the same viewing distance as LOD Level 4: the branches of the full models are opaque and don't look "decimated". But perhaps the game itself uses alpha-to-coverage for compositing vegetation at small resolution? If that's the case, I'm screwed.

https://dyndolod.info/Help/3D-Tree-LOD-Model
Note that LOD only has binary alpha with a fixed threshold of 128.

It does not really matter how nice an alpha channel looks when looking at a texture in program. In LOD a pixel either shows 100% or not.

If mipmaps do not fade into full transparency it is because they have been generated with alpha-to-coverage.

25 minutes ago, Mousetick said:

So for example, in treepineforest01passthru_lod.nif, I would add UseMipMaps to the crown BSTriShape name:

TreePineForest01_1:1 ScaleXY Crown UseMipMaps

Does it look right?

Yes, you added the term UseMipMaps to a shape name as explained by the instructions.

[IskanderStep]

On 8/27/2023 at 12:04 AM, IskanderStep said:

Hi, i downloaded the testversion, made a clean save, generated the whole bunch etc.

Whatever you did, it works !

The bridge is there and the ...Glow.Lod.. is gone.

 Thx !

If you need further information etc. just let me know.

Iskander

 

Hi,

i am really sorry to bring this topic up again, but the bridge in whiterun  is gone again  . 

The ingame datetime: Turdas 1850 0611 4E202

I hope you remember what you did to fix it in the first place and have an idea why the fix was not as complete as we both thought.

I assume it had something to do with "seasons" or "simplicity of snow" ?

 

I did'nt do screens etc. as i did that in the first place.

If i can help you nonethless, please let me know.

 

With best regards 

Iskander

 

 

[Mousetick]

9 minutes ago, sheson said:

It does not really matter how nice an alpha channel looks when looking at a texture in program. In LOD a pixel either shows 100% or not.

Yes that's true and I agree. But since LOD uses binary alpha and we don't care about transparency, we can remove the alpha by compositing the texture with a solid background.

Before with Alpha > After compositing

Anything that is not white background is 100 alpha (full opaque). Background is 0 alpha (full transparent).

This can be combined with alpha threshold filtering, applied before compositing with the background.

The gradation in shades and saturation is retained.

[sheson]

30 minutes ago, Mousetick said:

Yes that's true and I agree. But since LOD uses binary alpha and we don't care about transparency, we can remove the alpha by compositing the texture with a solid background.

Before with Alpha > After compositing

Anything that is not white background is 100 alpha (full opaque). Background is 0 alpha (full transparent).

This can be combined with alpha threshold filtering, applied before compositing with the background.

The gradation in shades and saturation is retained.

You changed the color of not 100% opaque pixels to contain white. In the real world/game it does not work like that.
What you achieved is to create an image that looks similar to the alpha checkerboard background preview of the program.
Change the program to actually show the color of all pixels and the alpha channel as mask that can be turned off.
Look up premultiplied alpha and alpha blending. Maybe start with this https://developer.nvidia.com/content/alpha-blending-pre-or-not-pre

[Mousetick]

1 hour ago, Mousetick said:

To use the mipmaps of the original texture defined by the LOD model, add the term UseMipMaps to the BSTriShape/NiTriShape name. This should preferably be done for all LOD models using this texture.

'preferably' or 'absolutely'? I have edited all 5 treepineforest*passthru_lod.nif meshes but I know there is at least another one which uses the same texture. I don't see any difference in-game. Is there a way to check in the log(s) that UseMipMaps is taken into account?

If this doesn't work out, I'll drop this and move on...

---

... to the last niggling "issue" before I reach tree LOD nirvana.

The lighting effect on the branches of the 3D tree LOD crown is very nice as a whole, but is there a way to "tone it down" a bit? It looks too bright to me.

I tried to counter-balance it by darkening the crowns with

; Vertexcolor multipliers for tree LOD models used in object LOD, see https://dyndolod.info/Help/Ultra-Tree-LOD
; CrownBrightness=1
CrownBrightness=0.75

but it's not the right approach, as it makes the snowy trees branches grey for example.

Sometimes the lighting clashes with full model trees in the foreground which are not illuminated as brightly. Also it seems to affect the color?

Thanks.

[sheson]

2 hours ago, Mousetick said:

'preferably' or 'absolutely'? I have edited all 5 treepineforest*passthru_lod.nif meshes but I know there is at least another one which uses the same texture. I don't see any difference in-game. Is there a way to check in the log(s) that UseMipMaps is taken into account?

If this doesn't work out, I'll drop this and move on...

If there is one or more NIF using that texture and not settings that, it might not work consistently. It would be best to copy the texture to a unique new filename and update the NIF to use that instead.
There is no dedicated debug log message but you can check for the absence of log messages like this:
[dynGenerateMipMaps] <Debug: Textures\landscape\trees\treepineforestbranchcomp.dds

2 hours ago, Mousetick said:

The lighting effect on the branches of the 3D tree LOD crown is very nice as a whole, but is there a way to "tone it down" a bit? It looks too bright to me.

I tried to counter-balance it by darkening the crowns with

; Vertexcolor multipliers for tree LOD models used in object LOD, see https://dyndolod.info/Help/Ultra-Tree-LOD
; CrownBrightness=1
CrownBrightness=0.75

but it's not the right approach, as it makes the snowy trees branches grey for example.

Sometimes the lighting clashes with full model trees in the foreground which are not illuminated as brightly. Also it seems to affect the color?

Thanks.

The 3D tree LOD models use 1:1 copies of the full models. Whatever you see are probably effects in the game.

If you want to change brightness of individual 3D tree LOD models, you could darken the full texture directly.

[Mousetick]

On 9/19/2023 at 7:46 PM, sheson said:

If there is one or more NIF using that texture and not settings that, it might not work consistently. It would be best to copy the texture to a unique new filename and update the NIF to use that instead.
There is no dedicated debug log message but you can check for the absence of log messages like this:
[dynGenerateMipMaps] <Debug: Textures\landscape\trees\treepineforestbranchcomp.dds

After many, many tries and goof-ups I finally managed to make it work. I was about to give up but it finally dawned on me (yes, I'm slow) that UseMipMaps must be the solution: if both the full models and 3d LOD models use the same mipmaps, they should look quasi-identical at roughly the same viewing distance.

Here are some results (CrownBrightness was reverted to 1 in DynDOLOD_SSE.ini):

• Baseline: Alpha threshold 224 without UseMipMaps
• Test: Alpha threshold 112 with UseMipMaps

Atlas Texture: Baseline > Test

This shows DynDOLOD's Lanczos filter and alpha-to-coverage do an excellent job compared to the full texture's mipmap, but somehow the mipmaps of the atlas texture end up very different, as seen in the next screenshots.

In-game mid-morning: Baseline > Test

In-game afternoon: Baseline > Test

This is beautiful, I'm so happy. Thank you very much for your assistance and for bearing with me.

Notes:

• I reverted the Alpha threshold to 112 for the UseMipMaps version, because with 224 the atlas texture and mipmaps were completely decimated, there was almost nothing left  I need to tweak the alpha threshold again to correct the lushiness of the 3D LOD models and match it with the full models.
• I tried to rename the textures paths and filenames in the 3D LOD models in order to make UseMipMaps work, but it didn't work as DynDOLOD requires the same paths and filenames in both the full and 3D LOD models. I didn't want to edit the vanilla meshes, so I made sure to add UseMipMaps to all the 3D LOD models that use treepineforestbranchcomp.dds (treepineforest*passthru_lod.nif + treepineforestdead*passthru_lod.nif).
• The branches of the 3D LOD models still look rather flat, but I understand this is due to the LOD's binary alpha. There's nothing that can be done.
• Suggestion for possible future usability improvement: Since the suitability of mipmaps for use by 3D LOD models is an intrinsic property of the full texture, and does not depend on the mesh, it would make sense to specify UseMipMaps separately for specific textures (e.g. in a config file) rather than in each 3D LOD mesh.

Thanks for reading.

[z929669]

3 hours ago, Mousetick said:

After many, many tries and goof-ups I finally managed to make it work. I was about to give up but it finally dawned on me (yes, I'm slow) that UseMipMaps must be the solution: if both the full models and 3d LOD models use the same mipmaps, they should look quasi-identical at roughly the same viewing distance.

Here are some results (CrownBrightness was reverted to 1 in DynDOLOD_SSE.ini):

• Baseline: Alpha threshold 224 without UseMipMaps
• Test: Alpha threshold 112 with UseMipMaps

Atlas Texture: Baseline > Test

This shows DynDOLOD's Lanczos filter and alpha-to-coverage do an excellent job compared to the full texture's mipmap, but somehow the mipmaps of the atlas texture end up very different, as seen in the next screenshots.

In-game mid-morning: Baseline > Test

In-game afternoon: Baseline > Test

This is beautiful, I'm so happy. Thank you very much for your assistance and for bearing with me.

Notes:

• I reverted the Alpha threshold to 112 for the UseMipMaps version, because with 224 the atlas texture and mipmaps were completely decimated, there was almost nothing left  I need to tweak the alpha threshold again to correct the lushiness of the 3D LOD models and match it with the full models.
• I tried to rename the textures paths and filenames in the 3D LOD models in order to make UseMipMaps work, but it didn't work as DynDOLOD requires the same paths and filenames in both the full and 3D LOD models. I didn't want to edit the vanilla meshes, so I made sure to add UseMipMaps to all the 3D LOD models that use treepineforestbranchcomp.dds (treepineforest*passthru_lod.nif + treepineforestdead*passthru_lod.nif).
• The branches of the 3D LOD models still look rather flat, but I understand this is due to the LOD's binary alpha. There's nothing that can be done.
• Suggestion for possible future usability improvement: Since the suitability of mipmaps for use by 3D LOD models is an intrinsic property of the full texture, and does not depend on the mesh, it would make sense to specify UseMipMaps separately for specific textures (e.g. in a config file) rather than in each 3D LOD mesh.

Thanks for reading.

Just to be clear, you are talking about TexGen_SSE.ini settings for UseMipMaps and TreeMSAlphaThreshold, correct?

If so, I'd like @sheson to confirm that these settings pertain to BOTH Level# and Billboard# DynDOLOD mesh textures. I had thought that these only pertained to Billboard# mesh textures.

Perhaps this discussion is about using UseMipMaps in the string name of the crown BsTriShape of the LOD models?

In that case, I want to confirm that the DynDOLOD treatment pertains to BOTH Level# and Billboard# DynDOLOD mesh textures, regardless.

Going slightly off topic from this discussion but on-topic for DynDOLOD: It would be extremely helpful if there were a handy reference for all NIF strings keywords (e.g., ShereNormals, UseMipMaps, etc.) and exactly the NIF node types to which they pertain (and I assume only the LOD models are considered by DynDOLOD and the full model strings have no bearing on LOD treatment). I know there are more, but we lack a comprehensive listing in the documentation AFAIK.

[Mousetick]

1 hour ago, z929669 said:

Just to be clear, you are talking about TexGen_SSE.ini settings for UseMipMaps and TreeMSAlphaThreshold, correct?

No, I'm talking about UseMipMaps in the name of the BSTriShape of the crown of the 3D tree LOD mesh, and about the Threshold value of the NiAlphaProperty of that same BSTriShape. The past discussion is solely about 3D tree LOD models and their use of full model textures, TexGen and billboards are not involved at all.

1 hour ago, z929669 said:

Perhaps this discussion is about using UseMipMaps in the string name of the crown BsTriShape of the LOD models?

Correct.

[sheson]

1 hour ago, z929669 said:

Just to be clear, you are talking about TexGen_SSE.ini settings for UseMipMaps and TreeMSAlphaThreshold, correct?

No. https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-148/?do=findComment&comment=274396

1 hour ago, z929669 said:

If so, I'd like @sheson to confirm that these settings pertain to BOTH Level# and Billboard# DynDOLOD mesh textures. I had thought that these only pertained to Billboard# mesh textures.

TexGen has nothing to do with object LOD level options of DynDOLOD. TexGen generates textures (and text files).
I have no idea what "mesh textures" means. Meshes are 3D models and textures are images.

The TexGen UseMipmaps INI setting does exactly what the explanations above it says it does:
; 1 = use mipmaps of full textures for rendering, 0 = don't use mipmaps
Since there is no condition/limitation mentioned it applies to all TexGen options that are rendered.

1 hour ago, z929669 said:

Perhaps this discussion is about using UseMipMaps in the string name of the crown BsTriShape of the LOD models?

Yes. https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-148/?do=findComment&comment=274396

1 hour ago, z929669 said:

In that case, I want to confirm that the DynDOLOD treatment pertains to BOTH Level# and Billboard# DynDOLOD mesh textures, regardless.

Billboard textures (that includes trunks) generated by TexGen do not have mipmaps, so they typically have to be generated by DynDOLOD when being added to a texture atlas regardless of any UseMipMaps being set in any LOD model.
Billboard meshes like ..\DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_flat_*_lod.nif define place holder textures, so adding UseMipMaps to them will not have any effects for any texture.

1 hour ago, z929669 said:

Going slightly off topic from this discussion but on-topic for DynDOLOD: It would be extremely helpful if there were a handy reference for all NIF strings keywords (e.g., ShereNormals, UseMipMaps, etc.) and exactly the NIF node types to which they pertain (and I assume only the LOD models are considered by DynDOLOD and the full model strings have no bearing on LOD treatment). I know there are more, but we lack a comprehensive listing in the documentation AFAIK.

https://dyndolod.info/Help/3D-Tree-LOD-Model#Shape-Names

Shape name = 3D Name https://ck.uesp.net/wiki/index.php?title=Model_Data
As explained by https://dyndolod.info/Help/3D-Tree-LOD-Model "... to the BSTriShape/NiTriShape name"
The filename of models or what they depict is irrelevant.