Jump to content

DynDOLOD 3.00 Alpha 182


sheson

Recommended Posts

On 8/27/2022 at 12: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.

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

1 full-128.jpg2 full-224.jpg3-256-128.jpg4-256-224.jpg

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.

Link to comment
Share on other sites

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

1 full-128.jpg2 full-224.jpg3-256-128.jpg4-256-224.jpg

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.

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.

  • Like 1
Link to comment
Share on other sites

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

Screenshot (177).png

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

Link to comment
Share on other sites

dyndolod64.exe has these erros, not sure how to fix them

<Error: Range check error while processing scripts\osex.pex>

  1. [03:21] <Error: File not found scripts\ccbgssse038_assassinenablescript.pex ccbgssse038-bowofshadows.esl ccBGSSSE038EnableTrigger [ACTI:FE037835]>
     
     
     
  2. [7:41 PM]
    [03:20] <Error: File not found scripts\cceejsse001_activatelinkedref.pex cceejsse002-tower.esl ccEEJSSE001_BakingSurfaceTrigger "Baking Surface" [ACTI:FE00E806]>
     
     
     
  3. [7:42 PM]
    [03:20] <Error: File not found scripts\cceejsse001_activatelinkedref.pex cceejsse002-tower.esl ccEEJSSE001_BakingSurfaceTrigger "Baking Surface" [ACTI:FE00E806]>
     
     
     
  4. [7:43 PM]
    [00:33] <Error: Range check error while processing scripts\osex.pex> [00:37] Processing 21531 base records for 2972 object LOD and 295 dynamic LOD models [00:51] <Warning: Billboard for model Meshes\landscape\plants\fallforestshrub02.nif has different CRC32 SkyrimIsWindy.esp TreeFallForestShrub02 [TREE:000AAE90]> [00:51] <Warning: Billboard for model Meshes\landscape\trees\reachtree01.nif has different CRC32 SkyrimIsWindy.esp TreeReachTree01Winterhold [TREE:00109716]> [00:52] <Warning: Billboard for model Meshes\landscape\trees\treepineforestdead05.nif has different CRC32 SkyrimIsWindy.esp TreePineForest05Dead [TREE:000B927E]> [00:52] <Warning: Billboard for model Meshes\landscape\trees\reachtree01.nif has different CRC32 for textures\landscape\trees\reachtreebranch01.dds SkyrimIsWindy.esp
Edited by Nutt_lemmings
Link to comment
Share on other sites

10 hours ago, Nutt_lemmings said:

Whenever Dyndolod3 texgen is about to finish it gives me System Error. Code: 1155. I can still manually zip the files and add them into mod organizer but the game textures flicker and the trees look like 2d models even when close. this error only happens when I try using dyndolod3 and not dyndolod2.

Ei4NI.txt 199.95 kB · 3 downloads

Moved to the DynOLOD 3 Alpha thread.
Check the first post which logs of the entire session and debug logs to upload.

The TexGen log says:
Error: System Error. Code: 1155. No application is associated with the specified file for this operation.

The OS does not seem to know how to open HTML files. Associate a webbroweser with them.

No logs uploaded for DynDOLOD. See https://dyndolod.info/FAQ answer for "Object LOD model and full model show at the same time causing texture flicker" and "Billboard tree LOD shows in active exterior cells"

7 hours ago, Nutt_lemmings said:

um not sure why but removing Immersive College of Winterhold fixed it.

edit: Also found a patch to fix it here https://www.nexusmods.com/skyrimspecialedition/mods/38655 

What did removing a mod fix exactly or what is it that was patched exactly? The texture flicker caused by large reference bugs?

Link to comment
Share on other sites

5 hours ago, Nutt_lemmings said:

dyndolod64.exe has these erros, not sure how to fix them

Read the first post which entire log of the session, debug log and bugreort.txt if it exists to upload when making posts.

As explained in the documentation DynDOLOD reports certain error in the load order. See https://dyndolod.info/Messages

The osex.pex script maybe be corrupt. Check if it works in game without errors and it doesn't have errors in the papapyrus log. Otherwise try reinstalling/recompiling it.

https://dyndolod.info/Messages/File-Not-Found-Scripts

https://dyndolod.info/Messages/Billboard-For-Model-Has-Different-CRC32

Link to comment
Share on other sites

Got Error C0000142 while running LodGen ("Error: Texconv error C0000142 textures\lod\trees\treeaspenbranchcompautumn03.dds "H:\Dyndolod\Edit Scripts\Texconvx64.exe" -nologo -y -m 1 -aw 256 -f R8G8B8A8_UNORM -o "C:\Users\redhe\AppData\Local\Temp\DynDOLOD_SSE" "C:\Users\redhe\AppData\Local\Temp\DynDOLOD_SSE\596A512B1597405D82F3AE2B6B49D6CD.dds").

 (https://imgur.com/a/xVTojWT)

 

Logs: https://mega.nz/file/Z9NiHbwC#XrZ2gCBv5n-FYC7lycy47NqkcwSqYZJ2C8x3ytxxuTM
No bugreport generated.


The key part from the debug log seems to be this:

[05:51] 00000000 ???                                   
01244e4d DynDOLODx64.exe DynDOLODHelpers  9282 dynLoadImage
0122fcc7 DynDOLODx64.exe DynDOLODHelpers  7378 AddTexture
00ee84e1 DynDOLODx64.exe DynDOLODMain     6991 RetrieveTextureSets
00ef3e4f DynDOLODx64.exe DynDOLODMain     7376 DoObjectLOD$ActRec.$0$Body
00b8c222 DynDOLODx64.exe System.Threading      TParallel.ForWorker$ActRec.$0$Body
00b8f0f3 DynDOLODx64.exe System.Threading      TTask.ExecuteReplicates$ActRec.$0$Body
00b8ece0 DynDOLODx64.exe System.Threading      TTask.Execute
00b905af DynDOLODx64.exe System.Threading      TTask.InternalExecute
00b906dc DynDOLODx64.exe System.Threading      TTask.InternalWork
00b8f2d7 DynDOLODx64.exe System.Threading      TTask.ExecuteWork
00b96544 DynDOLODx64.exe System.Threading      TThreadPool.TQueueWorkerThread.ExecuteWorkItem
00b95f9d DynDOLODx64.exe System.Threading      TThreadPool.TQueueWorkerThread.Execute
005de270 DynDOLODx64.exe System.Classes        ThreadProc
0042aa05 DynDOLODx64.exe BrainMM          2540 BrainMMThreadProxy
0041214a DynDOLODx64.exe System                ThreadWrapper
00511c69 DynDOLODx64.exe madExcept             ThreadExceptFrame
7ffa0ad8 KERNEL32.DLL                          BaseThreadInitThunk

Link to comment
Share on other sites

1 hour ago, DarthVitrial said:

Got Error C0000142 while running LodGen ("Error: Texconv error C0000142 textures\lod\trees\treeaspenbranchcompautumn03.dds "H:\Dyndolod\Edit Scripts\Texconvx64.exe" -nologo -y -m 1 -aw 256 -f R8G8B8A8_UNORM -o "C:\Users\redhe\AppData\Local\Temp\DynDOLOD_SSE" "C:\Users\redhe\AppData\Local\Temp\DynDOLOD_SSE\596A512B1597405D82F3AE2B6B49D6CD.dds").

 (https://imgur.com/a/xVTojWT)

 

Logs: https://mega.nz/file/Z9NiHbwC#XrZ2gCBv5n-FYC7lycy47NqkcwSqYZJ2C8x3ytxxuTM
No bugreport generated.


The key part from the debug log seems to be this:

  Reveal hidden contents

 

Use the "Copy message to clipboard" link to copy paste a message as text instead of making screenshots as explained on the first post.

C0000142 just means "failed" without any further information.

There might be a problem with the texture treeaspenbranchcompautumn03.dds (especially if the error is repeatable)_ or something happened to it after it was copied to the temp folder/filename or the OS or antivir interfered with texconv or it had some kind of trouble.

Check the texture is fine and what happens if you execute the command line on a copy on the windows command prompt.

Link to comment
Share on other sites

@sheson

I know DynDOLOD allows using LOD via rules for MSTT moveable statics, but since I only have xLODGen for Fallout 4, is there any built-in way to add LOD to MSTT references? For the raider wind turbines, I used fake static references to generate the LODs, but this is less then ideal for a lot of objects, especially as far as mod compatibility is concerned. Fallout 4 has a very large portion of its cars and trucks as MSTT references, since they are designed to exploded if you shoot them. I could develop a script of some sort to generate the fake statics I suppose, but I'd rather save myself the hassle if there already is a way to do this. Could it be possible for xLODGen to automatically use a specific naming structure LOD model (say lod\path_to_model_lod_0.nif) for LOD if I add the Has Distant LOD flag?

Link to comment
Share on other sites

3 hours ago, DoubleYou said:

@sheson

I know DynDOLOD allows using LOD via rules for MSTT moveable statics, but since I only have xLODGen for Fallout 4, is there any built-in way to add LOD to MSTT references? For the raider wind turbines, I used fake static references to generate the LODs, but this is less then ideal for a lot of objects, especially as far as mod compatibility is concerned. Fallout 4 has a very large portion of its cars and trucks as MSTT references, since they are designed to exploded if you shoot them. I could develop a script of some sort to generate the fake statics I suppose, but I'd rather save myself the hassle if there already is a way to do this. Could it be possible for xLODGen to automatically use a specific naming structure LOD model (say lod\path_to_model_lod_0.nif) for LOD if I add the Has Distant LOD flag?

xLODGen is a CK replacement LOD generator. It requires LOD models to be defined on base records. Only STAT base records can do that. So only reference that use STAT or SCOL which then use STAT base records can be used for static object LOD generation.

If anything, we would use DynDOLOD for anything beyond that. Either way, that would be a considerable time investment - the list of things to add to xLODGen (bake fake grass for example) and DynDOLOD is already quite long... so  anything like this is still some time in the future.

If you have a fixed list of LOD objects you could add them to the export file manually for the xLODGen or maybe via LOD options file.

Keep in mind though , that the static object LOD will truly be static, it can not move and not change how it looks.

Link to comment
Share on other sites

4 hours ago, sheson said:

xLODGen is a CK replacement LOD generator. It requires LOD models to be defined on base records. Only STAT base records can do that. So only reference that use STAT or SCOL which then use STAT base records can be used for static object LOD generation.

If anything, we would use DynDOLOD for anything beyond that. Either way, that would be a considerable time investment - the list of things to add to xLODGen (bake fake grass for example) and DynDOLOD is already quite long... so  anything like this is still some time in the future.

If you have a fixed list of LOD objects you could add them to the export file manually for the xLODGen or maybe via LOD options file.

Keep in mind though , that the static object LOD will truly be static, it can not move and not change how it looks.

Thanks. That confirms what I had expected was the case. I don't want to heap extra work onto that list. I just didn't want to be creating extra work for myself if there already was an easier way to do this.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.