DynDOLOD 3.00 Alpha 178

[mattski123]

11 hours ago, mattski123 said:

thank you! I have now gone and added the files and folders to my Windows Defender exceptions list. And as I said I don't have any other antivirus or anything. And my UAC settings are set to never notify if that's the right way to do it. No sorry BDS stands for better dynamic snow. And I actually didn't even know slash realize that the first two letters/numbers in X edit will literally the load order ID's. Thank you for telling me that! Because I didn't know that before.

Texgen ran very smoothly and after running arnimavoid ALONE it happily lets me save and exit. I will have to try to run the full dynDOLOD tomorrow. Incl other world spaces. Any other trobuleshooting tips?

Hey just got this when re-running in full (all mods selected):

[Main Instruction]
Checking for errors failed Access violation at address 000000000041928F in module 'DynDOLODx64.exe'.

[Content]
Read of address 0000000000000000 for arnima.esm [REFR:100892A0] (places Bucket02a "Bucket" [MISC:000747FB] in GRUP Cell Temporary Children of [CELL:1001DC47] (in arnimaDUPLICATE003 "The Reach" [WRLD:10000D62] at 20,-8))

Here's the logs: https://easyupload.io/dofki9
I checked the reference in xEdit and it's not conflicting with anything. Here's placement if this helps:

[10] arnima.esm (AAE5C2BB) \ Worldspace \ 10000D62 <arnimaDUPLICATE003> \ Block 0, -1 \ Sub-Block 2, -1 \ 1001DC47 \ Temporary \ 100892A0

[Stefan]

Question. I tried searching this thread and the xLodgen one for a Fo4 guide, but couldn't find one. Could someone please help me with Object LOD settings? For the Terrain LOD I can inspire myself from the SSE WIP settings, but that guide doesn't have Objects LOD since it uses Dyndolod. The FNV guide only says to use 8192 as Alpha Size, and that's about it.

If it matters, I am using vanilla trees, I have already installed higher quality assets for xLodgen from Luxor HD overhaul and the resources in the OP here. Here is what I am starting from:

Thank you

Edited October 13, 2021 by Stefan

[sheson]

3 hours ago, Stefan said:

Question. I tried searching this thread and the xLodgen one for a Fo4 guide, but couldn't find one. Could someone please help me with Object LOD settings? For the Terrain LOD I can inspire myself from the SSE WIP settings, but that guide doesn't have Objects LOD since it uses Dyndolod. The FNV guide only says to use 8192 as Alpha Size, and that's about it.

If it matters, I am using vanilla trees, I have already installed higher quality assets for xLodgen from Luxor HD overhaul and the resources in the OP here. Here is what I am starting from:

Thank you

The defaults are perfectly fine.

Using anything but BC5 for normal and specular textures does not really make any sense.

The diffuse format of the vanilla single object LOD textures is typically DXT5. There won't be any visual improvements by using BC7 max over BC7 quick over using DXT5.

If vertex colors are checked there can be issues with interiors using the LOD from parent worldspaces.

As you can see from the screenshots on the first post, using backlight power helps with tree LOD lighting.

Increasing the alpha threshold will make LOD for trees and other objects using transparency appear to be thinner.

[sheson]

12 hours ago, fodamaster2 said:

I'm using the latest version of SSEEdit available on Nexus Mods.
I really didn't do anything with the mentioned plugins. The only thing must have been one or two WACCF updates, always downloading from the Nexus Mods. 

With SSEEDit 4.0.3 from Nexus I get the exact same error message when loading the plugins:

[00:06] Background Loader: Warning: Record [LVLI:060012C4] in file Weapons Armor Clothing & Clutter Fixes.esp is being overridden by record [WEAP:040012C4] in file ACE Archery.esp.

The load order ID shown in the message is matching the Master Files Index for the mentioned plugin. Or one higher if the record is in the mentioned plugin. I.e. they are no yet adjusted to the actual load order when this error happens.

When I go to xx0012C4 in Weapons Armor Clothing & Clutter Fixes.esp I can indeed see that is being replaced by  ACE Archery.esp.

I am not sure what the purpose of injecting weapon records into the other plugin is exactly.

[Phlunder]

I've been testing the new alpha on Enderal LE, on a new vanilla test profile. So far, almost everything seems fine. I ran into two issues, one of them I hopefully already identified. The first is that there is an incorrect LOD stone mesh packaged with Enderal, its base ID is 8e844. It has been assigned very different shaped, sized, and textured LOD mesh found here: "meshes\enderal\lod\rocks\rock02_lod_1.nif"

In the screen its also visible that the LOD mesh of the building has a different shape, but I guess that's because its a vanilla Riften house (RTMeadery01 [STAT:0008C018]), with just a certain part reused in Enderal? Comparison screens are in the spoiler: 

Spoiler

The other issue is a bit harder to grasp for me. Certain tree types (haven't identified them all, one is _00E_NOaktree08 [TREE:001130D4]) have very weird visual artifacts when transitioning from object LOD to full model. I'm using the high preset and ultra trees, which means for Enderal trees in object LOD with normals. Textures have been freshly generated with TexGen beforehand. Here's a screenshot of the issue:

Spoiler

Thanks again for your continued work and dedication on DynDOLOD and xLODGen!

[Stefan]

Thank you very much. I will redo the LOD per your recommendations and OP. And a general LOD question. Does it make sense to have LOD levels bigger than this?

I am referring to L4, L8, etc. Or adding more distance doesn't add anything to the eye.

Thanks again.

PS: I have done the LOD and it's excellent, before I could easily see when LOD changed levels while getting closer, now I can see minimal differences only if I am very very focused on the LOD, and not all the time. Thanks!

Edited October 13, 2021 by Stefan

[sheson]

1 hour ago, Stefan said:

Thank you very much. I will redo the LOD per your recommendations and OP. And a general LOD question. Does it make sense to have LOD levels bigger than this?

I am referring to L4, L8, etc. Or adding more distance doesn't add anything to the eye.

Thanks again.

PS: I have done the LOD and it's excellent, before I could easily see when LOD changed levels while getting closer, now I can see minimal differences only if I am very very focused on the LOD, and not all the time. Thanks!

Which settings are the "best" depends on the game, load order, setup, performance and personal preference. So as I always, I suggest to make screenshots and compare different settings yourself.

Or refer to a modding guide and/or a comparisons made by users who play/mod the game.

[sheson]

1 hour ago, Phlunder said:

I've been testing the new alpha on Enderal LE, on a new vanilla test profile. So far, almost everything seems fine. I ran into two issues, one of them I hopefully already identified. The first is that there is an incorrect LOD stone mesh packaged with Enderal, its base ID is 8e844. It has been assigned very different shaped, sized, and textured LOD mesh found here: "meshes\enderal\lod\rocks\rock02_lod_1.nif"

In the screen its also visible that the LOD mesh of the building has a different shape, but I guess that's because its a vanilla Riften house (RTMeadery01 [STAT:0008C018]), with just a certain part reused in Enderal? Comparison screens are in the spoiler: 

  Hide contents

The other issue is a bit harder to grasp for me. Certain tree types (haven't identified them all, one is _00E_NOaktree08 [TREE:001130D4]) have very weird visual artifacts when transitioning from object LOD to full model. I'm using the high preset and ultra trees, which means for Enderal trees in object LOD with normals. Textures have been freshly generated with TexGen beforehand. Here's a screenshot of the issue:

  Hide contents

Thanks again for your continued work and dedication on DynDOLOD and xLODGen!

Upload the TexGen and DynDOLOD logs and debug logs as explained in the first post.

Have you check the diffuse and normal textures of the tree LOD billboards created by TexGen for that tree if they look weird?
Check the log for error messages.

Base Record 0008E844 defines the full model Enderal\architecture\AncientRuins\Rock02B.nif. There is no rock2b_lod.nif?

Maybe you mean 0008E83A? Its full model filename meshes\enderal\architecture\ancientruins\rock02.nif collides with meshes\enderal\medievalpack\rocks\rock02.nif for which the included LOD model is. I will have to address that with an updated rule.

Provide worldspace cell coordinates or a reference form id from console of the building in the first two screenshots.

[Phlunder]

44 minutes ago, sheson said:

Upload the TexGen and DynDOLOD logs and debug logs as explained in the first post.

Base Record 0008E844 defines the full model Enderal\architecture\AncientRuins\Rock02B.nif. There is no rock2b_lod.nif?

Maybe you mean 0008E83A? Its full model filename meshes\enderal\architecture\ancientruins\rock02.nif collides with meshes\enderal\medievalpack\rocks\rock02.nif for which the included LOD model is. I will have to address that with an updated rule.

Provide worldspace cell coordinates or a reference form id from console of the building in the first two screenshots.

Sorry for being an idiot and ignoring the big highlighted text in the first post. I'll get you the logs shortly. I am not sure about the stones, and yes there is no rock2b_lod.nif. I just looked at Enderal's rock LOD assets because I couldn't figure out where it was getting it from. I realize now that the naming convention has to match up too.

The ref ID of the building in question is 98273. The stones with the described issue are right next to it, maybe that helps too.

Regarding the visual artifacts on transition from object LOD to full model for trees, the issue doesn't happen when I use the traditional billboard system, just tested that. But maybe the logs will clear that up. Give me a minute to rerun everything.

 

Edited October 13, 2021 by Phlunder

[sheson]

14 hours ago, mattski123 said:

Hey just got this when re-running in full (all mods selected):

[Main Instruction]
Checking for errors failed Access violation at address 000000000041928F in module 'DynDOLODx64.exe'.

[Content]
Read of address 0000000000000000 for arnima.esm [REFR:100892A0] (places Bucket02a "Bucket" [MISC:000747FB] in GRUP Cell Temporary Children of [CELL:1001DC47] (in arnimaDUPLICATE003 "The Reach" [WRLD:10000D62] at 20,-8))

Here's the logs: https://easyupload.io/dofki9
I checked the reference in xEdit and it's not conflicting with anything. Here's placement if this helps:

[10] arnima.esm (AAE5C2BB) \ Worldspace \ 10000D62 <arnimaDUPLICATE003> \ Block 0, -1 \ Sub-Block 2, -1 \ 1001DC47 \ Temporary \ 100892A0

So this is a different reference than the other day.

Does the error happen (almost) every time but with different records?

[Phlunder]

1 hour ago, sheson said:

Upload the TexGen and DynDOLOD logs and debug logs as explained in the first post.

Have you check the diffuse and normal textures of the tree LOD billboards created by TexGen for that tree if they look weird?
Check the log for error messages.

Base Record 0008E844 defines the full model Enderal\architecture\AncientRuins\Rock02B.nif. There is no rock2b_lod.nif?

Maybe you mean 0008E83A? Its full model filename meshes\enderal\architecture\ancientruins\rock02.nif collides with meshes\enderal\medievalpack\rocks\rock02.nif for which the included LOD model is. I will have to address that with an updated rule.

Provide worldspace cell coordinates or a reference form id from console of the building in the first two screenshots.

Here are the logs: https://ufile.io/f/2hfza

Yes, I checked the TexGen output for any curiosities, but diffuse and normal for the tree in question (in the screenshot) look fine.

 

Edited October 13, 2021 by Phlunder

[Stefan]

Thanks again. I am too biased and uncertain to notice any difference between Ultra and going wild. I will just keep it Ultra and that's it. 

[sheson]

34 minutes ago, Phlunder said:

Here are the logs: https://ufile.io/f/2hfza

Yes, I checked the TexGen output for any curiosities, but diffuse and normal for the tree in question (in the screenshot) look fine.

The way you describe the problem there can not really be anything wrong with the ultra tree LOD if it looks fine while loaded in the distance. The object LOD is just disabled after the full models faded in, there is no fade out or anything. So that should mean any artifacts while the full models fade in should only have to do with the full models.

Disable LOD with tll in console. Then check how those full models load. I would expect they would still have the same artifacts.

[Phlunder]

42 minutes ago, sheson said:

The way you describe the problem there can not really be anything wrong with the ultra tree LOD if it looks fine while loaded in the distance. The object LOD is just disabled after the full models faded in, there is no fade out or anything. So that should mean any artifacts while the full models fade in should only have to do with the full models.

Disable LOD with tll in console. Then check how those full models load. I would expect they would still have the same artifacts.

Yes, you are right, just checked with tll command and the issue also happens with LOD toggled off. I guess the LOD switching of regular billboards just makes it less visible, or even hides the issue... not sure. I never noticed it before I switched to billboards as object LOD.

Sorry for bothering you with that then. I'll look into potential issues with the full model. I'll revert to traditional billboards if necessary, that's fine.

Another question regarding billboard generation with TexGen. The screen resolution scaling works like a charm for Skyrim trees, I'd even argue the automatically picked lower resolution for smaller trees helps with the appearance when rendered from afar. Though for some Enderal trees, like the "kapok01_0009093f" the scaling seems to pick something too small for their full model size. Is that because some trees were just scaled up from their default size? For some, like the widely used "kingstree01_0014f9a6" the scaling is fine, as it picks the max size (1K resolution on either axis). The logs are still relevant for that question, if they are of any help in that regard.

I know I can overwrite the automatic size scaling manually, just trying to understand how it picks relative billboard resolution.

Edited October 13, 2021 by Phlunder

[sheson]

23 minutes ago, Phlunder said:

Yes, you are right, just checked with tll command and the issue also happens with LOD toggled off. I guess the LOD switching of regular billboards just makes it less visible, or even hides the issue... not sure. I never noticed it before I switched to billboards as object LOD.

Sorry for bothering you with that then. I'll look into potential issues with the full model. I'll revert to traditional billboards if necessary, that's fine.

Another question regarding billboard generation with TexGen. The screen resolution scaling works like a charm for Skyrim trees, I'd even argue the automatically picked lower resolution for smaller trees helps with the appearance when rendered from afar. Though for some Enderal trees, like the "kapok01_0009093f" the scaling seems to pick something too small for their full model size. Is that because some trees were just scaled up from their default size? For some, like the widely used "kingstree01_0014f9a6" the scaling is fine, as it picks the max size (1K resolution on either axis). The logs are still relevant for that question, if they are of any help in that regard.

The model scaling is taken into account. However, if there are references that set a scale considerable higher than TreeModelHeightMultiplier in the TexGen.ini then the billboard might be too small for that tree. The (max) scale set on references is not yet part of the automatic process.