DynDOLOD 3.00 Alpha 182

[z929669]

@sheson

Per the doc, to modify 'fullness' of tree branches in Level0-2 statics, it is suggested that the NiAlphaProperty alpha threshold should be modified rather than the alpha in the BSLightingShaderProperty. I am not noticing any change in Nifskope or in game after changing alpha threshold in NiAlphaProperty of the static from 140 to 0. I also am guessing that the value of 140 is interpreted as 128, due to the cap.

I am changing this in the static model without re-running DynDOLOD ... must I regenerate via DynDOLOD to see the change in game?

[sheson]

1 hour ago, z929669 said:

@sheson

Per the doc, to modify 'fullness' of tree branches in Level0-2 statics, it is suggested that the NiAlphaProperty alpha threshold should be modified rather than the alpha in the BSLightingShaderProperty. I am not noticing any change in Nifskope or in game after changing alpha threshold in NiAlphaProperty of the static from 140 to 0. I also am guessing that the value of 140 is interpreted as 128, due to the cap.

I am changing this in the static model without re-running DynDOLOD ... must I regenerate via DynDOLOD to see the change in game?

LOD is generated for the current load order with the LOD assets that are installed at the time. In particular, object LOD are a collection of supermeshes made from combining LOD models. The generated object LOD files (which are just large NIF models) are loaded and placed in the game.
If the load order or the LOD assets change used for LOD generation change, LOD needs to be generated again for the new load order and/or assets to be show in generated LOD.

The alpha setting on the shader defines the transparency of the surface regardless of any alpha information in the texture.

As explained in the manual, in case a model used for LOD generation has a NiAlphaProperty, the threshold value of it is used to adjust the alpha of the input texture (and the mipmaps that are generated for it with alpha-to-coverage) to account for the fixed threshold of LOD while the texture is added to the LOD atlas texture. the threshold is quantized into 16 steps to prevent ending up with too many similarly adjusted textures.

For the changed thresholds in the LOD models to have an effect on the generated LOD meshes and textures, the LOD meshes and textures need to be generated after changing the LOD models.

[z929669]

1 hour ago, sheson said:

The alpha setting on the shader defines the transparency of the surface regardless of any alpha information in the texture.

As explained in the manual, in case a model used for LOD generation has a NiAlphaProperty, the threshold value of it is used to adjust the alpha of the input texture (and the mipmaps that are generated for it with alpha-to-coverage) to account for the fixed threshold of LOD while the texture is added to the LOD atlas texture. the threshold is quantized into 16 steps to prevent ending up with too many similarly adjusted textures.

Alright, the need to regen makes sense. I wasn't thinking comprehensively. The 3D statics textures are not used directly but rather in the supermeshes (which are used directly), so change to any aspect of the static mesh must then be incorporated into the supermesh during LOD(re)Gen to be resolved in game. Sound correct?

Regarding alpha (sorry to rehash what is probably 'basic' prerequisite knowledge):

• There are potentially two definitions in the static model.
  1. One inherent to any textures referenced by the model
  2. One defined in the BSLightingShaderProperty (what I assume you mean by "alpha setting on the shader")
• NiAlphaProperty alpha threshold value affects #1 and NOT #2?
• #2 on the 3D static is binary, and should only be 0 or 1?
• Alpha threshold value/16? If the threshold is 128, 64, or 0, what are the relative impacts to the crown appearance in game?

 

[z929669]

So unrelated to my follow-up Qs just above, I have questions on LODgen efficiency for testing. I want to only generate and use 3D statics and not tree billboards (so that I can determine if any 3D statics are borked without having to guess if I am looking at a tree billboard). I know I need to tick "Tree/Gass LOD Billboards" & 'Render' option in TexGen, but which of the two top options is necessary? I'm also unsure what these settings correspond to in DynDOLOD:

[sheson]

2 hours ago, z929669 said:

Alright, the need to regen makes sense. I wasn't thinking comprehensively. The 3D statics textures are not used directly but rather in the supermeshes (which are used directly), so change to any aspect of the static mesh must then be incorporated into the supermesh during LOD(re)Gen to be resolved in game. Sound correct?

Regarding alpha (sorry to rehash what is probably 'basic' prerequisite knowledge):

• There are potentially two definitions in the static model.
  1. One inherent to any textures referenced by the model
  2. One defined in the BSLightingShaderProperty (what I assume you mean by "alpha setting on the shader")
• NiAlphaProperty alpha threshold value affects #1 and NOT #2?
• #2 on the 3D static is binary, and should only be 0 or 1?
• Alpha threshold value/16? If the threshold is 128, 64, or 0, what are the relative impacts to the crown appearance in game?

 

The NiAlphaPropertety requires/works with the alpha channel of the texture.

The Alpha setting on the shader defines  how how opaque the entire texture is regardless of its alpha channel.
It can have any value between 0 and 1, even in LOD. It is always set to 1 in the LOD  meshes.

You adjust the threshold in the LOD model asset. Since this can not be done in the generated LOD meshes, DynDOLOD adjusts the threshold in the LOD texture, so it works with the hardcoded LOD meshes threshold of 128.

The impact is that the threshold of the full model is used to adjust the alpha channel of the input full texture when it is being added to the LOD texture atlas and becomes a LOD texture, so that whatever pixels in the full model are transparent/opaque are also transparent/opaque in the LOD despite the LOD having a hardcoded threshold of 128.

 

[sheson]

2 hours ago, z929669 said:

So unrelated to my follow-up Qs just above, I have questions on LODgen efficiency for testing. I want to only generate and use 3D statics and not tree billboards (so that I can determine if any 3D statics are borked without having to guess if I am looking at a tree billboard). I know I need to tick "Tree/Gass LOD Billboards" & 'Render' option in TexGen, but which of the two top options is necessary? I'm also unsure what these settings correspond to in DynDOLOD:

I suggest to read the included TexGen manual and help.
The first options has been available for years and still generates a select list of object LOD textures.
As has been discussed over and over again for years, that first option can not update rendered object LOD textures. Now with the addition of the second option, a select list of rendered object LOD can updated as well.
"Stitched object LOD textures are direct derivativs of resized full textures."
"Rendered object LOD textures are rendered from special models in the ..\DynDOLOD\Edit Scripts\DynDOLOD\Render\Objects\ folder."

DynDOLOD will use whatever object LOD textures are currently installed in the load order. If they are not updated with TexGen, some will still be vanilla, some will be from DynDOLOD Resources for vanilla and some from mods.

All options that are enabled by default are "necessary" so that default object LOD and tree LOD generation use the best possible  textures for the current load order. 

Unless you have a 4k or 8k monitor you not need to set 1024 in TexGen for the stitched or rendered object LOD textures.

Remember that DynDOLOD 3 ALPHA is work in progress.  I still need to update the texts, since nobody really pays much attention to t he manuals.

From the help: "This sets the typical base size of the generated object LOD textures. The default is 256."
Currently the generated stitched/rendered object textures can be anything from 32 to 2k with the base of 256.
The defaults are good for a screen resolution of 1440p and lower.

The stitched and rendered object LOD textures will probably also get a max texture size dropdown like the billboards.

The dropdowns in DynDOLOD say "Max tile size..."
From the help:
"Max tile size LOD sets the maximum resolution a single object LOD texture can occupy on the object LOD texture atlas."
 "Max tile size full sets the maximum resolution a single full texture can occupy on the object LOD texture atlas."

If a texture is larger, it is shrunk to the max tile size when it is added to the texture atlas.

Again, the default are supposed to be good for 1440p.

In a future update I plan to add more explanations to the manual, including how to determine live in the game the best resolution for a LOD texture in addition to the more mathematical explanations for billboards.

[z929669]

Great responses. Thanks a LOT for taking the time.

I have read through all of the relevant manuals by now, but I can get hung up on phraseology and semantics, so sometimes seeing it explained in a different or familiar context really helps.

The good news is that I think I am picking it up with your continued responses and can share what I know likewise ... without spreading misinformation intentionally or otherwise!

[patriklannebrink]

Having some issues using Dyndolod 3 for SSE (texgen works fine) where it says (Atleast this is how i interpret it) I'm missing files from some mods? Jedi Trees instructions said to use Texgen to generate billboards so I'm not sure what the issue is.

https://pastebin.com/J8DCjReg

Is this an issue or something I can ignore, because it seems like some trees do infact not have billboards (And I'm pretty sure its the Jedi Trees ones) 

Edited April 23, 2021 by patriklannebrink

[z929669]

I would look for those files in those mods and see why they are not loaded. Seems like you either have a mod(s) disabled or do not have a required mod installed that is expected by another mod. Just as likely, the mod files referenced by the plugins are not in the mod(s) ... i.e., poor housekeeping by mod author. As long as DynDOLOD finishes successfully, it may not matter at all (if they are just junk refs in the plugin(s)).

sheson may have other advice, but you can check the problem mods in the meantime and look at those mods bug reports on Nexus.

[sheson]

1 hour ago, patriklannebrink said:

Having some issues using Dyndolod 3 for SSE (texgen works fine) where it says (Atleast this is how i interpret it) I'm missing files from some mods? Jedi Trees instructions said to use Texgen to generate billboards so I'm not sure what the issue is.

https://pastebin.com/J8DCjReg

Is this an issue or something I can ignore, because it seems like some trees do infact not have billboards (And I'm pretty sure its the Jedi Trees ones) 

Upload entire log files not just parts of it. Use search to find posts that might already answer  questions. For example this post:

"Errors typically need to be fixed. They prevent LOD generation for the mentioned stuff or in general. Warnings typically should be fixed if possible, because of good practice or because they prevent the desired outcome."

Based on the posted log lines there is no issue using DynDOLOD. It seems to work as intended and reports problems in the load order.

Missing meshes can cause CTD or red exclamation marks in the game. DynDOLOD reports them and then will ignore the base records and any references using them. So in case it is an object that could have had LOD, it won't.

Normal textures should end in *_n.dds. This check helps to find typos or accidentally setting the diffuse as normal texture. It is highly beneficial and best practice for example for better compatibility with other mods/tools to adhere to Bethesda file naming conventions.

[z929669]

@sheson You may find this interesting. Not sure how much performance testing you have done in the past.

The following is pure apples-apples compare on my system after painstakingly preparing LOD tree statics from Myrkvior. This mod has 150 trees, and many are custom in addition to full vanilla replacement. I think it makes for one of the best candidates for performance compares, particularly with respect to full vs hybrid trees. I find hybrids to be twice as tedious to create as full, and with DynDOLOD 2.xx, it was 3x more tedious, IMHO. This analysis compares full to hybrid Myrkvior with all else remaining equal. Tested on clean runs of LODGen (same terrain and occlusion, different DynDOLOD). The avg FPS is a bit low, since I am running ENB and also compared only statics (all trees for LOD4/8/16 used Level0/1/2, respectively). I also used the recommended TexGen/DDL "max size" = 256 for all textures.

Each run involved me flying around 'slowly' across all regions of Tamriel using same route. Each run is 10-20 min long:

FULL

HYBRID

My system specs are linked in my sig.

Given that this is a fairly meticulous compare (all variables carefully throttled besides tree type and non-specific random factors), I am fairly confident that the same relative differences would be apparent on just about any modern PC, but there could be hardware factors that could deferentially impact performance of essentially # of NIF polygons rendered (my assumption about the brass-tax diff between full and hybrid models).

This is good news, because I can create full hybrids much faster and with fewer opportunities for error.

Your thoughts?

[sheson]

1 hour ago, z929669 said:

@sheson You may find this interesting. Not sure how much performance testing you have done in the past.

The following is pure apples-apples compare on my system after painstakingly preparing LOD tree statics from Myrkvior. This mod has 150 trees, and many are custom in addition to full vanilla replacement. I think it makes for one of the best candidates for performance compares, particularly with respect to full vs hybrid trees. I find hybrids to be twice as tedious to create as full, and with DynDOLOD 2.xx, it was 3x more tedious, IMHO. This analysis compares full to hybrid Myrkvior with all else remaining equal. Tested on clean runs of LODGen (same terrain and occlusion, different DynDOLOD). The avg FPS is a bit low, since I am running ENB and also compared only statics (all trees for LOD4/8/16 used Level0/1/2, respectively). I also used the recommended TexGen/DDL "max size" = 256 for all textures.

Each run involved me flying around 'slowly' across all regions of Tamriel using same route. Each run is 10-20 min long:

FULL

 

HYBRID

 

My system specs are linked in my sig.

Given that this is a fairly meticulous compare (all variables carefully throttled besides tree type and non-specific random factors), I am fairly confident that the same relative differences would be apparent on just about any modern PC, but there could be hardware factors that could deferentially impact performance of essentially # of NIF polygons rendered (my assumption about the brass-tax diff between full and hybrid models).

This is good news, because I can create full hybrids much faster and with fewer opportunities for error.

Your thoughts?

The load order seems to have issues if the FPS is under 60. Use a pure and defined vanilla setup to test things, with nothing else that limits or hinders performance. With vsync disabled, obviously. The graphs do not not show GPU % usage.

Obviously it is silly to use full models for all tree LOD models, especially now that creating hybrids became as simple as just saving the full model twice into trunk and crown. Every triangle saved means smaller files size, less resource usage, less memory usage, less draw calls that can be used for something else. For the few 3D tree LOD models that reveal so much (twisted) trunk and branches that they actually need 3D trunks and for Grass LOD for example. And the 8k skin and mandatory body physics...

[z929669]

Your logic makes perfect sense, particularly with respect to file size. But it is still much more work to create hybrids, IMO., Especially since *most* trunks us relatively few triangles anyway. I suppose 16 triangles is better than 50 though ...

Above load order doesn't have issues. It's just modded and running ENB. I wanted to test under a (my) fully modded setup. I do see value in testing with nothing but vanilla hybrid/full trees and no mods but the minimal 'fix' and unofficial patches. Obviously no post-processing in that case.

[Phlunder]

Just now got around to testing 3.0 alpha, great work! The addition of the TexGen renderer is incredible, saves so much work when using custom textures. For object LOD, this looked great so far in my testing. Tree LOD billboard creation also works flawlessly, I just ran into a small thing while playing around with it. The atlas is saved with mip-maps, which has some downsides in how those distant objects with these kind of alphas display. Especially the aspens look very "blurred" for lack of a better word, they loose a lot of detail. Resaving the atlas without mip maps fixes that. The testing was done on vanilla trees with vanilla textures. Would it be possible to add an option to save the tree LOD atlas without mip maps directly? Maybe its also an issue with alpha testing/threshold values, not sure.

Edited April 27, 2021 by Phlunder

[sheson]

2 hours ago, Phlunder said:

Just now got around to testing 3.0 alpha, great work! The addition of the TexGen renderer is incredible, saves so much work when using custom textures. For object LOD, this looked great so far in my testing. Tree LOD billboard creation also works flawlessly, I just ran into a small thing while playing around with it. The atlas is saved with mip-maps, which has some downsides in how those distant objects with these kind of alphas display. Especially the aspens look very "blurred" for lack of a better word, they loose a lot of detail. Resaving the atlas without mip maps fixes that. The testing was done on vanilla trees with vanilla textures. Would it be possible to add an option to save the tree LOD atlas without mip maps directly? Maybe its also an issue with alpha testing/threshold values, not sure.

TreeLODGenerateMipMaps=0 in the DynDOLOD INI