Jump to content

Recommended Posts

Posted
  On 10/31/2021 at 1:20 AM, mattski123 said:

Hey, just letting you know the maker of A Clear World Map just added Bruma. https://www.nexusmods.com/skyrimspecialedition/mods/56367/

Hope this helps. Which means we don't have to change the lod settings to 16 in his ini.

Expand  

Changing INI settings for the map or existing BTR/BTO Level 32 meshes and their textures have no relevance to LOD generation or DynDOLOD.

Posted

Hey Sheson,

I posted a brief comment on a Spice of Life Forts thread I had previously created but maybe this thread would be best for 3.0 support... The aforementioned mod contains these two config files:

image.thumb.png.fee98230500a7f20788af21c79fe2b52.png

However, they don't seem to work with 3.0 (worked pretty well with 2.9x). Forts now have purple lods...

Should a different syntax be used to tell texgen to generate the needed textures, than the one used in those files? Here's what they contain:

image.thumb.png.975db94c6acbbdc6e3c2eb9b5dff3654.png

image.thumb.png.5755dad1a2685637bedc5512bb0dc4fd.png

I last ran DynDOLOD with resources alpha 13. If support for SoL Forts has been added since, then I'm sorry to bring this up. But since the mod itself contained the config files, I guess it's up to the author (or us users) to fix it... In which case, what needs to be done? Thanks

Posted
  On 11/1/2021 at 1:12 AM, godescalcus said:

Hey Sheson,

I posted a brief comment on a Spice of Life Forts thread I had previously created but maybe this thread would be best for 3.0 support... The aforementioned mod contains these two config files:

image.thumb.png.fee98230500a7f20788af21c79fe2b52.png

However, they don't seem to work with 3.0 (worked pretty well with 2.9x). Forts now have purple lods...

Should a different syntax be used to tell texgen to generate the needed textures, than the one used in those files? Here's what they contain:

image.thumb.png.975db94c6acbbdc6e3c2eb9b5dff3654.png

image.thumb.png.5755dad1a2685637bedc5512bb0dc4fd.png

I last ran DynDOLOD with resources alpha 13. If support for SoL Forts has been added since, then I'm sorry to bring this up. But since the mod itself contained the config files, I guess it's up to the author (or us users) to fix it... In which case, what needs to be done? Thanks

Expand  

Post the TexGen logs as explained in the first post. It is very likely that config rules are not loaded and thus do not show up in the logs.

The config files for TexGen are loaded when the matching plugin name is installed in the load order. The MO2 screenshot does not show the plugin. 

The config file format for TexGen did not change.

This mod could use an update to give each new full texture a unique filename as per the Bethesda file naming conventions instead of using folder separation. Then there won't be any need for custom LOD models anymore and LOD textures would be generated automatically on the fly by DynDOLOD 3.

Posted (edited)

I'm getting this error:

LOGDenx64.exe failed to generate object lod for one or more worlds,

looking at the log i see 2 errors

- error occlusion generation aborted due to LODGen error

- error LOGDenx64.exe failed to gegerate objeect lod for PalePass

Logs:

https://ufile.io/f/6x7ie

 

 

Edited by dovisally
Posted
  On 11/1/2021 at 11:51 AM, dovisally said:

I'm getting this error:

LOGDenx64.exe failed to generate object lod for one or more worlds,

looking at the log i see 2 errors

- error occlusion generation aborted due to LODGen error

- error LOGDenx64.exe failed to gegerate objeect lod for PalePass

Logs:

https://ufile.io/f/6x7ie

Expand  

As you can see from the LODGen log, there is a problem reading the PalePass.4.1.-4.btr terrain LOD mesh file.

It is probably corrupt or invalid.

You could try to open the file in NifSkope to see if it is valid or not. If it opens without problem in NifSkope upload the file for me to review.

If NifSkope agrees, reinstall the mod it comes from.

Best solution is always to generate terrain LOD (meshes at least) with xLODGen for the current load order with xLODGen.

Posted
  On 11/1/2021 at 12:17 PM, sheson said:

As you can see from the LODGen log, there is a problem reading the PalePass.4.1.-4.btr terrain LOD mesh file.

It is probably corrupt or invalid.

You could open the file in NifSkope to see if it is valid or not. If it opens without problem in NifSkope upload it for me to review.

If NifSkope agrees, reinstall the mod it comes from.

Best solution is always to generate terrain LOD (meshes at least) with xLODGen for the current load order with xLODGen.

Expand  

Sorry for my ignorance and simple questions, very new with modding

I'm trying to follow the path of this file with mod2 virtual folder but the terrain folder doesn't have PalePass

is that something to consider?

 

Explorer++_ztTU0OdX15.png

Posted
  On 11/1/2021 at 12:25 PM, dovisally said:

Sorry for my ignorance and simple questions, very new with modding

I'm trying to follow the path of this file with mod2 virtual folder but the terrain folder doesn't have PalePass

is that something to consider?

 

Explorer++_ztTU0OdX15.png

Expand  

Assuming this shows the virtual file explorer from MO2.

The file will be in a BSA then.

Use the xEdit Asset Browser (started with CTRL+F3) to find which container (BSA or data = loose file) contains it, open it in NifSkope, extract it etc.

In that case it is possible LODGen can not read the BSA itself because it is blocked or is corrupt, invalid.

Posted
  On 11/1/2021 at 6:42 AM, sheson said:

The config files for TexGen are loaded when the matching plugin name is installed in the load order. The MO2 screenshot does not show the plugin. 

The config file format for TexGen did not change.

Expand  

Thanks, I now know what went wrong - I merged the mod and its patches. If I rename the rules files to match the merged plugin filename, would they get loaded?

Now, regarding the naming conventions - if I understood correctly, if I simply renamed those textures (for example, appending the current folder name to the filename) and moved them all into a folder that DynDOLOD would recognise (such as Beth's folders), without forgetting to update the file path in the static/texture records of the plugin(s), no need for rules at all? The mod was "broken" for so many years, but it appears that CaBaL has reuploaded aMidianBorn Imperial Forts, and granted kryptopyr permission to upload them to SSE, making it possible to do what I think you said. But it would be quite the undertaking. And there's an old GEMS mod that currently requires a ton of patching, from snow mods to fort conquests.

Posted
  On 11/1/2021 at 3:17 PM, godescalcus said:

Thanks, I now know what went wrong - I merged the mod and its patches. If I rename the rules files to match the merged plugin filename, would they get loaded?

Now, regarding the naming conventions - if I understood correctly, if I simply renamed those textures (for example, appending the current folder name to the filename) and moved them all into a folder that DynDOLOD would recognise (such as Beth's folders), without forgetting to update the file path in the static/texture records of the plugin(s), no need for rules at all? The mod was "broken" for so many years, but it appears that CaBaL has reuploaded aMidianBorn Imperial Forts, and granted kryptopyr permission to upload them to SSE, making it possible to do what I think you said. But it would be quite the undertaking. And there's an old GEMS mod that currently requires a ton of patching, from snow mods to fort conquests.

Expand  

See "Dealing with merged Mods" in..\DynDOLOD\Docs\DynDOLOD_Manual.html

Depending on how it was merged and if the map.txt or map.json  file still exists then it is supposed to discover the merged plugin file from that. Please check, it is possible that it broke in the alpha. Otherwise you need to copy the config files to the new plugin filename.

DynDOLOD 3 properly supports texture-sets for vanilla/DynDOLOD Resources LOD models that make use of stitched object LOD textures.
However, it assume that each filename is unique regardless of its path.

Every shape in the LOD models that uses a direct derivative  of the full texture (like the imperial towers) included in DynDOLOD Resource 3 defines the same full texture as their corresponding full model. For those vanilla textures a TexGen config rules how to create the LOD texture exists. If a base record with such a full model / LOD model combination uses a texture-set, DynDOLOD will automatically create a new LOD texture with the replaced full textures based on the same TexGen config. As usual the LOD textures are added to the atlas textures and then LODGen will do its thing and voila the LOD uses the correct LOD texture.

This automatic creation uses a simple filename setting like MyAwesomeFullTexture.dds -> MyAweSomeFullTextureLOD.dds, hence the unique filename requirement for now.

If you are interested, just do test with a vanilla imperial tower without creating/defining custom LOD models on the new base record with the texture-set.

Posted
  On 9/1/2021 at 5:15 AM, sheson said:

If this reference is Initially disabled with an enable state opposite to player and a z position of -30000 it should be "fixed" by DynDOLOD automatically. Check if it overwrites the record.

Expand  

 

  On 9/1/2021 at 1:55 PM, sheson said:

Only ESM flagged plugins can overwrite large references without triggering the bugs.

A solution would be to move all such overwrites out of the ESP into a ESM (can also be flagged ESL).

As a user who is not fixing the plugins/mods you will just have to ignore the warnings. Large reference are a visual problem. The bugs are only visible when the large reference system is enabled via the launcher/INI setting.

Expand  

I'm confused. Perhaps you could shed some light on this. Realistic Water Two SE does this very thing (ESM, flagged as ESL to disable refs), yet DynDOLOD is calling out the disabled references within the ESM in the logs.

Posted
  On 11/2/2021 at 3:08 AM, TechAngel85 said:

I'm confused. Perhaps you could shed some light on this. Realistic Water Two SE does this very thing (ESM, flagged as ESL to disable refs), yet DynDOLOD is calling out the disabled references within the ESM in the logs.

Expand  

Initially Disabled references can cause large reference bugs. The plugin type does not matter.  If they have an enable parent they most likely do. If they do not have an enable parent they might. It happens a few times in the vanilla game with references only defined in Skyrim.esm for example. It seems only the one at the Winterhold college bridge affects full and LOD models that occupy the same 3D space. In all other cases the LOD models in the cell are smaller so it isn't that obvious that full models and LOD models are loaded.

Typically the report is meant for reverse troubleshooting. If there is texture flicker because of full and LOD models being loaded at the same time, test if it is caused by the large reference bugs by disabling them. If  they are the cause, search for the cell coordinates in the log if they are being reported. In case there are no log entries, search the debug log, too.

Posted

First, using alpha 53 of DynDOLOD 3, and the generation is fine, no interrupt in whole process.

But while using DynDOLODx64.exe to generate it goes with heavy number of "Warning: Overwritten large reference in.." or "Warning: Initially disabled large reference in..", and few Warning: File not found..

I move the outputed file and create as a mod, load it and sort order, everything is OK. In game, the LOD looks fine and nothing obvious wrong.

BUT, when I move to a specific area(Windhelmet indeed), probably as the LOD near it started loading, the game crashed.

By reading README, I do what the manual said.

Hide generated mesh folder, Crashed.

Hide DynDOLOD.esp, No Crash.

Also, tons of error in Papyrus Log like that below:

  Quote

[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C00241C) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C0026C6) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C00200B) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_LODObject to  (7C003DD8) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C003720) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C002D47) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C001E4F) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C002FB7) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C002ED3) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C002BF7) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C0037E2) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C0032A6) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C003563) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C00206B) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_LODObject to  (7C003B20) because their base types do not match
[11/02/2021 - 02:15:12PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C002A8A) because their base types do not match

Line 12521 to Line 12536

=====================================================================================================================

[11/02/2021 - 02:16:44PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (1900163E) because their base types do not match
[11/02/2021 - 02:16:44PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (19001650) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (1900162C) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (1900163F) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (19001651) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (1900162D) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Worshipper to  (19001652) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C001782) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C001783) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C0017A7) because their base types do not match
[11/02/2021 - 02:16:45PM] Error: Unable to bind script SHESON_DynDOLOD_Firstborn to  (7C0017A6) because their base types do not match

Line 46436 to Line 46446

Expand  

Same error "Unable to bind script SHESON_DynDOLOD_.." filled almost the whole log.

I searched for long time and trying find a similar issue like this, but there isn't any.

I don't know what's wrong with the damn mod file, I suffered this dumb problem for totally 3 days.

Also, I tried using the latest & stable version, DynDOLOD 2.96 and Resource 2.88 in Nexus Page, same.

Tried take off other irrelevant mods, keep only enviorment mod then generate LOD, same.

NEED HELP PLS

Posted
  On 11/2/2021 at 7:08 AM, Epslion_09cc said:

First, using alpha 53 of DynDOLOD 3, and the generation is fine, no interrupt in whole process.

But while using DynDOLODx64.exe to generate it goes with heavy number of "Warning: Overwritten large reference in.." or "Warning: Initially disabled large reference in..", and few Warning: File not found..

I move the outputed file and create as a mod, load it and sort order, everything is OK. In game, the LOD looks fine and nothing obvious wrong.

BUT, when I move to a specific area(Windhelmet indeed), probably as the LOD near it started loading, the game crashed.

By reading README, I do what the manual said.

Hide generated mesh folder, Crashed.

Hide DynDOLOD.esp, No Crash.

Also, tons of error in Papyrus Log like that below:

Same error "Unable to bind script SHESON_DynDOLOD_.." filled almost the whole log.

I searched for long time and trying find a similar issue like this, but there isn't any.

I don't know what's wrong with the damn mod file, I suffered this dumb problem for totally 3 days.

Also, I tried using the latest & stable version, DynDOLOD 2.96 and Resource 2.88 in Nexus Page, same.

Tried take off other irrelevant mods, keep only enviorment mod then generate LOD, same.

NEED HELP PLS

Expand  

Read the first post.

You did not upload any logs. In this case the entire papyrus log also would be of interest.

"Unable to bind script" points to a an (incomplete) LOD generation or an installation problem (like DynDOLOD Resources missing or not installed completely).

Read ..\DynDOLOD\docs\help\LogMessages.html for explanations what log messages mean.

As the readme explains, install .NET Script Framework for Skyrim Special Edition and check its crash log for clues. Upload the crash log if help is required.

Posted (edited)
  On 10/31/2021 at 5:28 AM, sheson said:

Changing INI settings for the map or existing BTR/BTO Level 32 meshes and their textures have no relevance to LOD generation or DynDOLOD.

Expand  

Where do I change those ini settings which ini? Also, in terms of game performance, which one is more liekly to cause lag spikes: Occlusion Datas quality 3 or quality 1? I'm just not sure what the difference is. Also, do neargridtoload & fargridtoload affect performance if those numbers are changed? Or does that just mean objects farther away like grass not showing on landscapes would be loaded? I was having that problem, and I precached the grass but it was still an issue. Any hints or resolves for showing grass in all countryside?

 

Is there a picture example of the prefer base record LOD assignments over rules? I just wanna see what I'd be losing for minimal performance gain.

Edited by mattski123
Posted
  On 11/2/2021 at 10:06 AM, mattski123 said:

Where do I change those ini settings which ini? Also, in terms of game performance, which one is more liekly to cause lag spikes: Occlusion Datas quality 3 or quality 1? I'm just not sure what the difference is. Also, do neargridtoload & fargridtoload affect performance if those numbers are changed? Or does that just mean objects farther away like grass not showing on landscapes would be loaded? I was having that problem, and I precached the grass but it was still an issue. Any hints or resolves for showing grass in all countryside?

 

Is there a picture example of the prefer base record LOD assignments over rules? I just wanna see what I'd be losing for minimal performance gain.

Expand  

You yourself referred to the INI settings which object/terrain LOD level is used for the map:
"Which means we don't have to change the lod settings to 16 in his ini."

Occlusion data does not cause lag spikes. It determine which LOD quads are rendered for a cell.
Read ..\DynDOLOD\docs\help\OcclusionCulling.html
Read ..\DynDOLOD\docs\help\Advanced.html and hover the mouse pointer above a setting for hints.
Read ..\DynDOLOD\docs\DynDOLOD_Manual.html "
TVDT - Occlusion Data"
They all explain the quality setting determines how many samples are used for the calculations to generate the occlusion data.

Read ..\DynDOLOD\docs\DynDOLOD_Manual.html "DynDOLOD Mod", which explains what the  Near and Far Grid is and that they are concepts of dynamic LOD. It goes without saying that the further or the more stuff is shown the more resources it uses. Regardless of LOD type/method.

Read ..\DynDOLOD\docs\help\GrassLOD.html which explains that grass LOD is done in object LOD level 4.
No idea what hints you are expecting for showing grass in all countrysides as you do not explain what the problem is.
Refer to the troubleshooting section in case grass LOD is incomplete.

If you want to see how different settings affect your unique load order and setup, take a before and after screenshots or refer to guides that do these things for their particular load order. The performance impact of the setting will be negligible with grass or 3D tree LOD,  too high INI settings or 8k apple textures.

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.