DynDOLOD 3.00 Alpha 190

[Abbot]

  On 7/20/2021 at 5:29 PM, sheson said:

If you use tfc to fly close, then LOD does not get replaced by the full model. It should be easy to make a close up screenshot of the LOD with TFC.

Check if what looks like scaffolding actually is static object LOD by disabling LOD with tll in console. If the wooden beams remain it means they might dynamic LOD or just full models.
In either case they should have reference form ids. In case they do and they are in a DynDOLOD login, look up the form IDs in xEdit. The reference have an EditiorID that typically starts with pluginname_formid.

If they have static object LOD that goes away with tll, then check what mods overwrite DynDOLOD Resources.

This almost looks like there is mod that replaces the cabin with different stages of rebuilding it.

Expand  

The wooden beams remain if using tll but their form IDs and their ref IDs are from base Skyrim and none of them are touched by DynDOLOD

EDIT: So I've noticed that DynDOLOD v2.96 modifies the "ShackWall" STAT entries (form IDs: 5CCDE , 5CCDF , 5CCE0 , 5CCE1 , 5CCE2 , 5CCE3 ) by attributing to them the "Has Distant LOD" flag, while DynDOLOD 3 does NOT do that. Could this be the culprit?

Edited July 20, 2021 by Abbot

[EazyH]

  On 7/20/2021 at 12:32 PM, EazyH said:

I will take a look at the plug-in bounds once I get home. From what I understand from Sheson’s post, I should’ve been able to just run DynDOLOD and update atlas, but the results are not what was expected. The grass textures are still from cathedral brown grass, and with the Direct, Ambient, and ini settings recommended. I am using Wiz’s Enb for Obsidian, and the grass admittedly looks better when the enb is toggled off (but I think that’s because of how muted colors are without ENB) so not sure what’s going on. Only issue with the picture is I forgot to turn off LODGen terrain meshes/textures before going in game and those were built w/ green tundra installed. I believe that was ticked off when generating Grass with DynDOLOD though (I don’t think it matters, but I usually do just to be safe). Plan to do that at the end when I finalize the grass I’ll be using, since originally the plan was for brown, but since I was unable to get it right I haven’t put much time into tweaking the terrain LOD since it’s easy enough. I’m using no Northern Cathedral Landscapes but don’t believe it touches the tundra which is where I’ve been doing the testing.

 

it’s becoming a pattern where I get home after work and say “today will be the day, the day I finally play…“ Just for that to not be the case because I’m trying to get things perfect lol

Expand  

I took a look at the plug-in and didn’t see anything conflicting with tundra grass or editing any bounds. I am using the Northern Cathedral Grass mashup, but there should be no conflicts with tundra/field grass that would cause issues from what I can tell. I’ve reinstalled Cathedral Landscapes again, making sure to select the brown tundra, I am even rerunning grass cache in Tamriel to be EXTRA safe, and I will try again with your values, except far less blue, but still, such a drastic difference in grass LOD color seems odd. And the fact that it’s not necessarily a quick process doesn’t make it easier haha. Beauty is pain, right?

 

anyone at least have any ideas what could cause this to be such a drastic change from your included values? Is it only different textures (Which shouldn’t be a part of the problem) that could cause the issue? I am using obsidian weathersm right now, but I don’t think it would have such an impact on grass LOD color, even if not used exactly with Cathedral Weather

Edited July 20, 2021 by EazyH

[EazyH]

I wanted to try little tree mod out in conjunction with Myrkvior, my current tree mod for a new look as a reward of sorts for dealing with DynDOLOD so much recently. Seems simple enough, little tree ESP only alters the tree record, which I let overwrite the main Myrkvior plug in, and those resources overwrite Myrkvior’s. Boom, all positions should still be as intended and LTM trees should be replacing the conflicted trees!

What throws me off however, was generating TexGen and DynDOLOD.. would there be any issues using the settings on Myrkvior’s page? Level 4: Level 0, Level 8: Billboard 2, Lvl 16: Billboard 2, Lvl 32: None, VWD. His settings for DynDOLOD were wayy diff, ultra trees w/ billboard 4 all across 🤨
I figured I should be able to still use those settings, and thought DynDOLOD should in theory make the hd trees and comparable billboard 2s. But then I saw how drastically different his DynDOLOD 3 settings are. I still used the tree settings in TexGen I had already had success with. So now I’m worrying if it did not generate trees for treemod, because I also don’t see a folder with this mods name on it (tho it may very well be in skyrim/DLC1/Dlc2 folder)

And it may, but I noticed my TexGen file was a good deal smaller, the terrain and DynDOLOD folders, so I wanted to be sure all tree LOD’s would still be generated as intended with those settings? any reason you folks can think of for this? Perhaps his trees are better optimized, hence the much smaller file size? I also switched to 11 pixels from 8 pixels in TexGen per the Steps guide If that could make a difference

[EazyH]

  On 7/21/2021 at 1:26 AM, EazyH said:

I wanted to try little tree mod out in conjunction with Myrkvior, my current tree mod for a new look as a reward of sorts for dealing with DynDOLOD so much recently. Seems simple enough, little tree ESP only alters the tree record, which I let overwrite the main Myrkvior plug in, and those resources overwrite Myrkvior’s. Boom, all positions should still be as intended and LTM trees should be replacing the conflicted trees!

What throws me off however, was generating TexGen and DynDOLOD.. would there be any issues using the settings on Myrkvior’s page? Level 4: Level 0, Level 8: Billboard 2, Lvl 16: Billboard 2, Lvl 32: None, VWD. His settings for DynDOLOD were wayy diff, ultra trees w/ billboard 4 all across 🤨
I figured I should be able to still use those settings, and thought DynDOLOD should in theory make the hd trees and comparable billboard 2s. But then I saw how drastically different his DynDOLOD 3 settings are. I still used the tree settings in TexGen I had already had success with. So now I’m worrying if it did not generate trees for treemod, because I also don’t see a folder with this mods name on it (tho it may very well be in skyrim/DLC1/Dlc2 folder)

And it may, but I noticed my TexGen file was a good deal smaller, the terrain and DynDOLOD folders, so I wanted to be sure all tree LOD’s would still be generated as intended with those settings? any reason you folks can think of for this? Perhaps his trees are better optimized, hence the much smaller file size? I also switched to 11 pixels from 8 pixels in TexGen per the Steps guide If that could make a difference

Expand  

OK, interestingly enough, there are 60 files from my previous TexGen that did not generate for some reason… some of them are srgtreepineforestdead05, sfopineforest05, letreepineforestdeadsnow03, and multiple files of those. I wonder why they did not generate… Perhaps there is a rule not seen that caused it to miss some if looking at Myrkvior last..? I assume they are part of Myrkvior’s mix, since there’s “sfo” which I believe is a Skyrim Flora Overhaul which I don’t have installed so it likely came from there. What I’m thinking is maybe I grab those 60 files, put them in a separate mod, and run DynDOLOD with all those textures… wondering if it would then place everything correctly?

Any insight from anyone knowledgeable would be greatly appreciated

[EazyH]

I was able to isolate the 60 files that for whatever reason we’re not generated, and put them into a folder called DynDOLOD addtnl textures for now. I originally, I was going to re-run DynDOLOD, w/ The addtnl files enabled, but then I thought about the tree report. Would it be necessary to go through the recent tree report that was included in the LOD generation and find any differences between the tree reports so that they can be corrected? I take it they are necessary when running DynDOLOD and the textures alone are not enough ?

 

I did try rerunning TexGen again and got the same result. About 100 MB missing that likely belong to those files from before I installed LTM. I just don’t understand why they wouldn’t be generated. This should change nothing about tree placement or variety. The only conflicts in the ESP are vanilla tree models, which overwrite the conflicting vanilla treemodels in Myrkvior. Those are the only records in the ESP. Other than that, it’s resources overwrite conflicting trees in Myrkvior, and that should be it. I would expect everything else not conflicting would still generate properly?

 

[sheson]

  On 7/20/2021 at 6:57 PM, Abbot said:

The wooden beams remain if using tll but their form IDs and their ref IDs are from base Skyrim and none of them are touched by DynDOLOD

EDIT: So I've noticed that DynDOLOD v2.96 modifies the "ShackWall" STAT entries (form IDs: 5CCDE , 5CCDF , 5CCE0 , 5CCE1 , 5CCE2 , 5CCE3 ) by attributing to them the "Has Distant LOD" flag, while DynDOLOD 3 does NOT do that. Could this be the culprit?

Expand  

The HasDistantLOD flag does not change models/textures.

The way plugins can change things is either by updating/replacing  the references to use different base records, base records are updated to define different models or models themselves are being replaced.

If you see references/base records from vanilla Skyrim, how is what you see a problem with DynDOLOD?

[sheson]

  On 7/20/2021 at 10:55 PM, EazyH said:

I took a look at the plug-in and didn’t see anything conflicting with tundra grass or editing any bounds. I am using the Northern Cathedral Grass mashup, but there should be no conflicts with tundra/field grass that would cause issues from what I can tell. I’ve reinstalled Cathedral Landscapes again, making sure to select the brown tundra, I am even rerunning grass cache in Tamriel to be EXTRA safe, and I will try again with your values, except far less blue, but still, such a drastic difference in grass LOD color seems odd. And the fact that it’s not necessarily a quick process doesn’t make it easier haha. Beauty is pain, right?

 

anyone at least have any ideas what could cause this to be such a drastic change from your included values? Is it only different textures (Which shouldn’t be a part of the problem) that could cause the issue? I am using obsidian weathersm right now, but I don’t think it would have such an impact on grass LOD color, even if not used exactly with Cathedral Weather

Expand  

TexGen uses the installed full textures when it generates LOD billboards. The preview can be used to check the visuals.
DynDOLOD uses the installed LOD billboards when creating the object LOD atlas.
The INI grass brightness settings are applied when generating object LOD meshes. If the RGB values are equal the color tone does not change.
The second post explains how to update textures or how to update one object LOD mesh for quicker tests.

[sheson]

  On 7/21/2021 at 1:26 AM, EazyH said:

I wanted to try little tree mod out in conjunction with Myrkvior, my current tree mod for a new look as a reward of sorts for dealing with DynDOLOD so much recently. Seems simple enough, little tree ESP only alters the tree record, which I let overwrite the main Myrkvior plug in, and those resources overwrite Myrkvior’s. Boom, all positions should still be as intended and LTM trees should be replacing the conflicted trees!

What throws me off however, was generating TexGen and DynDOLOD.. would there be any issues using the settings on Myrkvior’s page? Level 4: Level 0, Level 8: Billboard 2, Lvl 16: Billboard 2, Lvl 32: None, VWD. His settings for DynDOLOD were wayy diff, ultra trees w/ billboard 4 all across 🤨
I figured I should be able to still use those settings, and thought DynDOLOD should in theory make the hd trees and comparable billboard 2s. But then I saw how drastically different his DynDOLOD 3 settings are. I still used the tree settings in TexGen I had already had success with. So now I’m worrying if it did not generate trees for treemod, because I also don’t see a folder with this mods name on it (tho it may very well be in skyrim/DLC1/Dlc2 folder)

And it may, but I noticed my TexGen file was a good deal smaller, the terrain and DynDOLOD folders, so I wanted to be sure all tree LOD’s would still be generated as intended with those settings? any reason you folks can think of for this? Perhaps his trees are better optimized, hence the much smaller file size? I also switched to 11 pixels from 8 pixels in TexGen per the Steps guide If that could make a difference

Expand  

DynDOLOD 3 is an alpha version to test settings and to find and report bugs or problems.

Which billboard type you use for which LOD level depends on your preference. Billboard1 or Billboard4 are the best suited for HD billboards with normal maps.
If you define to 3D tree LOD models for LOD level 4 depends on your preference. 

The path and file name of LOD billboards are defined by the master plugin and form id that adds the tree base record and the model filename defined by the winning overwrite.

The size of files in a folder is not really a meaningful metric for anything. The log tells you which object LOD textures and which LOD billboards are being created.
TexGen generates textures for the current load order. If the load order changes and depending on the TexGen settings it might generate more or less files.

As docs/help/TexGenConfiguration.html explains, the bounds defined on the base record define if a tree/grass is suitable for automatic billboard generation. Billboards can be forced to be generated or not via config files, too.

[Abbot]

  On 7/21/2021 at 5:54 AM, sheson said:

The HasDistantLOD flag does not change models/textures.

The way plugins can change things is either by updating/replacing  the references to use different base records, base records are updated to define different models or models themselves are being replaced.

If you see references/base records from vanilla Skyrim, how is what you see a problem with DynDOLOD?

Expand  

Sheson, I checked with a vanilla game and the problem happens there as well, thought it is much less visible - the cabin is "complete" when the player looks at it from the Guardian Stones in Vanilla - but the problem is that with DynDOLOD v2.x I CAN see the full Cabin from far away, while I CANNOT do that with DynDOLOD v 3, just like in Vanilla...

I thought about reporting this issue so that you could iron it out and have a fully functioning final release of version 3...

The problem may be mine specifically, but I don't see how since I used the same exact load order and the same exact left pane of MO2 for generating both DynDOLOD v2.x and DynDOLOD v3.x...

If I could ask another question: leaving the far away model of the Cabin  aside, only in regards to the worse performance with DynDOLOD in respect to Vanilla (the Cabin disappearing at close distance), would you say that mine may be a memory problem? If that is the problem , and if it isn't too much to ask, why DynDOLOD v3.x would use more memory than DynDOLOD v.2.x? I've generated 3D tree models with both

Edited July 21, 2021 by Abbot

[Abbot]

  On 7/21/2021 at 9:14 AM, Abbot said:

and if it isn't too much to ask, why DynDOLOD v3.x would use more memory than DynDOLOD v.2.x? I've generated 3D tree models with both

Expand  

High settings in v. 3.x are more impactful than high settings in v. 2.x? I should say that I didn't notice significant FPS losses with v. 3.x

Edited July 21, 2021 by Abbot

[sheson]

  On 7/21/2021 at 9:14 AM, Abbot said:

Sheson, I checked with a vanilla game and the problem happens there as well, thought it is much less visible - the cabin is "complete" when the player looks at it from the Guardian Stones in Vanilla - but the problem is that with DynDOLOD v2.x I CAN see the full Cabin from far away, while I CANNOT do that with DynDOLOD v 3, just like in Vanilla...

I thought about reporting this issue so that you could iron it out and have a fully functioning final release of version 3...

The problem may be mine specifically, but I don't see how since I used the same exact load order and the same exact left pane of MO2 for generating both DynDOLOD v2.x and DynDOLOD v3.x...

If I could ask another question: leaving the far away model of the Cabin  aside, only in regards to the worse performance with DynDOLOD in respect to Vanilla (the Cabin disappearing at close distance), would you say that mine may be a memory problem? If that is the problem , and if it isn't too much to ask, why DynDOLOD v3.x would use more memory than DynDOLOD v.2.x? I've generated 3D tree models with both

Expand  

There are probably no LOD models for the wooden beams, that is why they have no LOD.
You reported that the wooden beams are all vanilla records.
You need to find out why in one load order those vanilla records show cabin models with walls and why in the other load order the same? vanilla records show wooden beams.
You reported that none of those vanilla records are being changed by DynDOLOD.

When I generate LOD for vanilla Skryim with DynDOLOD 3, I see the the usual cabin close up and for LOD.

The memory question is somewhat vague. See the first post,  changelog and the included manual to learn about the changes and feature updates between versions.
It is very likely there are more or higher resolution object LOD and billboard textures with the default settings. For example, rendered object LOD textures can have up to 2k resolution compared to the 256 vanilla textures.

[Abbot]

  On 7/21/2021 at 11:33 AM, sheson said:

There are probably no LOD models for the wooden beams, that is why they have no LOD.
You reported that the wooden beams are all vanilla records.
You need to find out why in one load order those vanilla records show cabin models with walls and why in the other load order the same? vanilla records show wooden beams.
You reported that none of those vanilla records are being changed by DynDOLOD.

When I generate LOD for vanilla Skryim with DynDOLOD 3, I see the the usual cabin close up and for LOD.

The memory question is somewhat vague. See the first post,  changelog and the included manual to learn about the changes and feature updates between versions.
It is very likely there are more or higher resolution object LOD and billboard textures with the default settings. For example, rendered object LOD textures can have up to 2k resolution compared to the 256 vanilla textures.

Expand  

Ok. Thanks for the wonderful mod in any case!

[EazyH]

  On 7/21/2021 at 6:33 AM, sheson said:

 

As docs/help/TexGenConfiguration.html explains, the bounds defined on the base record define if a tree/grass is suitable for automatic billboard generation. Billboards can be forced to be generated or not via config files, too.

Expand  

Thank you, I figured this may be the case. So would there be any issue with manually adding files that for whatever reason were not automatically generated, to the TexGen output? I kept my previous TexGen output and isolated the Myrkvior files that for whatever reason were not generated (some SFO, SGR, and letreepine textures that wouldn’t be vanilla trees from little tree mod). They don’t conflict with any other LOD textures in the  order.

 

I was thinking it should be enough to add those files to my TexGen output and then re-run DynDOLOD. The TexGen log generated should not matter, should it? From what I understand, it’s more like a receipt showing what was actually generated?

 

Thanks

[EazyH]

  On 7/21/2021 at 12:22 PM, EazyH said:

Thank you, I figured this may be the case. So would there be any issue with manually adding files that for whatever reason were not automatically generated, to the TexGen output? I kept my previous TexGen output and isolated the Myrkvior files that for whatever reason were not generated (some SFO, SGR, and letreepine textures that wouldn’t be vanilla trees from little tree mod). They don’t conflict with any other LOD textures in the  order.

 

I was thinking it should be enough to add those files to my TexGen output and then re-run DynDOLOD. The TexGen log generated should not matter, should it? From what I understand, it’s more like a receipt showing what was actually generated?

 

Thanks

Expand  

edit: I also noticed these textures from Little Tree Mod and I wondered if these would impact LOD generation for some of those files that were not generated for some reason?

 

Textures\

Landscape\

trees\

northern hemispheres

Deadatlas_normal.dds, Deadatlas_diffuse.dDS, pine atlas_a normal.DDS, pineatlas_rl.dds, pineatlas_diffuse.dds, pinebark.dds, pinebark_n.dds, snowbark_atlas.dds, and snowbark_atlas_n.dds

Is there anything about these textures that would cause some of Myrkvior’s unrelated textures not to be generated? Perhaps these textures cover a broad range of meshes, thus making some of Myrkvior’s redundant?

[Abbot]

  On 7/21/2021 at 11:33 AM, sheson said:

There are probably no LOD models for the wooden beams, that is why they have no LOD.
You reported that the wooden beams are all vanilla records.
You need to find out why in one load order those vanilla records show cabin models with walls and why in the other load order the same? vanilla records show wooden beams.
You reported that none of those vanilla records are being changed by DynDOLOD.

When I generate LOD for vanilla Skryim with DynDOLOD 3, I see the the usual cabin close up and for LOD.

The memory question is somewhat vague. See the first post,  changelog and the included manual to learn about the changes and feature updates between versions.
It is very likely there are more or higher resolution object LOD and billboard textures with the default settings. For example, rendered object LOD textures can have up to 2k resolution compared to the 256 vanilla textures.

Expand  

So I have NO IDEA how or why, but giving the "HasDistantLOD" flag to the following records: https://imgbox.com/v8F8oC00

Fixed the issue.