DynDOLOD 3.00 Alpha 190

[Blackread]

  On 9/8/2022 at 9:22 PM, sheson said:

But xx041be6 is in 18,-2. Was it listed with the other large references in the grid list for 18,-3?
If so, was that also the case with the script from github? (the one I sent was my current test version).

Edit: test attached script, it should add the reference to the correct grid list instead.

Skyrim SE - Generate Large References.pas 13.85 kB · 0 downloads

Expand  

Yes, it was in the grid list for 18 -3. Damn, I never noticed that it's in the wrong cell. Here's a screenshot I took while I was doing the testing that shows it (I had removed the tundra stream objects first).

And yes, just tested it, the github script also put it in the wrong grid list.

The attached script put it in the correct grid list! Seemed to do it a lot faster too.

Edited September 9, 2022 by Blackread

[sheson]

  On 9/9/2022 at 4:16 AM, Blackread said:

Yes, it was in the grid list for 18 -3. Damn, I never noticed that it's in the wrong cell. Here's a screenshot I took while I was doing the testing that shows it (I had removed the tundra stream objects first).

And yes, just tested it, the github script also put it in the wrong grid list.

The attached script put it in the correct grid list! Seemed to do it a lot faster too.

Expand  

I assume that resolves the large refs bugs, right?

[Blackread]

  On 9/9/2022 at 7:00 AM, sheson said:

I assume that resolves the large refs bugs, right?

Expand  

Almost. After the rock was placed in the right grid list, everything else worked except the rock itself. I assume this is because the rock was placed right on the cell border.

It's a bit hard to see on the vanilla pic, but I made sure by disabling the object that there was indeed LOD mixed in.

I nudged the rock one unit towards the 18 -2 cell, and after that there were no more issues.

The LOD also had to be regenerated after moving the rock, otherwise it wasn't properly registered as a large reference.

After this last tweak I haven't seen any more large ref bugs in the area!

Edited September 9, 2022 by Blackread

[sheson]

  On 9/9/2022 at 9:11 AM, Blackread said:

Almost. After the rock was placed in the right grid list, everything else worked except the rock itself. I assume this is because the rock was placed right on the cell border.

It's a bit hard to see on the vanilla pic, but I made sure by disabling the object that there was indeed LOD mixed in.

I nudged the rock ever so slightly to the side of the 18 -2 cell, and after that there were no more issues.

The LOD also had to be regenerated after moving the rock, otherwise it wasn't properly registered as a large reference.

After this last tweak I haven't seen any more large ref bugs in the area!

Expand  

What coordinates did you load into the worldspace or from which direction do you approached the cell for it to happen?

[Blackread]

  On 9/9/2022 at 11:15 AM, sheson said:

What coordinates did you load into the worldspace or from which direction do you approached the cell for it to happen?

Expand  

This video shows what I always did when testing:

But in short, I would use the command "cow arnimaduplicate003 21 -3" in the main menu, run up the little hill on the left, and then enter free cam to go inspect the objects.

[sheson]

  On 9/9/2022 at 11:42 AM, Blackread said:

This video shows what I always did when testing:

But in short, I would use the command "cow arnimaduplicate003 21 -3" in the main menu, run up the little hill on the left, and then enter free cam to go inspect the objects.

Expand  

I need to make a similar change as I did in the script to DynDOLOD - in fact I already did it for the next Alpha version because of other related changes  - so that the LOD for the rock in the BTO is marked large ref as well. So with the next alpha version you won't have to move it.

[Blackread]

  On 9/9/2022 at 12:09 PM, sheson said:

I need to make a similar change as I did in the script to DynDOLOD - in fact I already did it for the next Alpha version because of other related changes  - so that the LOD for the rock in the BTO is marked large ref as well. So with the next alpha version you won't have to move it.

Expand  

Alright, thanks!

[quochunganhphu]

Dyndolod using too much of my pc resource on alpha 96, this wasn't the case before and also takes a lot longer to finish, 100% cpu 100% ram on  [Tamriel] Updating height map from object LOD meshes

[sheson]

  On 9/12/2022 at 9:43 PM, quochunganhphu said:

Dyndolod using too much of my pc resource on alpha 96, this wasn't the case before and also takes a lot longer to finish, 100% cpu 100% ram on  [Tamriel] Updating height map from object LOD meshes

Expand  

Read the first post which log and debug log to upload when making posts.

Read the https://dyndolod.info/Changelog to see what changed.

Read the answers for "High memory usage / Out of memory" at https://dyndolod.info/FAQ and https://dyndolod.info/Help/Occlusion-Data#Out-of-Memory-while-Generating-Occlusion-Data

[Akidson]

Hello, I am encountering crashing in the area around Ivarstead. Here are the crash logs:

Crash_2022_9_13_1-27-18.txtFetching info... Crash_2022_9_13_1-33-23.txtFetching info... Crash_2022_9_13_1-38-53.txtFetching info... Crash_2022_9_13_2-2-15.txtFetching info... Crash_2022_9_13_2-7-41.txtFetching info...

As you can see, all of these crash logs have objects in common. Do you perhaps know how to fix this? Maybe remove the problematic  objects? Or somehow exclude it beofre generation? And if yes, then how do I do it?

I am using Veydogolt Trees, just mentioning if that's important, but if I disable DynDOLOD and go to the same places then I don't crash.

[z929669]

FYI. Alpha 96 is working without issue for me. TexGen takes about 20% longer (from 100s in alpha 95 to 125s in alpha 96 [Step SSE mod list, same exact LO as always]), and DynDOLOD processing time is normal. The new complex grass shows some real promise in my initial runs. I am using DynDOLOD grass tints normalized to 1.000 for all top/bottom and TexGen HD grass Direct/Indirect 0/145 in this example (Direct seems to have no impact on HD grass). Running again at 0/155 and will test more stuff  after.

EDIT: I have noticed that LOD4 grass seems to show as a slightly darker band than LOD8 and greater ... again, nothing definitive at this point. Just a casual observation as I search for the best TexGen settings for our setup.

[Eumeta]

Hi sheson, I got a bug report of the new version Alpha 96, Dyndolod 3 stopped running ( still running as application but zero progress from 100% CPU usage to nil at the beginning of Tamriel object LOD generation). This did not happen in previous versions.
Attached are the bug report and the log, the debug log is too large to insert so i'm putting a link instead. https://drive.google.com/file/d/1JuNF3um-BHtxem6xDJsTWwYhhwPPl9po/view?usp=sharing . Thank you.

 

bugreport.txtFetching info... DynDOLOD_SSE_log.txtFetching info...

[z929669]

  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  

 

  On 8/28/2022 at 8:17 PM, sheson said:

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.

Expand  

Testing the aspens again using the latest alpha 96 ...

The first screen is as I indicate above in test case #4 above (this is what is configured in the AA DynDOLOD Add-On mod (performance, autumnal). The second screen is using the same models exactly but referencing the original AA diffuse rather than the special version I created from the 256 mip of the original (saved this without mips).

I think the result is improved, but branches are still a bit too thick. I assume this is due to the alpha opacity of the original AA branch texture mips?

Logs corresponding to the second image: https://mega.nz/file/ecNmBCLQ#hQaAlvfWtH9h7NDZXvP_n39i0gmJP8bhpYrOgiNdk_k

[DoubleYou]

@z929669

See this addition to the documentation with the update:

I think we want to try that UseMipMaps thing he added.

[z929669]

  On 9/13/2022 at 3:31 AM, DoubleYou said:

@z929669

See this addition to the documentation with the update:

I think we want to try that UseMipMaps thing he added.

Expand  

Thanks, I missed that. I was hoping we could do it without manipulating the models, but I will do this tomorrow and update.