Jump to content

Recommended Posts

Posted
1 hour ago, z929669 said:

No, they all contain LOD but that one shot. Toggling the next image should show more distant pines popping in, two at left and one at right. One in the middle as well but it's mostly obscured by the foreground. It may be simpler to view them locally. Screenshots

Make a useful screenshot of a relevant full model with more informative console as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots

If you want to show something about LOD, then put the LOD model into the middle of the screenshot, use tfc to get closer as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots.

I suggest to compare the normal (and may be tangents and bi-tangents) vectors between the full model, LOD model and also in the BTOs for anything that does not use "fixednormals" which are typically only useful for billboards like planes. If you want to change the normal vectors, "spherenormals" probably works better for crowns.

Posted
6 hours ago, sheson said:

Make a useful screenshot of a relevant full model with more informative console as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots

If you want to show something about LOD, then put the LOD model into the middle of the screenshot, use tfc to get closer as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots.

I suggest to compare the normal (and may be tangents and bi-tangents) vectors between the full model, LOD model and also in the BTOs for anything that does not use "fixednormals" which are typically only useful for billboards like planes. If you want to change the normal vectors, "spherenormals" probably works better for crowns.

Yeah, spherenormals will take care of the differential brightness issue, but it also makes LOD pines very bright, so I will need to see about modifying the normals and possibly the mesh lighting of the LOD models to see if I can compensate. Thanks

Posted
2 hours ago, z929669 said:

Yeah, spherenormals will take care of the differential brightness issue, but it also makes LOD pines very bright, so I will need to see about modifying the normals and possibly the mesh lighting of the LOD models to see if I can compensate. Thanks

Read my entire post. Make sure that the used LOD models that do not set fixednormals have the same normal vectors as the full model. If that is the case, check that they are still the same in the BTO.

Posted (edited)
6 hours ago, sheson said:

Assuming the second screenshot shows LOD, use MO2 right window data tab to find out which mod is overwriting meshes\lod\mountains\mountaintrim01_lod_0.nif and report.

ERM - Dyndolod Add-on. I checked texgen output and it seems like texgen is making a black pineforest01lod.dds texture out of pineforest01.dds. The texture is from this mod https://www.nexusmods.com/skyrimspecialedition/mods/83847?tab=description

EDIT: Happens with reachdirt01lod.dds and reachgras01lod.dds

Edited by mostwanted11
Posted
7 hours ago, mostwanted11 said:

ERM - Dyndolod Add-on. I checked texgen output and it seems like texgen is making a black pineforest01lod.dds texture out of pineforest01.dds. The texture is from this mod https://www.nexusmods.com/skyrimspecialedition/mods/83847?tab=description

EDIT: Happens with reachdirt01lod.dds and reachgras01lod.dds

In that case use MO2 right window data tab to find out which mod textures\landscape\pineforest01.dds is from and report.

Posted
33 minutes ago, sheson said:

In that case use MO2 right window data tab to find out which mod textures\landscape\pineforest01.dds is from and report.

The mod link is in the reply

  • +1 1
Posted
2 hours ago, mostwanted11 said:

The mod link is in the reply

Ah sorry, the CRC32 did not seem to match on first glance. In any case, the mod contains textures that do not have all expected mipmap levels and stop at 128x128.

The latest test version from https://dyndolod.info/Downloads/Test-Versions should fix that. Delete all old logs. Report result, upload new logs if issue persists.

Posted
7 hours ago, sheson said:

Ah sorry, the CRC32 did not seem to match on first glance. In any case, the mod contains textures that do not have all expected mipmap levels and stop at 128x128.

The latest test version from https://dyndolod.info/Downloads/Test-Versions should fix that. Delete all old logs. Report result, upload new logs if issue persists.

It didn't get fixed, the texture that came out is still black

Logs.rar

Posted
19 hours ago, sheson said:

Read my entire post. Make sure that the used LOD models that do not set fixednormals have the same normal vectors as the full model. If that is the case, check that they are still the same in the BTO.

I don't set `fixednormals` on any of the shape names, so they are the same between full/LOD models, since LOD models use stripped copies of the branch mesh from full.

I assume you are suggesting to check that normal vectors in the BTO remain equal to the LOD models generated without setting `spherenormals`, since that instruction will inherently alter the normal vectors in pines of the BTO, correct?

Posted
9 minutes ago, z929669 said:

I don't set `fixednormals` on any of the shape names, so they are the same between full/LOD models, since LOD models use stripped copies of the branch mesh from full.

I assume you are suggesting to check that normal vectors in the BTO remain equal to the LOD models generated without setting `spherenormals`, since that instruction will inherently alter the normal vectors in pines of the BTO, correct?

Verify that the normal vectors, tangents, bi-tangents of the used full model in the game and the LOD models used by DynDOLOD are the same.
While you are at it, make sure the UV is inside 0.0 and 1.0 and/or the clamp mode is CLAMP_S_CLAMP_T for LOD models that do not have "noreuv" or "noatlas" in the shape names.
If all that is the case, then check the BTOs. It only makes sense to do that for LOD models that neither have "fixednormals" or "spherenormals" in the shape names.

  • Like 1
Posted

The LOD for some building moss cover from Riften Extension - Northshore does not look quite right. See the attached screenshots (they are taken from the Creation Kit, but I would expect it to look similar in game). As you can see, the building is not nearly as overgrown as it looks in the LOD. To me, it looks like some scaling issue.

How would I resolve this? If I need specific mesh mask rules for these particular objects, I need to know how to set them up. Or perhaps this is something you can fix on the DynDOLOD side? The affected objects have FormIDs 22890~RiftenExtensionNorth.esp and 22891~RiftenExtensionNorth.esp, respectively.

Logs can be found here: https://www.dropbox.com/scl/fi/mhvt3nxzsjc1hb2dz2er2/Logs.7z?rlkey=zot7643q61cmmt0am8hi8zcoh&dl=0

Skärmbild 2026-02-01 211203.png

Skärmbild 2026-02-01 211638.png

Posted
2 hours ago, sheson said:

Verify that the normal vectors, tangents, bi-tangents of the used full model in the game and the LOD models used by DynDOLOD are the same.
While you are at it, make sure the UV is inside 0.0 and 1.0 and/or the clamp mode is CLAMP_S_CLAMP_T for LOD models that do not have "noreuv" or "noatlas" in the shape names.
If all that is the case, then check the BTOs. It only makes sense to do that for LOD models that neither have "fixednormals" or "spherenormals" in the shape names.

How exactly can I compare specific vertices in the LOD model to corresponding vertices in the BTO? There's so many in the BTO, and its shapes merge many different tree models. I have verified a random sample of vertices are identical between full model and LOD model, but the BTO is another matter.

The tree in center screen has LOD model with identical vertex data to full model, CLAMP_S_CLAMP_T, and all branch UV between 0-1. It's using proper diffuse and normal.

SkyrimSE 2026-02-01 14-44-30-56.jpgSkyrimSE 2026-02-01 14-52-12-94.jpg

Here's the full model followed by the LOD model in game around 1PM:

full.jpgLOD.jpg

 

I regenerated LOD, and here's logs and all relevant data.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.