DynDOLOD 3.00 Alpha 190

[sheson]

  On 8/27/2022 at 3:40 PM, DoubleYou said:

I left NiAlphaProperty at 128 for all tests. I simply changed out the full texture with the provided texture in each case. Let me audit my screenshots to ensure that I have this in the right order. I think I mixed up the first two somehow.

Expand  

The models that use the orginal/not adjusted texture 128.dds should have an alpha threshold of 224, while the models that use adjusted 224_* textures should have an alpha property of 128 - the one LOD is hardcoded to use.

[DoubleYou]

  On 8/27/2022 at 3:43 PM, sheson said:

The models that use the orginal/not adjusted texture 128.dds should have an alpha threshold of 224, while the models that use adjusted 224_* textures should have an alpha property of 128 - the one LOD is hardcoded to use.

Expand  

Okay. Let me get this for you. Please see my edit though, as I mixed up 1 and 2 in my previous post accidentally.

[DoubleYou]

1. Original texture from mod with 128 NiAlphaProperty
2. 128.dds with 224 NiAlphaProperty
3. 244_new.dds with 128 NiAlphaProperty
4. 244_old.dds with 128 NiAlphaProperty
5. 128.dds with 128 NiAlphaProperty

1. Original texture from mod with 128 NiAlphaProperty
2. 128.dds with 224 NiAlphaProperty
3. 244_new.dds with 128 NiAlphaProperty
4. 244_old.dds with 128 NiAlphaProperty
5. 128.dds with 128 NiAlphaProperty

[Mephitic]

I humbly apologize for interjecting here (this is a fascinating and valuable discussion) with an update on my end.

I reverted TexGen settings to those listed in the 2.0 version of the guide.

And DynDOLOD to settings in the default DynDOLOD_SSE.ini and and also the generation settings in version 2.0 of the guide.

; grass LOD brightness multipliers
GrassBrightnessTopR=0.400
GrassBrightnessTopG=0.445
GrassBrightnessTopB=0.450
; make bottom darker to fake shadowing
GrassBrightnessBottomR=0.200
GrassBrightnessBottomG=0.223
GrassBrightnessBottomB=0.225

And this is the result. (back to where I started, it appears)

Without enhancing my understanding of exactly what happens when any of these settings are changed, I'm satisfied with the look for now.

[edit] I neglected to mention (though it may be clear from the fact I'm using cached grass) I'm using game engine version 1.5.97

Edited August 27, 2022 by Mephitic
Added game version info

[sheson]

  On 8/27/2022 at 3:57 PM, DoubleYou said:

1. Original texture from mod with 128 NiAlphaProperty
2. 128.dds with 224 NiAlphaProperty
3. 244_new.dds with 128 NiAlphaProperty
4. 244_old.dds with 128 NiAlphaProperty
5. 128.dds with 128 NiAlphaProperty

1. Original texture from mod with 128 NiAlphaProperty
2. 128.dds with 224 NiAlphaProperty
3. 244_new.dds with 128 NiAlphaProperty
4. 244_old.dds with 128 NiAlphaProperty
5. 128.dds with 128 NiAlphaProperty

Expand  

Thanks. I will need to look at this some more in the coming days. I still would expect it to match better. The 244_new.dds seems to be dull compared to the 128.dds with 224 NiAlphaProperty for some reason and that doesn't seem right with me why that would even be the case.

[DoubleYou]

  On 8/27/2022 at 6:47 PM, sheson said:

Thanks. I will need to look at this some more in the coming days. I still would expect it to match better.

Expand  

Your textures say "244" while we've talked a lot and used "224" a lot. Perhaps you meant 244 and that's why it doesn't match better?

[sheson]

  On 8/27/2022 at 6:51 PM, DoubleYou said:

Your textures say "244" while we've talked a lot and used "224" a lot. Perhaps you meant 244 and that's why it doesn't match better?

Expand  

It's just the filename. The threshold it was created with was 224.

[z929669]

  On 8/27/2022 at 3:57 PM, DoubleYou said:

1. Original texture from mod with 128 NiAlphaProperty
2. 128.dds with 224 NiAlphaProperty
3. 244_new.dds with 128 NiAlphaProperty
4. 244_old.dds with 128 NiAlphaProperty
5. 128.dds with 128 NiAlphaProperty

1. Original texture from mod with 128 NiAlphaProperty
2. 128.dds with 224 NiAlphaProperty
3. 244_new.dds with 128 NiAlphaProperty
4. 244_old.dds with 128 NiAlphaProperty
5. 128.dds with 128 NiAlphaProperty

Expand  

For top row, 3-5 looks like changes also to the full models in the foreground. Nothing was changed about the full models or the textures they are using?

I think #2 is the best match with full.

The goal should be getting the best match without having to use a custom texture, obviously ... but also without having to make changes to the LOD model NiAlphaProperty.

Apologies for dropping off of testing. I spend daytime on weekends working on my house.

[mooit]

  On 8/27/2022 at 8:06 AM, sheson said:

Use whatever tool that allows editing of NIF models. NifSkope seems like the obvious choice.

If you read https://dyndolod.info/Help/3D-Tree-LOD-Model you would see screenshots from NifSkope that show the NiAlphaProperty blocks as children of the BSTriShape blocks.

https://www.google.com/search?q=NIF+model+NiAlphaProperty
->
http://wiki.beyondskyrim.org/wiki/Arcane_University:NIF_Data_Format#Transparency

Expand  

Ok thanks...

[Kaizersoze27]

Don't know what I am doing wrong. I have a crap load of mods, they all work fine, the game is stable (as much as I experience playing it). When I try generating DynDoLoD with Grass LoDs, the total volume generated is 40+ GB and I get single framerates. It takes many hours to generate too, I ran it all night, all other apps closed. If I do not generate grass LoDs, then all is fine and the game is stable with DynDoLoD. 

I tried disabling mods that have nothing to do with DynDoLoD, for example animation mods, combat mods, CBBE 3BA and many such mods. I also disabled the various mods that enhanced textures and meshes. Tried only with mods that add/modify locations, tree mods and grass mods, still takes a log time and gives 40+ GB of data. This time the system froze and DynDoLoD generation was giving me some entries stating something like " could not read...out of memory", I had to force shutdown my system and reboot. 

I have a decent i7 (8700K), 3080ti (12 GB), 32 GB DDR4, I think there is something very wrong in what I am doing. Could you please help?

apologies for tons of mods I have installed, I am a bit greedy, but they work good for me. Any suggestions are welcome

Thank you.

Logs.zipFetching info... modlist.txtFetching info...

Edited August 28, 2022 by Kaizersoze27

[sheson]

  On 8/28/2022 at 9:27 AM, Kaizersoze27 said:

Don't know what I am doing wrong. I have a crap load of mods, they all work fine, the game is stable (as much as I experience playing it). When I try generating DynDoLoD with Grass LoDs, the total volume generated is 40+ GB and I get single framerates. It takes many hours to generate too, I ran it all night, all other apps closed. If I do not generate grass LoDs, then all is fine and the game is stable with DynDoLoD. 

I tried disabling mods that have nothing to do with DynDoLoD, for example animation mods, combat mods, CBBE 3BA and many such mods. I also disabled the various mods that enhanced textures and meshes. Tried only with mods that add/modify locations, tree mods and grass mods, still takes a log time and gives 40+ GB of data. This time the system froze and DynDoLoD generation was giving me some entries stating something like " could not read...out of memory", I had to force shutdown my system and reboot. 

I have a decent i7 (8700K), 3080ti (12 GB), 32 GB DDR4, I think there is something very wrong in what I am doing. Could you please help?

apologies for tons of mods I have installed, I am a bit greedy, but they work good for me. Any suggestions are welcome

Thank you.

Logs.zip 952.12 kB · 2 downloads modlist.txt 54.77 kB · 1 download

Expand  

Unfortunately you started DynDOLOD one more time after generating, which replaces the debug log, so I do not have any of its information from the generation. Nevertheless, if your load order and settings cause DynDOLOD to run several hours and produce 10s of GB of output you are obviously overdoing/putting too much stuff into LOD.

Really read the documentation, for example:

https://dyndolod.info/Help/Grass-LOD#Settings
Change the Density dropdown to a lower value in the advanced mode of DynDOLOD under the Grass LOD checkbox to thin out grass LOD for better performance.
In case the grass pre-cache was generated with SuperDenseGrass = True, expect really long object LOD generation times. Lower the density to 33% or less.

https://dyndolod.info/Help/Grass-LOD#Performance
https://dyndolod.info/Help/Grass-LOD#Troubleshooting, especially the parts about out of memory.

Also https://dyndolod.info/FAQ DynDOLOD/TexGen Questions - High memory usage / Out of memory 

[z929669]

  On 8/27/2022 at 5:14 AM, sheson said:

Do not use "lod" in the name of textures if you want them to be treated like full textures being downsized and adjusted for the object LOD atlas.

I would be interested in directly comparing the actual texture of the 4k input to 256 input and if 4k has no change or just a very small change in the alpha channel. Use pipette to get the alpha value of a pixel.

So, with this we know that the 4k input has an alpha change that is ever so slightly making things thinner. Looking forward to the 256 pixel input to compare to.

Also upload the 256 input textures again together with the output so I do not have to wonder I got the right one from earlier posts.

Expand  

Finally got around to repeating my tests. This time, I succeeded in reproducing @DoubleYou's result.

I removed the Specular flag from the source AA treeaspen01 model and set Glossiness to 80 to make it consistent with treeaspen02-09.

In my testing, I either use the AA 4k source texture or a 256px version of that taken from that mip level of the 4k texture to use as a LOD-specific version (named as "autumnal.dds" rather than "birch03_c_lod.dds" per sheson's advice to remove "_lod" from the file name). This way, the source alpha of my 256px texture is direct from source without any resizing artifacts. This LOD specific texture was saved without mips, since DynDOLOD only needs the top level.

I also used a version of the AA 4k source normal WITHOUT alpha and the 256px mip from that as Source for LOD-specific normals (also saved without mips). See source normals.

1. Full AA source texture, NiAlphaProperty=128 - logs
2. Full AA source texture, NiAlphaProperty=224 - logs
3. 256 mip source texture, NiAlphaProperty=128 - logs
4. 256 mip source texture, NiAlphaProperty=224 - logs

DynDOLOD is definitely making a thicker alpha when processing the full AA texture. Check out the alpha of the source against the DynDOLOD renditions snipped from the respective atlas of each run. I have labeled then in an obvious way as indicated above --> z-tests.7z

1. 0 source-256 mip.dds (source used for #3 & #4 tests above)
2. full-128.tga (#1 test starting with 4k AA source texture)
3. full-224.tga (#2 test starting with 4k AA source texture)
4. 256-128.tga (#3 test starting with 256px mip of AA source texture)
5. 256-224.tga (#4 test starting with 256px mip of AA source texture)

So I stand corrected in that NiAlphaProperty changes do have impact, but only marginally when the source texture is 4k. The impact is much closer to expected when the source texture is smaller resolution.

From the screens, the #3 test produces the best transitions in game (which is great, because ideally, I don't want to customize NiAlphaProperty). In a perfect world, DynDOLOD produces a LOD version on the atlas that more closely approximates or exactly matches the 256 mip alpha of the source 4k texture.

[sheson]

  On 8/28/2022 at 3:16 PM, z929669 said:

Finally got around to repeating my tests. This time, I succeeded in reproducing @DoubleYou's result.

I removed the Specular flag from the source AA treeaspen01 model and set Glossiness to 80 to make it consistent with treeaspen02-09.

In my testing, I either use the AA 4k source texture or a 256px version of that taken from that mip level of the 4k texture to use as a LOD-specific version (named as "autumnal.dds" rather than "birch03_c_lod.dds" per sheson's advice to remove "_lod" from the file name). This way, the source alpha of my 256px texture is direct from source without any resizing artifacts. This LOD specific texture was saved without mips, since DynDOLOD only needs the top level.

I also used a version of the AA 4k source normal WITHOUT alpha and the 256px mip from that as Source for LOD-specific normals (also saved without mips). See source normals.

1. Full AA source texture, NiAlphaProperty=128 - logs
2. Full AA source texture, NiAlphaProperty=224 - logs
3. 256 mip source texture, NiAlphaProperty=128 - logs
4. 256 mip source texture, NiAlphaProperty=224 - logs

DynDOLOD is definitely making a thicker alpha when processing the full AA texture. Check out the alpha of the source against the DynDOLOD renditions snipped from the respective atlas of each run. I have labeled then in an obvious way as indicated above --> z-tests.7z

1. 0 source-256 mip.dds (source used for #3 & #4 tests above)
2. full-128.tga (#1 test starting with 4k AA source texture)
3. full-224.tga (#2 test starting with 4k AA source texture)
4. 256-128.tga (#3 test starting with 256px mip of AA source texture)
5. 256-224.tga (#4 test starting with 256px mip of AA source texture)

So I stand corrected in that NiAlphaProperty changes do have impact, but only marginally when the source texture is 4k. The impact is much closer to expected when the source texture is smaller resolution.

From the screens, the #3 test produces the best transitions in game (which is great, because ideally, I don't want to customize NiAlphaProperty). In a perfect world, DynDOLOD produces a LOD version on the atlas that more closely approximates or exactly matches the 256 mip alpha of the source 4k texture.

Expand  

We determined that the order of when the threshold adjustment is done needs to be after the mipmaps are created and not before that so it has the desired results.

Normal map textures do not contain alpha information that is used for alpha blending/testing with the standard shaders. The alpha information is in the diffuse texture.

What you see is that DynDOLOD is creating mipmaps differently to how the mipmaps of the full texture were created. You could say the alpha of the mipmaps of the full textures are too thin. Either way, they do not match perfectly. We know this can happen, hence the suggestion for the threshold adjustment in the LOD model. Now that people know how to create mipmaps with alpha-to-coverage,  I'll  add a shape name command so a LOD model can instruct to keep using the mipmaps from the source texture instead of generating them.

[jkp993]

Hi,

I'm getting this error. I don't want to install 2022 version of unofficial sse patch because I have not updated to AE. What should I do?

[sheson]

  On 8/29/2022 at 10:57 PM, jkp993 said:

Hi,

I'm getting this error. I don't want to install 2022 version of unofficial sse patch because I have not updated to AE. What should I do?

Expand  

Read the first post which log and debug log to upload when making posts.
Do not post screenshots of messages, use the "Copy message to clipboard" link and paste the message as text as explained in the first post.
Click the "Click on this link for additional explanations and help for this message" to open and read further explanations about the error.

This message informs you about an error in the load order.

Either use a version of Requim.esp that was made for the older versions of the plugins in the load order or update all plugins to the required versions. Or use/create a patch. I would assume that there has to be some kind of documentation or guide how to setup the mod properly and what its requirements are. Maybe it also has instructions for the different game versions / load orders.

Unrelated: Do not install third party billboards, use TexGen to create all desired/required billboards. https://dyndolod.info/Help/Tree-Grass-LOD-Billboards