DynDOLOD 3.00 Alpha 190

[sheson]

  On 10/13/2021 at 9:01 AM, 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: 

  Reveal hidden 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:

  Reveal hidden contents

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

Expand  

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]

  On 10/13/2021 at 10:27 AM, 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.

Expand  

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]

  On 10/12/2021 at 9:21 PM, 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

Expand  

So this is a different reference than the other day.

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

[Phlunder]

  On 10/13/2021 at 10:27 AM, 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.

Expand  

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]

  On 10/13/2021 at 11:44 AM, 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.

Expand  

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]

  On 10/13/2021 at 12:10 PM, 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.

Expand  

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]

  On 10/13/2021 at 12:34 PM, 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.

Expand  

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.

[Phlunder]

  On 10/13/2021 at 10:27 AM, sheson said:

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.

Expand  

Again, you were right, it was indeed 0008E83A that had the weird LOD model issue from my original post. There were so many placed close and on top of each other that I must have clicked on the one right next to it. Come to think of it, weird that the ones I misclicked have no LOD meshes assigned but the others do. From my experience (working on textures) these ancientruins and medievelpack assets can be very crude. The specific stone meshes are so simplistic they should act well as LOD meshes too heh.

Edit: Sorry, I think I get it now. Those stones have no LOD, DynDOLOD just grabbed the other LOD mesh because it has the same naming convention?

Edited October 13, 2021 by Phlunder

[sheson]

  On 10/13/2021 at 3:47 PM, Phlunder said:

Again, you were right, it was indeed 0008E83A that had the weird LOD model issue from my original post. There were so many placed close and on top of each other that I must have clicked on the one right next to it. Come to think of it, weird that the ones I misclicked have no LOD meshes assigned but the others do. From my experience (working on textures) these ancientruins and medievelpack assets can be very crude. The specific stone meshes are so simplistic they should act well as LOD meshes too heh.

Edit: Sorry, I think I get it now. Those stones have no LOD, DynDOLOD just grabbed the other LOD mesh because it has the same naming convention?

Expand  

Bethesda folder and file naming conventions stipulate that different assets never have the same filename. The DynDOLOD manual explains how automatic full model file name to LOD model matching works. It addition the CRC32 of full model can be used to bind a specific LOD model to a specific full model. The next DynDOLOD Resources 3 LE/SE versions will have a dedicated LOD model for the second rock02.nif. They will also have an LOD model updates for the building from the other post.

[RulerOfWorlds]

 

Hi Sheson, before I forget and do it wrong, imma do all the Logs first.

DynDOLOD bug report: None

TexGen Log: https://ufile.io/vhbkh43u (nothing in here, generated from quick in and out setting look up to make sure settings matches DynDOLOD options. Nothing located before that.)

TexGen Debug Log: https://ufile.io/4xede0ka (nothing in here, generated from quick in and out setting look up to make sure settings matches DynDOLOD options. Nothing located before that.)

DynDOLOD log: https://ufile.io/8nkdirse 

DynDOLOD debug log: https://filebin.net/q2l7uywle1i8lkdj

I'm having a problem with my mountains and trees using other meshes, and then when I approach it transfers to the high quality meshes (without fade). Comparison Pictures: https://imgur.com/a/74BwjiR the last 4 pictures are the best examples and are taken from walking 2 or 3 feet back and forth. This problem seems to be the same problem the user, Breaking Mountain, had here: 

 

I have reran DynDOLOD multiple times since the problem occured, no change. Problem still occurs on new games (see last 2 images). I don't think its a wild edit since not many of my mods touch mountains, although guess thats why its called "wild" edit. Loot reports no dirty plugins, I clean/uninstall any mods that are dirty. On a previous generation, I tried the mountain mesh rule: 

Mesh mask = mountains
LOD Level 4 = Level0
LOD Level 8 = Level0
LOD Level 16 = Level1 or Level2
Flags = VWD
Grid = Far LOD
Reference = Unchanged

Mountain (and tree) problem still existed. The fBlockLevel0Distance seen in the pictures 57000 ( fBlockLevel1Distance: 60,000) My usually play with fBlockLevel0Distance on 30,000. Increasing fblockLevel0Distance does make the problem happen further away, though it still happens (as expected) (and takes 5-10% of GPU more at 60k then 30k) . My uLargeRefLODGridSize is usually the default of 11, when changed to 5 as suggested, the problem still occured.

The only thing from that post I can't verify is bolded below

  On 10/22/2020 at 8:48 PM, sheson said:

Disable large references, set them to 5 to not have full models and LOD models show at the same time because of the bugs triggered by plugins from mods. If anything, use sane values for uLargeRefLODGridSize. Convert plugins causing large reference bugs to ESM - if possible. The DynDOLOD log lists the references/plugins.

Expand  

Another note is I did try a fresh ini by removing my current INIs, launching the launcher and then using the new skyrim.ini and skyrimpref.ini on my save, problem still occurred. Where in the DynDOLOD log does it list the refernces/plugins that need conversions? Although this may not be a large reference bug. The big question is how do I fix these mountains and trees? 

[mattski123]

  On 10/13/2021 at 11:21 AM, sheson said:

So this is a different reference than the other day.

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

Expand  

It didn't happen this time. But got this one:

[Window Title]
DynDOLOD

[Main Instruction]
LODGenx64.exe failed to generate object LOD for one or more worlds.

[Content]
Check for error messages in the listed LODGen log(s)

I pressed okay and it came up with:

[Window Title]
DynDOLOD

[Main Instruction]
Save DynDOLOD plugins, save plugins and zip output, exit DynDOLOD without saving, check the log?

[Content]
If 'Check log' is selected, the DynDOLOD plugins will be saved when DynDOLOD is closed.

https://easyupload.io/n7tf3q

I saved and exited. Would there be any issues in my game?

[sheson]

  On 10/14/2021 at 6:18 AM, RulerOfWorlds said:

I'm having a problem with my mountains and trees using other meshes, and then when I approach it transfers to the high quality meshes (without fade).

Expand  

As explained in the manual LOD starts beyond the uGridsToLoad or ulargeRefLODGridSize.

A cell has 4096 units. So the first LOD Level shows after about ~ 10240 and ~ 22528 units.

fBlockLevel0Distance=57000 and fBlockLevel1Distance=60000 are way to close together. It wouldn't be surprised if it showed LOD level 16 right after LOD Level 4 and skips LOD Level 8 on occasion.

Start the games launcher to set ultra settings. Then adjust only fBlockLevel0Distance to avoid it causing stuck object LOD. Use the DynDOLOD SkyUI MCM Settings page to adjust the distance in the game.

  On 10/14/2021 at 6:52 AM, mattski123 said:

It didn't happen this time. But got this one:

[Window Title]
DynDOLOD

[Main Instruction]
LODGenx64.exe failed to generate object LOD for one or more worlds.

[Content]
Check for error messages in the listed LODGen log(s)

I pressed okay and it came up with:

[Window Title]
DynDOLOD

[Main Instruction]
Save DynDOLOD plugins, save plugins and zip output, exit DynDOLOD without saving, check the log?

[Content]
If 'Check log' is selected, the DynDOLOD plugins will be saved when DynDOLOD is closed.

https://easyupload.io/n7tf3q

I saved and exited. Would there be any issues in my game?

Expand  

Why don't you check the LODGen logs as explained in the message, the DynDOLOD logs and the "Help for this message" help file to find out what error LODGen printed to its log files?

[19:21] <Error: LODGenx64.exe failed to generate object LOD for Blackreach. LODGenx64.exe returned 25B. Check D:\Mods\Mod packs\DynDOLOD\Logs\LODGen_SSE_Blackreach_log.txt>

[19:21] <Error: LODGenx64.exe failed to generate object LOD for DLC01FalmerValley. LODGenx64.exe returned 25B. Check D:\Mods\Mod packs\DynDOLOD\Logs\LODGen_SSE_DLC01FalmerValley_log.txt>

[19:21] <Error: LODGenx64.exe failed to generate object LOD for arnimaTheHollow. LODGenx64.exe returned 25B. Check D:\Mods\Mod packs\DynDOLOD\Logs\LODGen_SSE_arnimaTheHollow_log.txt>

[mattski123]

  On 10/14/2021 at 6:57 AM, sheson said:

As explained in the manual LOD starts beyond the uGridsToLoad or ulargeRefLODGridSize.

A cell has 4096 units. So the first LOD Level shows after about ~ 10240 and ~ 22528 units.

fBlockLevel0Distance=57000 and fBlockLevel1Distance=60000 are way to close together. It wouldn't be surprised if it showed LOD level 16 right after LOD Level 4 and skips LOD Level 8 on occasion.

Start the games launcher to set ultra settings. Then adjust only fBlockLevel0Distance to avoid it causing stuck object LOD. Use the DynDOLOD SkyUI MCM Settings page to adjust the distance in the game.

Why don't you check the LODGen logs as explained in the message, the DynDOLOD logs and the "Help for this message" help file to find out what error LODGen printed to its log files?

[19:21] <Error: LODGenx64.exe failed to generate object LOD for Blackreach. LODGenx64.exe returned 25B. Check D:\Mods\Mod packs\DynDOLOD\Logs\LODGen_SSE_Blackreach_log.txt>

[19:21] <Error: LODGenx64.exe failed to generate object LOD for DLC01FalmerValley. LODGenx64.exe returned 25B. Check D:\Mods\Mod packs\DynDOLOD\Logs\LODGen_SSE_DLC01FalmerValley_log.txt>

[19:21] <Error: LODGenx64.exe failed to generate object LOD for arnimaTheHollow. LODGenx64.exe returned 25B. Check D:\Mods\Mod packs\DynDOLOD\Logs\LODGen_SSE_arnimaTheHollow_log.txt>

Expand  

Sorry that was foolish of me to miss. Here's the logs: https://easyupload.io/v3fnad

I tried running this again but this time turned take ownership on, as I wasn't sure what kept not allowing access. I tried it again and here's those newer logs (I also have the requied redistibutables) keep in mind I'm doing all worlds: https://easyupload.io/67fmcc

[sheson]

  On 10/14/2021 at 7:43 AM, mattski123 said:

Sorry that was foolish of me to miss. Here's the logs: https://easyupload.io/v3fnad

I tried running this again but this time turned take ownership on, as I wasn't sure what kept not allowing access. I tried it again and here's those newer logs (I also have the requied redistibutables) keep in mind I'm doing all worlds: https://easyupload.io/67fmcc

Expand  

Why don't you take the time to read the log message yourself and to search for it on the forum?

Error accessing D:\Mods\SE\Data\meshes\clutter\blackreach\blackreachcrystalm03.nif Unable to read beyond the end of the stream.

There seems to be a problem with that NIF.
Check if it opens in NifSkope.
Find out which mod is the last to supply it. Reinstall it.
Run NIF through CAO.
If a NIF with that error is shipping with a mod but open fine in NifSkope, let me know which one it is.

https://stepmodifications.org/forum/topic/15606-dyndolod-300-alpha-47/page/108/?tab=comments#comment-249712