DynDOLOD 3.00 Alpha 173

[sheson]

11 hours ago, 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?

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]

7 hours ago, 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

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]

5 hours ago, 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

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]

3 hours ago, 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?

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]

31 minutes ago, 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

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]

2 hours ago, 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

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]

52 minutes ago, 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.

Ok. Thanks for the wonderful mod in any case!

[EazyH]

5 hours ago, 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.

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]

33 minutes ago, 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

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]

1 hour ago, 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.

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

Fixed the issue.

[sheson]

32 minutes ago, Abbot said:

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

Fixed the issue.

Setting that flag does not change the full model, the LOD model or if something has object LOD generated or not.

Generate LOD for the vanilla game with DynDOLOD 3 as is to test.

[sheson]

1 hour ago, 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

Read "Tree/Grass LOD Billboards" in docs/help/TexGenConfiguration.html to find out how TREE base records are selected for tree LOD billboard generation.

TexGen scans the currently installed plugins, and then uses the currently installed full model and the referenced full textures to generate the tree LOD billboards.

Check the log and especially the debug log for message regarding errors or skipped base records. The logs are the most important tool to understand the what and the why.

If you believe the output is missing billboards it should have generated, adjust the plugin data, fix any errors if there are any or force billboard generation as explained in the manual.
Using output that was generated for a different load order might not match with the current load order, e.g. different models/texture CRC32 will be reported by DynDOLOD.

[z929669]

19 minutes ago, EazyH said:

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?

@sheson Will correct me if any of my assumptions are wrong:

LTM has no 3D models, and it replaces several vanilla trees that Myrkvior also replaces (and also has the 3D models). Therefore, only tree billboards will be available using the 'winning' textures for the these trees. If LTM textures are wrong or have wrong paths, your logs will show the errors. The author supplies tree billboard1, but TexGen 3 should generate billboard1/2 even if the 3D models are missing (I think), so there should be billboard conflicts that TexGen output overwrites.

If you are using billboards for all tree mesh rules, then trees should look consistent (if object bounds are defined in the LTM plugin ... if not, then no TexGen billboards created I think, which may explain smaller output), but if you are using 3D trees mesh rules, you will have inconsistencies with tree LOD. For this reason, I would not use LTM with Mrykvior at this time until proper 3D models are available for LTM.

[Abbot]

19 minutes ago, sheson said:

Setting that flag does not change the full model, the LOD model or if something has object LOD generated or not.

Generate LOD for the vanilla game with DynDOLOD 3 as is to test.

Sorry, Sheson, but I'm not sure I understand.

Doing that gives me the problem that I have described?

[EazyH]

12 minutes ago, z929669 said:

@sheson Will correct me if any of my assumptions are wrong:

LTM has no 3D models, and it replaces several vanilla trees that Myrkvior also replaces (and also has the 3D models). Therefore, only tree billboards will be available using the 'winning' textures for the these trees. If LTM textures are wrong or have wrong paths, your logs will show the errors. The author supplies tree billboard1, but TexGen 3 should generate billboard1/2 even if the 3D models are missing (I think), so there should be billboard conflicts that TexGen output overwrites.

If you are using billboards for all tree mesh rules, then trees should look consistent (if object bounds are defined in the LTM plugin ... if not, then no TexGen billboards created I think, which may explain smaller output), but if you are using 3D trees mesh rules, you will have inconsistencies with tree LOD. For this reason, I would not use LTM with Mrykvior at this time until proper 3D models are available for LTM.

Thank you, I am following this for the most part and was wondering if hd trees would be simply created using the HD tree option in TexGen, since I know he has some settings for hd tree, though he used billboard 4 instead of Lvl 0, which I usually see. 
 

my current tree settings (And recommended for Myrkvior) was Lvl 0, Billboard 2, Billboard 2. So you’re saying essentially in its current form, I can’t simply use LTM to replace the conflicting trees in Myrkvior without running into issues? If I’m not mistaken, when he uses ultra tree in TexGen w/ BB4, doesn’t that make all trees 3D? What would stop the trees from being able to be 3D if used w/ Myrkvior? And if it’s a bit much to explain, feel free to let me know that too, as I admittedly am very green with some of this stuff