DynDOLOD 3.00 Alpha 180

[sheson]

38 minutes ago, MITSUYOMI said:

Im sorry if i was not too Clear about the explanation. The problem that persists is the trees with the edited and fixed uvs still have transparent foliage. Ill try the the clamp_s and _t this time. For checking if the uv coordinates is not within 0 to 1, i just made sure that the uvs are inside the box, i dont know where to look for the actual uv values. For verbose=1 ill check again and ran dyndo.

If the UV is inside 0.0 and 1.0, then the shapes for the leaves in the object LOD BTO should be using the object LOD atlas generated by DynDOLOD which should have properly made mipmaps. Have you verified what texture the leaves in the BTO are using? If they are still using the full texture with bad mipmaps, then it is typically because of the UV being outside 0.0 and 1.0.

The UV data is either in the NiTriShapeData block or the BSTrIshape and can be checked with NifSkope.

[MITSUYOMI]

I have already set the clamp mode to clamp_s and _t, have verified the UV sets to be in between 0 and 1, but the leaves are still transparent. The BTO of the trees with transparent foliage use the same textures as the original tree model and also upon checking the UVs of the BTO it also has UV sets in between 0 and 1.

[sheson]

8 minutes ago, MITSUYOMI said:

I have already set the clamp mode to clamp_s and _t, have verified the UV sets to be in between 0 and 1, but the leaves are still transparent. The BTO of the trees with transparent foliage use the same textures as the original tree model and also upon checking the UVs of the BTO it also has UV sets in between 0 and 1.

Check the verbose LODGen log for out of range messages.
Upload the 3D tree LOD model and the used textures.

[z929669]

@sheson Question about new features in latest update:

Quote

DynDOLOD.exe - added GrassGlowMap, GrassBacklightMask, ComplexGrassGlowMap, ComplexGrassBacklightMask INI setting for better control with billboard NIF used for grass LOD generation

Is the documentation on these features pending?

[sheson]

33 minutes ago, z929669 said:

@sheson Question about new features in latest update:

Is the documentation on these features pending?

See the explanations in the INI above those settings.

[z929669]

17 minutes ago, sheson said:

See the explanations in the INI above those settings.

That's the first thing I tried ... not seeing those settings in the 119 DynDOLOD_SSE.ini

My fault. I made a mistake in updating my upgrade INI

[sheson]

8 minutes ago, z929669 said:

That's the first thing I tried ... not seeing those settings in the 119 DynDOLOD_SSE.ini

GrassGlowMap, GrassBacklightMask, ComplexGrassGlowMap, ComplexGrassBacklightMask are in the DynDOLOD_SSE.ini and DynDOLOD_ENDERALSE.ini under 4 lines of explanations for them in the DynDOLOD-Standalone.3.0-Alpha-119.7z archive.

[z929669]

On 3/2/2023 at 7:54 AM, heheloveer said:

 

I just spent a lot of time testing and the results are very very interesting. Not many screenshots though since I tested way too many things to record down one by one, and you'll have to trust my words for it. In any case, a key culprit for the phenomenon I encountered (LOD grass lighting up at dawn/dusk when facing the sun while full grass doesn't) was EVLAS. I also believe EVLAS is also responsible for the phenomenon shown in z929669's screenshots.

The summary to my findings is, EVLAS makes grass lods react to dawn/dusk lighting much more aggressively, as in, they can become very, very bright. With my ENB preset it isn't much of a problem when facing the direction opposite to the sun, since the full grass is also lit up, but when you're facing the sun, the effect becomes quite jarring, especially when EVLAS makes terrain and full grass turn darker. The screenshots were all taken with grass lods generated with the default billboard (with Back_Lighting flag). Without EVLAS, grass lods with or without Back_Lighting work more or less fine to me, but with EVLAS it seems Back_Lighting has to be removed so that grass lods won't become an eyesore when facing the sun, at least in my case.

The other interesting problem is the one illustrated in z929669's screenshots. We weren't really describing the same phenomenon, since in his screenshots the camera was facing the sun but the full grass was also quite bright, at least when the sun hadn't been obstructed by the mountains. He noticed that when the sun was obstructed but not yet sunk below the horizon, the full grass became dark but the grass lods remained bright, and I think this is also a behavior brought about by EVLAS. Step Guide does include EVLAS so I'm assuming he was using it. Anyway, without EVLAS, both the full grass and the grass lods would, as he described, "stay lit up until most of the ambient sunlight is gone". With EVLAS, sunlight can be obstructed by terrain and objects, and the full grass would not light up when the mountains are casting shadows on them. But grass lods behave the same as before: they begin to gradually light up when it's sunrise time, regardless of whether there's actually sunlight present. With Skyrim as mountainous as it is, this could create some quite confusing visuals when the sun is over the horizon but not over the mountains. Removing Back_Lighting flag doesn't really help in this case, since the grass lods would still light up when they think "it's time", albeit only on one side, instead of on all sides. z929669 thought it's likely an engine limitation and I'm inclined to agree. In any case this is for sure far beyond me to find some sort of fix.

Another thing I noticed is that, as I mentioned, in z929669's screenshots the full grass were bright when the camera was facing the sun, but in my game it would only light up when the camera is facing the opposite direction. I'm not very sure what makes the our games behave this differently. I found increasing SubSurfaceScatteringAmount parameter in ENB complex grass settings could make the grass somewhat brighter in backlighting conditions, but in the ENB preset he used this value isn't very high. This is worth considering however. If I understand it correctly, in some setups the full grass are darker when the camera's facing the sun, while in others they are brighter. This would mean some people have to resolve this "overly bright grass lods when facing the sun" issue while others don't, since the full grass are also bright anyway.

Anyway here's the logs and the ENB setting I used. I ran DynDOLOD two times with the same setting and TexGen textures. Only the billboard meshes were changed. https://anonfiles.com/B4Vdz1b2z1/Logs_and_ENB_setting_zip

 

On 3/2/2023 at 8:50 AM, sheson said:

Something must have changed since September. The backlighting also wrongly affects the Vanilla Complex Grass for ENB with the default ENB complex grass setting s (mulitpliers at 1.0 or amounts at 0.0). So next Alpha version will probably use a NIF without backlighting for complex grass by default. Since it is also possible to control the amount/percentage of backlighting with a gray scale texture, e.g. black = off, white = on, an INI setting that creates a x% gray scale texture might be added as well in case someone wants to use backlighting and control it.

By default LOD does not cast or receive shadows, so with a mod like EVLaS that makes the game cast long shadows from full models it becomes very obvious what is LOD and what isn't. It seems the ENB distant shadow effect does not make full shadows cast on LOD either. It probably just makes LOD cast shadows on LOD.

Tested latest features in Alpha 119 using defaults for grass (backlighting flag unset using external billboard). Following are screen compares with my previous under 118:

 

Left to right: Alpha 118  >>  Alpha 119

So this looks great when the sun is down. While the sun still shows over the mountain though, matching is a bit worse. Should I play with ComplexGrassBacklightMask then? Keep using ComplexGrassBillboard=4 or switch to 5?

 

[sheson]

12 minutes ago, z929669 said:

 

Tested latest features in Alpha 119 using defaults for grass (backlighting flag unset using external billboard). Following are screen compares with my previous under 118:

 

Left to right: Alpha 118  >>  Alpha 119

So this looks great when the sun is down. While the sun still shows over the mountain though, matching is a bit worse. Should I play with ComplexGrassBacklightMask then?

If the side facing away from the light direction is too dark it can be brightened with the backlightmask.

ComplexGrassBillboard=5
ComplexGrassBacklightMask=50

50 = 50% of the light makes it through

[z929669]

3 hours ago, sheson said:

If the side facing away from the light direction is too dark it can be brightened with the backlightmask.

ComplexGrassBillboard=5
ComplexGrassBacklightMask=50

50 = 50% of the light makes it through

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

[MITSUYOMI]

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

[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.