DynDOLOD 3.00 Alpha 196

[sheson]

2 hours ago, oiram1993 said:

Yeah that's fair lol, should have been more thorough on my end. Uploaded the zip of the relevant logs, can't seem to target which of my mods is causing the issue/has the bad file pathway.

It supposed to notify much earlier about the error, so I will have to look into this for future versions.

https://dyndolod.info/Installation-Instructions
Use 7-Zip to unpack the DynDOLOD Standalone archive into a new and empty 'DynDOLOD' directory that is outside of special OS folders like 'Programs Files' or 'Program Files (x86)', User, Documents, Desktop, Download and also not in SteamApps, game, Data or any mod manager folders. For example C:\Modding\DynDOLOD\.

https://dyndolod.info/Generation-Instructions#Prerequisites
Clean and error check the load order with xEdit. Clean every plugin that LOOT suggests to clean

[Althro]

21 hours ago, sheson said:

https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-106/?do=findComment&comment=266132

https://www.amd.com/en/support/kb/release-notes/rn-rad-win-22-5-1 has a link to https://drivers.amd.com/drivers/WHQL-AMD-Software-Adrenalin-Edition-22.5.1-Win10-Win11-May10.exe, found via a simple google search.

Thank you for the driver link.

The driver linked does have issues with black screening multi-monitor setups and faulty chromium based web browser video playback. However if it is only needed for lod gen, then simple roll back and forward will suffice.

[Althro]

On 12/10/2022 at 7:25 PM, sheson said:

https://stepmodifications.org/forum/topic/17510-dyndolod-300-alpha-106/?do=findComment&comment=266132

https://www.amd.com/en/support/kb/release-notes/rn-rad-win-22-5-1 has a link to https://drivers.amd.com/drivers/WHQL-AMD-Software-Adrenalin-Edition-22.5.1-Win10-Win11-May10.exe, found via a simple google search.

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.

[ikonomov]

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)?

Edited December 12, 2022 by ikonomov

[DoubleYou]

2 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)?

Pretty sure you can use it with that, and TexGen will update the texture to match.

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