Jump to content

Recommended Posts

Posted

Well i belive i found a problem/solution. i disabled DynDOLOD.esp, loadded my old save without DynDOLOD.esp, made i new save, then out, enable DynDOLOD.esp, load last save, and creat a new save with DynDOLOD.esp enabled and it is fine! no that error!

Posted
  On 1/14/2022 at 9:37 PM, chumik6000 said:

Well i belive i found a problem/solution. i disabled DynDOLOD.esp, loadded my old save without DynDOLOD.esp, made i new save, then out, enable DynDOLOD.esp, load last save, and creat a new save with DynDOLOD.esp enabled and it is fine! no that error!

Expand  

As mentioned, follow the clean save routine when updating. See https://dyndolod.info/Help/Clean-Save

That should also mean testing with a new game should also be able to save without issue.

Posted (edited)

Hey Sheson, hope you're doing well!

A quick question: I did a complete new LOD-generation with the latest Alpha v63 and discovered that the new DynDOLOD-output zip became appx 800 MB smaller in filesize (1.7 GB) than the previous generated output-zip (from Alpha v60; 2.5 GB). This seems a bit weird since I haven't changed my load order and Im using the exact same DynDOLOD-settings as before...

Also, the Alpha 63 "Logs"-directory seems to be missing (?) a lot of files when compared to Alpha 60 (see attached screenshots below) and the debug file is freaking HUGE in size (100 MB)?  But maybe all of this is perfectly fine since I did not recieve a bugreport? Anyway, please have a look at attached files:

DynDOLOD log and debug file: https://ufile.io/f/in6da

Screenshot/comparison: log-files Alpha 60 vs 63 after completed LOD-generation (same settings): https://imgur.com/a/3B6Dk9l

Edited by TheDude
Posted
  On 1/15/2022 at 1:53 AM, TheDude said:

Hey Sheson, hope you're doing well!

A quick question: I did a complete new LOD-generation with the latest Alpha v63 and discovered that the new DynDOLOD-output zip became appx 800 MB smaller in filesize (1.7 GB) than the previous generated output-zip (from Alpha v60; 2.5 GB). This seems a bit weird since I haven't changed my load order and Im using the exact same DynDOLOD-settings as before...

Also, the Alpha 63 "Logs"-directory seems to be missing (?) a lot of files when compared to Alpha 60 (see attached screenshots below) and the debug file is freaking HUGE in size (100 MB)?  But maybe all of this is perfectly fine since I did not recieve a bugreport? Anyway, please have a look at attached files:

DynDOLOD log and debug file: https://ufile.io/f/in6da

Screenshot/comparison: log-files Alpha 60 vs 63 after completed LOD-generation (same settings): https://imgur.com/a/3B6Dk9l

Expand  

Instead of comparing file size of logs, open them and check their content for warning or error messages as is their purpose. The LODGen logs indicate there were problems. See what they say and let me know.

Instead of checking size of output (or stopping there), check that the expected sub-folders and files for the selected worldspaces were generated.

Seems like object LOD generation failed for some worldspace. 

E.g. it only says LODGenx64.exe generated object LOD for Tamriel successfully but none of the others.

See if Alpha-64 works as expected or if it reports that there were problems with LODGen as expected.

Posted
  On 1/14/2022 at 5:28 PM, sheson said:

Check the Windows event log if there is a report in there.

While the tool runs, check main memory and video memory usage.

Maybe disable anything like Geforce experience or software from the graphics card maker, overlays etc. Everything else that is equally unnecessary running in the background.

Expand  

There is no Windows event log report. At least I can't find it. I looked for it in Windows\System32\Config, and I found no text log in there. Is it there were I have to look?

I run TexGen again, with no unnecesary applications running in the background (including GeForce or any overlay). Main memory never went up of 29%. Video memory peaked at 2300 MB (I have a 3080, so not close to the limit). I leave here the log:

https://ufile.io/squ9sk33

P.S. Always, at the top of every log, there are two errors:

<Debug: OpenGL: framebuffer objects unsupported>
<Debug: Framebuffer error: framebuffer objects unsupported: 32768>
<Debug: OpenGL: framebuffer objects unsupported>
<Debug: Framebuffer error: framebuffer objects unsupported: 16384>

 

 

Posted
  On 1/15/2022 at 9:12 AM, Thardrim said:

There is no Windows event log report. At least I can't find it. I looked for it in Windows\System32\Config, and I found no text log in there. Is it there were I have to look?

I run TexGen again, with no unnecesary applications running in the background (including GeForce or any overlay). Main memory never went up of 29%. Video memory peaked at 2300 MB (I have a 3080, so not close to the limit). I leave here the log:

https://ufile.io/squ9sk33

P.S. Always, at the top of every log, there are two errors:

<Debug: OpenGL: framebuffer objects unsupported>
<Debug: Framebuffer error: framebuffer objects unsupported: 32768>
<Debug: OpenGL: framebuffer objects unsupported>
<Debug: Framebuffer error: framebuffer objects unsupported: 16384>

Expand  

Use the Windows Event Log Viewer to check the event log. It can be found in  Administrative Tools.

The log entries for finding the max possible resolution for the framebuffer are expected.

Assuming you keep testing with latest Alpha-64?

See what happens if you run TexGen without any mods for vanilla.

Have you checked if Alpha-60 actually still works now?

Posted
  On 1/15/2022 at 9:23 AM, sheson said:

Use the Windows Event Log Viewer to check the event log. It can be found in  Administrative Tools.

The log entries for finding the max possible resolution for the framebuffer are expected.

Assuming you keep testing with latest Alpha-64?

See what happens if you run TexGen without any mods for vanilla.

Have you checked if Alpha-60 actually still works now?

Expand  

Ok. I used the windows event viewer and here it is what I found:

https://ufile.io/tci6l4ou (I guess this is what we're looking for. If not, let me know).
 
No, I kept testing with Alpha-63. I didn't realize there was an update. From now on, I'll try with Alpha-64 and Dyndolod Resources Alpha-19.
 
I actually did run TexGen (Alpha-63) without any mod loaded a few hours ago and it went through. It finished correctly with Grass and HD trees checked.
 
Yesterday, I checked Alpha-60 and it also didn't work this time.
 
I'm going to check again with Alpha-64 with and without mods. I'll let you know how it goes.
 
Thank you very much for following my case so closely. 
Posted
  On 1/15/2022 at 6:42 AM, sheson said:

Instead of comparing file size of logs, open them and check their content for warning or error messages as is their purpose. The LODGen logs indicate there were problems. See what they say and let me know.

Instead of checking size of output (or stopping there), check that the expected sub-folders and files for the selected worldspaces were generated.

Seems like object LOD generation failed for some worldspace. 

E.g. it only says LODGenx64.exe generated object LOD for Tamriel successfully but none of the others.

See if Alpha-64 works as expected or if it reports that there were problems with LODGen as expected.

Expand  

Thanks for your support! And yes, you're absolutely right: I will check the logs for warnings or errors next time. I agree that it seems that LOD-generation failed for certain worldspaces and will try to re-generate everything using Alpha-64. I'll be back with more info after this! Cheers!

Posted
  On 1/15/2022 at 11:02 AM, Thardrim said:

Ok. I used the windows event viewer and here it is what I found:

https://ufile.io/tci6l4ou (I guess this is what we're looking for. If not, let me know).
 
No, I kept testing with Alpha-63. I didn't realize there was an update. From now on, I'll try with Alpha-64 and Dyndolod Resources Alpha-19.
 
I actually did run TexGen (Alpha-63) without any mod loaded a few hours ago and it went through. It finished correctly with Grass and HD trees checked.
 
Yesterday, I checked Alpha-60 and it also didn't work this time.
 
I'm going to check again with Alpha-64 with and without mods. I'll let you know how it goes.
 
Thank you very much for following my case so closely. 
Expand  

Test if there is anything different using this test version

Posted
  On 1/15/2022 at 6:42 AM, sheson said:

Instead of comparing file size of logs, open them and check their content for warning or error messages as is their purpose. The LODGen logs indicate there were problems. See what they say and let me know.

Instead of checking size of output (or stopping there), check that the expected sub-folders and files for the selected worldspaces were generated.

Seems like object LOD generation failed for some worldspace. 

E.g. it only says LODGenx64.exe generated object LOD for Tamriel successfully but none of the others.

See if Alpha-64 works as expected or if it reports that there were problems with LODGen as expected.

Expand  

Hi again, Dyndolod Alpha-64 seems to work perfect for me and LOD-generation worked for all of the worldspaces! Thanks a lot!

Posted
  On 1/12/2022 at 3:09 PM, sheson said:

If full textures become thin in the distances, also try generating mipmaps for it with an appropriate alpha-to-covergage setting.

When a texture is added to the atlas, DynDOLOD does this automatically, hence the difference.

From https://dyndolod.info/Help/3D-Tree-LOD-Model:
Note that LOD only has binary alpha with a fixed threshold of 128. DynDOLOD reads the alpha threshold from the NiAlphaProperty from the models used for LOD and adjusts the textures before it is added to the atlas texture. The final result in game may be to thick or thin like certain objects seem to be missing or transparency looks off. Try adjusting the NiAlphaProperty in the 3D LOD model. Again, note that the UV texture coordinates need to be >= 0.0 and <= 1.0 for LOD being able to use the atlas texture. If the UV is outside those limits, LOD will use the texture directly.

You can check and do simple edits to UV in NifSkope. If they are just slightly outside you can move them inside 0.0 and 1.0 in NifSkope UV editor or change wrap UV to clamp the UV in the shader settings for that shape.

Expand  

Thank you, I did an "alpha-to-covergage" increase in the texture and it made the distant trees no longer sparse.  But still I wonder as you said, Dyndolod will create records to dyndolodxx.dds when they satisfy UV coordinates between 0.0-1.0 but in Alpha 62 version the trunks are written to Dyndolod.dds  but not in the latest version, resulting in them breaking when viewed from a distance.  LOL.

received-661288151699064.webp[/img]

 Anyway thank you so much for all your efforts in answering my questions, you are amazing.

Posted
  On 1/15/2022 at 4:54 PM, ntluan_vn said:

Thank you, I did an "alpha-to-covergage" increase in the texture and it made the distant trees no longer sparse.  But still I wonder as you said, Dyndolod will create records to dyndolodxx.dds when they satisfy UV coordinates between 0.0-1.0 but in Alpha 62 version the trunks are written to Dyndolod.dds  but not in the latest version, resulting in them breaking when viewed from a distance.  LOL.

imageproxy.php?img=&key=1d9081609aff28e4received-661288151699064.webp[/img]

 Anyway thank you so much for all your efforts in answering my questions, you are amazing.

Expand  

Nothing really changed how this works in months or years even. I mean just check changelog of 62, 63 and 64...

  • Thanks 1

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.