DynDOLOD 3.00 Alpha 173

[sheson]

20 minutes ago, Copenhagen said:

Oh crap, i meant to include the texgen log, not dyndolod log. my b, sorry. 

Here it is

TexGen_SSE_log.txt 262.28 kB · 0 downloads

The TexGen log shows the generation of object LOD texture and tree LOD billboards with one texture missing for one tree.

Is this a quiz where I have to guess what it is you want to ask?

[Copenhagen]

25 minutes ago, sheson said:

The TexGen log shows the generation of object LOD texture and tree LOD billboards with one texture missing for one tree.

Is this a quiz where I have to guess what it is you want to ask?

I understand your confusion, I will explain: 

First time using dyndolod, i did what it told me to do, got everything installed in MO2, set up executables, ran texgen and dyndylod, afterwards, but it keeps telling me to generate LOD billboards. 

I have uploaded both logs here 

https://ufile.io/f/gmlee

But, something messed it up, or i messed something up, so i was hoping you could help. 

[sheson]

22 minutes ago, Copenhagen said:

I understand your confusion, I will explain: 

First time using dyndolod, i did what it told me to do, got everything installed in MO2, set up executables, ran texgen and dyndylod, afterwards, but it keeps telling me to generate LOD billboards. 

I have uploaded both logs here 

https://ufile.io/f/gmlee

But, something messed it up, or i messed something up, so i was hoping you could help. 

This upload contain the TexGen log and debug log.

They show the generation of object LOD texture and tree LOD billboards with one texture missing for one tree.

After that is done, install the created output as a mod and enable it before starting DynDOLOD.

I have no access to the DynDOLOD log and debug log anymore.

 

Do not install DynDOLOD into special Windows folders under UAC control. /User or /AppData is probably a bad idea for executables.

Do not install the game into Program Files x86. Same problem.

[mattski123]

On 10/28/2021 at 7:45 PM, sheson said:

Bruma, see this post and this thread

If you want to generate (tree) LOD for the new worldspace, you will need to edit ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GAMEMODE]_worldspace_ignore.txt and remove/change the line "BSHeartland (Tamriel) - bsheartland.esm". Just adding an X in front would be enough for it to show in the world selection drop down again.

It is impossible to generate good LOD for new worldspaces/mods that do not include all the data for the worldspace or all the assets.

I doubt telling the mod author(s) is going to change much. It is like this since 4 years. We will simply have to await for the complete release.

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.

Edited October 31, 2021 by mattski123

[sheson]

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

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

[godescalcus]

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:

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:

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

[sheson]

5 hours ago, 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:

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:

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

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.

[dovisally]

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 November 1, 2021 by dovisally

[sheson]

44 minutes ago, 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

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.

[dovisally]

21 minutes ago, 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.

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?

 

[sheson]

23 minutes ago, 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?

 

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.

[godescalcus]

8 hours ago, 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.

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.

[sheson]

33 minutes ago, 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.

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.

[TechAngel85]

On 9/1/2021 at 12: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.

 

On 9/1/2021 at 8:55 AM, 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.

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.

[sheson]

3 hours ago, 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.

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.