DynDOLOD 3.00 Alpha 182

[sheson]

4 hours ago, ikonomov said:

Assuming that the 3.0 LOD pack for Majestic Mountains is made for its newest version 4.02, is there a way to make https://www.nexusmods.com/skyrimspecialedition/mods/66844/ this mountain texture replacer work (recommended to be used with v1.84 of MM)?

If you notice visual issues with the LOD models from the latest DynDOLOD V 3.0 LOD pack, use 1.1 from the file archive.

[z929669]

20 hours ago, Althro said:

Addendum.

Windows is now auto-updating to the newer drivers with the most recent updates. This is regardless of if you are on Win 10 or 11.

Set your drivers and disable this ridiculous behavior using GP (or registry):

[Mousetick]

DynDOLOD Alpha 106

1. Seeing Dragonsreach window glow LOD "through" the tower roofs. LODs generated without Glow windows. Sorry for the postage stamp shots, forgot to use free camera.

• Is the window glow expected even though 'Glow windows' option is off?
• Is the glow expected not to be obstructed by objects in front of it?

2. I seem to have the same problem as discussed here but that discussion went nowhere. Thin, 1-pixel thick apparently, and short lines appearing on top of trees LODs, sometimes one line, sometimes two in a cross depending on viewing distance and angle I guess. Visible on different tree models (e.g. dead vs. not dead). Again sorry for the hard to see shots, but if I get any closer even in free camera mode they become invisible.

Any idea what might be causing this?

Full logs here: https://drive.google.com/file/d/1LEfGV8BFFUbhPUlXNgrjP0bhpJaYTqVI/view

Thanks.

[sheson]

2 hours ago, Mousetick said:

DynDOLOD Alpha 106

1. Seeing Dragonsreach window glow LOD "through" the tower roofs. LODs generated without Glow windows. Sorry for the postage stamp shots, forgot to use free camera.

• Is the window glow expected even though 'Glow windows' option is off?
• Is the glow expected not to be obstructed by objects in front of it?

2. I seem to have the same problem as discussed here but that discussion went nowhere. Thin, 1-pixel thick apparently, and short lines appearing on top of trees LODs, sometimes one line, sometimes two in a cross depending on viewing distance and angle I guess. Visible on different tree models (e.g. dead vs. not dead). Again sorry for the hard to see shots, but if I get any closer even in free camera mode they become invisible.

Any idea what might be causing this?

Full logs here: https://drive.google.com/file/d/1LEfGV8BFFUbhPUlXNgrjP0bhpJaYTqVI/view

Thanks.

1. Same happens with the vanilla glow. That is how decals work. It is either that or z-fighting.

2. MipMap artifact. Can happen if the height of a texture on the atlas is not multiple of 4 or power of 2. It is not necessarily the billboard texture itself but another that causes odd positions of following textures. Upload..DynDOLOD3\Edit Scripts\Export\LODGen_SSE_ObjectAtlasMap_Tamriel.txt and ..Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds

[ikonomov]

On 12/12/2022 at 12:42 AM, sheson said:

If you notice visual issues with the LOD models from the latest DynDOLOD V 3.0 LOD pack, use 1.1 from the file archive.

Actually I just realized that when using xLODGen I probably don't need the LOD pack, but just to confirm, is there a reason to use it when generating the terrain meshes and textures using xLODGen?

Thank you

[sheson]

18 minutes ago, ikonomov said:

Actually I just realized that when using xLODGen I probably don't need the LOD pack, but just to confirm, is there a reason to use it when generating the terrain meshes and textures using xLODGen?

Thank you

Obviously the LOD pack for DynDOLOD 3 does not affect terrain or terrain LOD. If it did it would be mentioned.

[Mousetick]

7 hours ago, sheson said:

1. Same happens with the vanilla glow. That is how decals work. It is either that or z-fighting.

Ok, that's good, better that than ugly z-fighting. But what I'm not understanding is: why is the glow visible at all? I didn't select the 'Glow windows' option on the DynDOLOD generation panel. Is Dragonsreach an exception?

7 hours ago, sheson said:

Upload..DynDOLOD3\Edit Scripts\Export\LODGen_SSE_ObjectAtlasMap_Tamriel.txt and ..Textures\DynDOLOD\LOD\DynDOLOD_Tamriel.dds

Here: https://drive.google.com/file/d/1FFzKzPkyZ5zTrbtupbCgxKhdek_KTfLm/view

At a glance looking at ObjectAtlasMap, LOD textures have power-of-2 dimensions. But I didn't check every single one (659 total) or verify their height is divisible by 4.

Thanks.

[sheson]

1 hour ago, Mousetick said:

Ok, that's good, better that than ugly z-fighting. But what I'm not understanding is: why is the glow visible at all? I didn't select the 'Glow windows' option on the DynDOLOD generation panel. Is Dragonsreach an exception?

Here: https://drive.google.com/file/d/1FFzKzPkyZ5zTrbtupbCgxKhdek_KTfLm/view

At a glance looking at ObjectAtlasMap, LOD textures have power-of-2 dimensions. But I didn't check every single one (659 total) or verify their height is divisible by 4.

Thanks.

That seems to look fine. Find out the form id of the tree base record so we can lookup which billboard it is using.

Also upload ..\DynDOLOD3\Logs\DynDOLOD_SSE_Object_Report.txt

[z929669]

8 hours ago, Mousetick said:

Ok, that's good, better that than ugly z-fighting. But what I'm not understanding is: why is the glow visible at all? I didn't select the 'Glow windows' option on the DynDOLOD generation panel. Is Dragonsreach an exception?

Here: https://drive.google.com/file/d/1FFzKzPkyZ5zTrbtupbCgxKhdek_KTfLm/view

At a glance looking at ObjectAtlasMap, LOD textures have power-of-2 dimensions. But I didn't check every single one (659 total) or verify their height is divisible by 4.

Thanks.

 

7 hours ago, sheson said:

That seems to look fine. Find out the form id of the tree base record so we can lookup which billboard it is using.

Also upload ..\DynDOLOD3\Logs\DynDOLOD_SSE_Object_Report.txt

 

If this is EVT, is it possible that it's due to certain branch texture options not being 'clean' on the UV map of the source atlas? or not being between 0-1? Then this causing mipmap artifacts? I believe that some of the EVT UVs of certain branch options may capture bits of other parts of the texture not under the alpha opacity of the atlas and wonder if this could manifest in such a way.

[DoubleYou]

1 hour ago, z929669 said:

 

 

If this is EVT, is it possible that it's due to certain branch texture options not being 'clean' on the UV map of the source atlas? or not being between 0-1? Then this causing mipmap artifacts? I believe that some of the EVT UVs of certain branch options may capture bits of other parts of the texture not under the alpha opacity of the atlas and wonder if this could manifest in such a way.

No, this will not cause this. I've seen this creating billboards manually myself, and typically the fix is to pad the UV down for the billboard model, so that it is between 0 and 0.95 or similar, instead of 0 and 1, to help prevent the texture on the top of the atlas from bleeding into the texture for the tree billboard. You could probably make this modification via changing the included billboard template models (e.g., DynDOLOD_flat_4x2_lod.nif for Billboard4). Alternately you can pad the texture with additional transparency space at the top.

[Mousetick]

I hate to be a pain in the bottom, but I'd appreciate if you wouldn't mind answering my earlier questions:

Ok, that's good, better that than ugly z-fighting. But what I'm not understanding is: why is the glow visible at all? I didn't select the 'Glow windows' option on the DynDOLOD generation panel. Is Dragonsreach an exception?

Or you could tell me to stop asking stupid questions and RTFM, that'd be fine too. Thanks in advance, either way

11 hours ago, sheson said:

That seems to look fine. Find out the form id of the tree base record so we can lookup which billboard it is using.

Also upload ..\DynDOLOD3\Logs\DynDOLOD_SSE_Object_Report.txt

Form id of one of the base trees is 000B927A <TreePineForest01Dead>. The specific reference I picked is 00019125 along the Whiterun/Riverwood road. The base record is modified by a custom plugin to tweak the animation settings, the rest is vanilla Skyrim.esm. The reference is modified by the same custom plugin to make it x1.2 times larger, the rest is vanilla Skyrim.esm.

Full logs here: https://drive.google.com/file/d/1LEfGV8BFFUbhPUlXNgrjP0bhpJaYTqVI/view

Edit: I figured the next thing you'd ask to look at are the billboards for 000B927A <TreePineForest01Dead>, so I put them there: https://drive.google.com/file/d/1S_X_8SbElowX1lwIyyuudyMkfWhAuirn/view.

Thanks.

4 hours ago, z929669 said:

If this is EVT

No this is LVT (Lush Vanilla Trees) with texture replacers that only work with vanilla branch meshes, so wouldn't work with EVT, as per textures MA.

4 hours ago, z929669 said:

is it possible that it's due to certain branch texture options [...]

3 hours ago, DoubleYou said:

[...] typically the fix is to pad the UV down for the billboard model, so that [...]

All you guys are discussing and suggesting sounds very interesting, but I can barely understand a word of what you're saying!

[sheson]

4 hours ago, Mousetick said:

Ok, that's good, better that than ugly z-fighting. But what I'm not understanding is: why is the glow visible at all? I didn't select the 'Glow windows' option on the DynDOLOD generation panel. Is Dragonsreach an exception?

That is the vanilla glow of Whiterun. Have you not opened console and clicked on it to get its form id etc.?

[sheson]

5 hours ago, Mousetick said:

Form id of one of the base trees is 000B927A <TreePineForest01Dead>. The specific reference I picked is 00019125 along the Whiterun/Riverwood road. The base record is modified by a custom plugin to tweak the animation settings, the rest is vanilla Skyrim.esm. The reference is modified by the same custom plugin to make it x1.2 times larger, the rest is vanilla Skyrim.esm.

Full logs here: https://drive.google.com/file/d/1LEfGV8BFFUbhPUlXNgrjP0bhpJaYTqVI/view

Edit: I figured the next thing you'd ask to look at are the billboards for 000B927A <TreePineForest01Dead>, so I put them there: https://drive.google.com/file/d/1S_X_8SbElowX1lwIyyuudyMkfWhAuirn/view.

Thanks.

No this is LVT (Lush Vanilla Trees) with texture replacers that only work with vanilla branch meshes, so wouldn't work with EVT, as per textures MA.

All you guys are discussing and suggesting sounds very interesting, but I can barely understand a word of what you're saying!

That trees top is exactly at y = 0.5 of the atlas texture, so there should not be any mipmap artefacts or any float precision errors.

Please upload the object LOD level 4 *.BTO file for that area as indicated by the DynDOLOD SkyUI MCM.

[IX_Flipyap]

Does anyone know how to get the shrine of azura to have higher quality on the map? https://imgur.com/6LoddgR

[sheson]

7 minutes ago, IX_Flipyap said:

Does anyone know how to get the shrine of azura to have higher quality on the map? https://imgur.com/6LoddgR

Create a higher resolution LOD model/texture, make it use the full texture (not trivial since it goes directly against what LOD is supposed to do) or set to use the full model for the object LOD Level used on the map. https://dyndolod.info/Mods/Replaced-Full-Model-Example-Azura-Statue

Being that close to LOD or the map is not supposed to happen.