DynDOLOD 3.00 Alpha 196

[z929669]

1 hour ago, MITSUYOMI said:

Hey sheson, just ran Dyndolod again with verbose enabled this time. The log do say that the trees with transparent leaves have out of range but it say it does not refer to the texture of the foliage but instead to the trunk or bark textures of the tree. Here are also the files you asked for.

 

 

Log SSE LODGEN - https://drive.google.com/file/d/1WzOFycipAIvyrhiRdAeSANcHHyzMt_JM/view?usp=share_link

3d Lod Resource - https://drive.google.com/file/d/1f1v1w1Sh1niQUilsa4HFEUsZwSdf17Bz/view?usp=share_link

While sheson is away ... This is what I would do.

Try regenerating DynDOLOD using this version of the LODs you sent. This removes the "UseMipMaps" string from the branch BsTriShape name, which --as I learned just a few posts back-- is what prevents DynDOLOD from generating the branch texture mipmaps for the LOD version as usual. It will instead use the mips in the texture.

It could be that the texture mipmaps are not done properly (I looked at them, and they get very thin) ... if that's the case, you should notice that the loaded full trees in the farthest distance before LOD begins look thinner than the close ones. It's worth a try. If it looks better, the mod author should be told to fix the mips or remove the string. These LODs are also not hybrids for some reason, so unnecessarily complex for LOD.

Branch UVs look fine to me, and trunk UV doesn't matter (no alpha transparency to worry about). The NiAlphaProperty is quite low (40), but I don't think it matters much. But it would matter if the MA used a texture alpha threshold to match it (not sure how to check that or if that info is in the texture).

[MITSUYOMI]

22 hours ago, MITSUYOMI said:

Ok, will do z92. They are a bit complex for LOD but I am planning to redo them I just need to iron out that transparent foliage bug. 

[z929669]

22 minutes ago, MITSUYOMI said:

23 hours ago, MITSUYOMI said:

Ok, will do z92. They are a bit complex for LOD but I am planning to redo them I just need to iron out that transparent foliage bug. 

You could also try this version of one of the diffuse used. I just saved at alpha mipmap coverage threshold of default 127. This is probably close to what DynDOLOD uses, I assume.atlas_pine.7z

PS: I should have mentioned that you could use the texture on the original version of pine01 I think without "UseMipMaps" removed.

[sheson]

7 hours ago, MITSUYOMI said:

Hey sheson, just ran Dyndolod again with verbose enabled this time. The log do say that the trees with transparent leaves have out of range but it say it does not refer to the texture of the foliage but instead to the trunk or bark textures of the tree. Here are also the files you asked for.

Log SSE LODGEN - https://drive.google.com/file/d/1WzOFycipAIvyrhiRdAeSANcHHyzMt_JM/view?usp=share_link

3d Lod Resource - https://drive.google.com/file/d/1f1v1w1Sh1niQUilsa4HFEUsZwSdf17Bz/view?usp=share_link

Really read this entire page https://dyndolod.info/Help/3D-Tree-LOD-Model carefully.

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.

To create better mipmaps for a full texture you can use Texconv -keepcoverage number. See https://github.com/Microsoft/DirectXTex/wiki/Texconv

Remove the UseMipMaps from the shape name so it can use the texture added to the atlas with properly made mipmaps by DynDOLOD. However, atm the LOD shapes can not use the texture atlas because of the glow texture for the soft lighting (3rd slot). This will be addressed in a future update.

Create hybrid 3D tree LOD models as explained at https://dyndolod.info/Help/3D-Tree-LOD-Model so the trunks are replaced by billboards in the LOD.

Only creating a "lod" texture that is 1:1 the full texture with a lower resolution is pointless, especially when the UV for it is not inside 0.0 and 1.0 and the shape can not be combined with others. Create a stitched LOD texture and update the UV accordingly (and remove the small branches for futrher optimization) or better create hybrid 3D tree LOD models with billboard trunks. They work well for trees with straight trunks in the center of the tree.

Otherwise, those 3D tree LOD models are not much better than full models in terms of drawcalls and optimization.

[MITSUYOMI]

hey z92, it seems to be working now but still it is a bit transparent, can you please tell me how you did it. what software did you use and settings?

Edited March 11, 2023 by MITSUYOMI

[heheloveer]

8 hours ago, z929669 said:

Testing with these changes for Alpha 119. Default is using ComplexGrassBillboard=4, ComplexGrassBacklightMask=0

L to R: Default  >>  ComplexGrassBillboard=5, ComplexGrassBacklightMask=50

This doesn't seem right. First images show as expected, but I did not expect that these changes would affect loaded grass, so I'm verifying ... wait one.

---

I confirmed that EVLaS has no impact. No shadow is cast my the distant mountain. It should creep along towards the PC as the sun is occluded.

Any ideas? Terrain underside not working maybe? Logs

---

Disregard previous compare. I was lazy and loaded up the game on my save without clean saving first. Using a clean save or new game resolved EVLaS interaction:

L to R: Default  >>  ComplexGrassBillboard=5, ComplexGrassBacklightMask=50  >>  ComplexGrassBillboard=5, ComplexGrassBacklightMask=25

Better, but I think ComplexGrassBacklightMask=25 may be the best trade-off

I haven't tried the new build myself but this is pretty much the effect I envisaged. Without backlighting the grass lod would not be lit up when in, well, backlighting conditions. This may or may not match the full grass very well since the way full grass reacts to backlighting conditions depends on complex grass normal map and ENB complex grass settings, among other things. I have already noticed in your screenshots the grass would be partially lit up even in backlighting conditions, so re-enabling backlighting but tune down the force seems to be the way to go, while I imagine I might as well ditch backlighting altogether since my grass doesn't really light up when the camera's facing the sun. Anyway I think each user have to observe how their full grass react to dawn/dusk sunlight and adjust the ini settings accordingly in order to have the best matching grass lods. It might take some work and experimentation, but now we do have the option to control it better.

Edited March 11, 2023 by heheloveer

[z929669]

8 hours ago, MITSUYOMI said:

hey z92, it seems to be working now but still it is a bit transparent, can you please tell me how you did it. what software did you use and settings?

I used NVIDIA Texture Tools Exporter and just opened and saved with alpha mipmap coverage threshold box checked at default threshold of 127. All other settings default (but saved using 'normal' method instead of 'fastest'). I'm guessing you could alternatively use Texconv -keepcoverage number as sheson said, but I don't know what 'number' represents.

Maybe increasing NiAlphaProperty to 128 on the branch node would resolve completely, but not sure without testing.

[sheson]

57 minutes ago, z929669 said:

I used NVIDIA Texture Tools Exporter and just opened and saved with alpha mipmap coverage threshold box checked at default threshold of 127. All other settings default (but saved using 'normal' method instead of 'fastest'). I'm guessing you could alternatively use Texconv -keepcoverage number as sheson said, but I don't know what 'number' represents.

Maybe increasing NiAlphaProperty to 128 on the branch node would resolve completely, but not sure without testing.

https://github.com/Microsoft/DirectXTex/wiki/Texconv
-keepcoverage number: Preserves alpha coverage in generate mipmaps for alpha test reference value (0 to 1).

0 = 0, 0.5 = 127, 1.0 = 255

[Honeypopcorn]

Sorry my bad english. However, it has been suffering for three days due to repeated phenomena.

 

 

The arrival time is different, but the exact same phenomenon is repeated, and everything like Window defender is blocked. I've done enough googling. Please help me.

If I generate Texgen dozens of times over and over again, sometimes succeed once, but I don't think this is the right way.

I've been using DYNDOLod enough since the beginning of the SE and I've had this problem after the recent update.

 

Upload log to Google Drive due to capacity issues.

https://drive.google.com/drive/folders/1IZhCqMRqnHTgvMRjnGg2Aajor9-2zmdA

 

 

Edited March 12, 2023 by Honeypopcorn

[MITSUYOMI]

19 hours ago, sheson said:

Really read this entire page https://dyndolod.info/Help/3D-Tree-LOD-Model carefully.

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.

To create better mipmaps for a full texture you can use Texconv -keepcoverage number. See https://github.com/Microsoft/DirectXTex/wiki/Texconv

Remove the UseMipMaps from the shape name so it can use the texture added to the atlas with properly made mipmaps by DynDOLOD. However, atm the LOD shapes can not use the texture atlas because of the glow texture for the soft lighting (3rd slot). This will be addressed in a future update.

Create hybrid 3D tree LOD models as explained at https://dyndolod.info/Help/3D-Tree-LOD-Model so the trunks are replaced by billboards in the LOD.

Only creating a "lod" texture that is 1:1 the full texture with a lower resolution is pointless, especially when the UV for it is not inside 0.0 and 1.0 and the shape can not be combined with others. Create a stitched LOD texture and update the UV accordingly (and remove the small branches for futrher optimization) or better create hybrid 3D tree LOD models with billboard trunks. They work well for trees with straight trunks in the center of the tree.

Otherwise, those 3D tree LOD models are not much better than full models in terms of drawcalls and optimization.

Yup, thats my bad. But I did try to run dyndo without the 'UseMipMaps' and when i did try ro run it with the texture provided by z92 it did create better results but still a bit transparent. I am planning to further optimize it and remove the branches in all its entirety the next time, but I want to fix them for now. Btw can you tell me, how can a texture be outside of UV 0.0 and 1.0. I tried getting snip of the edit UV window and can you point out to me which is the actual boundaries of 0 to 1? 

 

 

[z929669]

1 hour ago, MITSUYOMI said:

Yup, thats my bad. But I did try to run dyndo without the 'UseMipMaps' and when i did try ro run it with the texture provided by z92 it did create better results but still a bit transparent. I am planning to further optimize it and remove the branches in all its entirety the next time, but I want to fix them for now. Btw can you tell me, how can a texture be outside of UV 0.0 and 1.0. I tried getting snip of the edit UV window and can you point out to me which is the actual boundaries of 0 to 1? 

 

 

I'd like to know this as well. I don't understand why NifSkope doesn't have axis values in the UV editor. Putting it in vertex mode and selecting a number of vertices shows that everything I select is in 0-1 range, so I think the light gray box is 0-1 (or -1 to +1 in Cartesian space) ... so if that's true, then the dark gray must be 0-3 (or -3 to +3)??

[sheson]

4 hours ago, Honeypopcorn said:

Sorry my bad english. However, it has been suffering for three days due to repeated phenomena.

The arrival time is different, but the exact same phenomenon is repeated, and everything like Window defender is blocked. I've done enough googling. Please help me.

If I generate Texgen dozens of times over and over again, sometimes succeed once, but I don't think this is the right way.

I've been using DYNDOLod enough since the beginning of the SE and I've had this problem after the recent update.

 

Upload log to Google Drive due to capacity issues.

https://drive.google.com/drive/folders/1IZhCqMRqnHTgvMRjnGg2Aajor9-2zmdA

Check the task manager if there are Texconvx64.exe processes TexGen might be waiting for.

If there are, make sure Texconvx64.exe is not blocked by the OS or antivir.

[sheson]

4 hours ago, MITSUYOMI said:

Yup, thats my bad. But I did try to run dyndo without the 'UseMipMaps' and when i did try ro run it with the texture provided by z92 it did create better results but still a bit transparent. I am planning to further optimize it and remove the branches in all its entirety the next time, but I want to fix them for now. Btw can you tell me, how can a texture be outside of UV 0.0 and 1.0. I tried getting snip of the edit UV window and can you point out to me which is the actual boundaries of 0 to 1? 

2 hours ago, z929669 said:

I'd like to know this as well. I don't understand why NifSkope doesn't have axis values in the UV editor. Putting it in vertex mode and selecting a number of vertices shows that everything I select is in 0-1 range, so I think the light gray box is 0-1 (or -1 to +1 in Cartesian space) ... so if that's true, then the dark gray must be 0-3 (or -3 to +3)??

I uploaded a screenshot that shows the 0.0 to 1.0 area with a red outline here https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-119/?do=findComment&comment=269997. The center 0.0 to 1.0 area typically shows the texture normally lit. The repeated texture outside the area is usually darker. The major guidelines are spaced at 0.5 each. This is off topic.

[Honeypopcorn]

13 hours ago, sheson said:

Check the task manager if there are Texconvx64.exe processes TexGen might be waiting for.

If there are, make sure Texconvx64.exe is not blocked by the OS or antivir.

Process blocking and folder blocking have already been done. There are no anti-virus programs other than Window Defender.

[sheson]

1 hour ago, Honeypopcorn said:

Process blocking and folder blocking have already been done. There are no anti-virus programs other than Window Defender.

You did not answer if there is a Texconvx64.exe (a command line tool from MS) processes visible in Task manager TexGen is waiting for.
If that is the case, then something is blocking it from executing/continuing. If you kill it TexGen will most likely continue/fail with an error message about it.
If it is not the OS, UAC, antivir or mod manager blocking file access, it could be old/outdated graphics drivers or a problem with them preventing it from continuing. Do a clean re-install of the latest official drivers (not beta or optional versions). Do not install any bloat/crapware that comes with drivers, just the drivers only.