DynDOLOD 3.00 Alpha 196

[RYTY]

hello i've recently tried to get dyndolod again after a failed attempt from a few months back and now im getting a weird error

[Window Title]
DynDOLOD

[Main Instruction]
Error: Assertion failure (E:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 8941)

strange thing is i don't even have a E drive so this error makes no sense... anyone know what it means?

[sheson]

30 minutes ago, RYTY said:

hello i've recently tried to get dyndolod again after a failed attempt from a few months back and now im getting a weird error

[Window Title]
DynDOLOD

[Main Instruction]
Error: Assertion failure (E:\Delphi\Projects\DynDOLOD3\Core\wbImplementation.pas, line 8941)

strange thing is i don't even have a E drive so this error makes no sense... anyone know what it means?

Moved to the DynDOLOD 3 Alpha thread.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log, debug log and bugreport.txt (if it exists) to upload.

Did the message not have a link Click on this link for additional explanations and help for this message that opens https://dyndolod.info/Messages/Exceptions as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#Read-Log-and-Error-Messages?
Assertion failure
Always use the latest version of DynDOLOD/TexGen as explained above.
If the assertion failure is a 100% repeatable, it might be caused by a broken plugin.
Clean and error check the load order with xEdit before generating LOD as explained above.
If the assertion failure is not 100% repeatable or no error can be found in plugins, it could be a bug with the tools encountering unexpected situations. Make a report with the log, debug log and bugreport.txt as explained on the official DynDOLOD support forum.

[Gamma_Metroid]

Hi Sheson,

I have an LOD model with vertex colors that are not being carried over into the generated LOD. I have included some log files as well as the LOD model itself and a quad of the generated LOD so you can see the result: https://ufile.io/n4yy7pab
The base formID is 05101261, and an example ref is 050A0357. The corresponding shapes in the generated LOD file are blocks 158 and 164.

Is there something I am missing or is this a bug?

[BuddyKidd]

I am getting this error which I don't know how to fix:

[Window Title]
DynDOLOD

[Main Instruction]
Error: [FE0676D1] <Error: Could not be resolved 2 >Material.

[Content]

Click on this link for additional explanations and help for this message

For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum.

[OK] [Exit DynDOLOD]

[Footer]
Online Help | Support Forum | Copy message to clipboard

 

Here are my logs:

https://www.dropbox.com/scl/fi/mosla8knxioyg11j85q7l/bugreport.txt?rlkey=5y26qpsrgh2cy2rker77opyhc&st=4yfp8opu&dl=0

https://www.dropbox.com/scl/fi/huuarmtk2q3zxay7ldmbc/DynDOLOD_SSE_log.txt?rlkey=mdsb01lcch1ryutooclia4bua&st=f18aclkh&dl=0

https://www.dropbox.com/scl/fi/iwilbra7kb3vet5dlaxny/DynDOLOD_SSE_Debug_log.txt?rlkey=5sd9l0xzyowcweyh4k4s6839u&st=dyi6wqsv&dl=0

[z929669]

Looks like the OP still refers to Alpha 176, and I'm not seeing the 177 changelog. Maybe you are still working on the doc update piece, but thought I'd let you know. The Mega source references 177, and the executable looks right.

[sheson]

5 hours ago, Gamma_Metroid said:

Hi Sheson,

I have an LOD model with vertex colors that are not being carried over into the generated LOD. I have included some log files as well as the LOD model itself and a quad of the generated LOD so you can see the result: https://ufile.io/n4yy7pab
The base formID is 05101261, and an example ref is 050A0357. The corresponding shapes in the generated LOD file are blocks 158 and 164.

Is there something I am missing or is this a bug?

The vertex colors of rocktundraland01_lod_1.nif you uploaded are all white, which is the same as not having vertex colors.
This means they might be optimized away sometimes - (depends on other assets it is merged with).

Keep at least one color channel per shape <= 0.9.
Is there a reason you are changing the vertex colors too and not just the alpha presumably because of the custom shader cover you are doing?
We might want to use a method of uniquely naming these custom LOD assets so it doesn't end up in overwriting lots of DynDOLOD Resources having filename collisions.

[sheson]

5 hours ago, BuddyKidd said:

I am getting this error which I don't know how to fix:

[Window Title]
DynDOLOD

[Main Instruction]
Error: [FE0676D1] <Error: Could not be resolved 2 >Material.

[Content]

Click on this link for additional explanations and help for this message

For qualified help and advice or to report a problem make a post on the official DynDOLOD support forum.

[OK] [Exit DynDOLOD]

[Footer]
Online Help | Support Forum | Copy message to clipboard

 

Here are my logs:

https://www.dropbox.com/scl/fi/mosla8knxioyg11j85q7l/bugreport.txt?rlkey=5y26qpsrgh2cy2rker77opyhc&st=4yfp8opu&dl=0

https://www.dropbox.com/scl/fi/huuarmtk2q3zxay7ldmbc/DynDOLOD_SSE_log.txt?rlkey=mdsb01lcch1ryutooclia4bua&st=f18aclkh&dl=0

https://www.dropbox.com/scl/fi/iwilbra7kb3vet5dlaxny/DynDOLOD_SSE_Debug_log.txt?rlkey=5sd9l0xzyowcweyh4k4s6839u&st=dyi6wqsv&dl=0

It seems like you flagged plugins as light plugins without compacting them first. For example:
SMIM-SE-Merged-All.esp
Farmhouse Chimneys patches Merged.esp
Cathedral Weathers.esp

See https://dyndolod.info/Messages/Invalid-Object-ID

Restore the broken plugins with valid ones.

[sheson]

4 hours ago, z929669 said:

Looks like the OP still refers to Alpha 176, and I'm not seeing the 177 changelog. Maybe you are still working on the doc update piece, but thought I'd let you know. The Mega source references 177, and the executable looks right.

Fixed the first post.
If you do not see the new changelog, clear the browsers cache.

[Gamma_Metroid]

51 minutes ago, sheson said:

The vertex colors of rocktundraland01_lod_1.nif you uploaded are all white, which is the same as not having vertex colors.
This means they might be optimized away sometimes - (depends on other assets it is merged with).

Keep at least one color channel per shape <= 0.9.
Is there a reason you are changing the vertex colors too and not just the alpha presumably because of the custom shader cover you are doing?
We might want to use a method of uniquely naming these custom LOD assets so it doesn't end up in overwriting lots of DynDOLOD Resources having filename collisions.

Ah! I haven't even realized I set the vertex colors to all white. That explains that!

Filename collisions are a concern I have wondered about. Generally I try to keep the filename and path as close as possible between the full model and LOD model. Is there any existing convention for when a single full model requires two different LOD models due to the directional shader?

[sheson]

15 minutes ago, Gamma_Metroid said:

Ah! I haven't even realized I set the vertex colors to all white. That explains that!

Filename collisions are a concern I have wondered about. Generally I try to keep the filename and path as close as possible between the full model and LOD model. Is there any existing convention for when a single full model requires two different LOD models due to the directional shader?

Not yet like that. I will have to add something.
I think looking for LOD filenames plus the EditorID of the shader should work.

[Gamma_Metroid]

13 minutes ago, sheson said:

Not yet like that. I will have to add something.
I think looking for LOD filenames plus the EditorID of the shader should work.

Would the name need to be specific to the individual shader? The vertex alpha makes it possible for the model to receive any LOD shader. And on a practical level, we have multiple full detail moss shaders which end up using the same LOD moss shader. Maybe something more generic like "rocktundraland01_lod_1_mato.nif" ?

[sheson]

4 hours ago, Gamma_Metroid said:

Would the name need to be specific to the individual shader? The vertex alpha makes it possible for the model to receive any LOD shader. And on a practical level, we have multiple full detail moss shaders which end up using the same LOD moss shader. Maybe something more generic like "rocktundraland01_lod_1_mato.nif" ?

We could then use a config file that lists the MATO records and their substitute strings similar to how TextureSets worked in the past before the automatic replacement and LOD texture generation.

See ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_textures_names.txt as example
[pluginname];[zero form id];[string]
zero form ID = load order ID = 00 for full plugin or 00000 for light plugin

Create a new file DynDOLOD_SSE_material_names.txt. Put yours into ..\Data\DynDOLOD\DynDOLOD_SSE_material_names.txt
Make sure to use a hopefully unique string. For example:
Skywind.esm;00345678;sw-moss
Skywind.esm;00654321;sw-moss
...
Next test or alpha version could then look for rocktundraland01_sw-moss_lod_1.nif if a base record uses any of those material records.
In case the filename does not exists, it falls back to normal filename.

[Jonado]

On 8/6/2024 at 8:11 AM, sheson said:

DynDOLOD does not include any rules for BluePalaceTerrace-LegacyOfTheDragonborn-Patch.esp

What is the actual problem with the new patch? Make a proper problem report with logs and screenshots if required.

The problem with the old patch was the bleeding rock seen in the attached screenshot. You asked me back then which plugin was the last to edit that reference, which was BluePalaceTerrace-LegacyOfTheDragonborn-Patch.esp. I don't know how you resolved it, but I interpreted is as you were going to apply certain rules for that plugin. If that is the case, those rules need to be updated to the new plugin, DBM_BluePalaceTerrace_Patch.esp. I have not checked whether the issue has reappeared, just notifying you that if it was resolved that way, some action will be needed on your side.

I haven't saved my log files from that DynDOLOD generation, but the screenshot should be informative enough for you to be able to look up what is currently being done for that reference.

[sheson]

41 minutes ago, Jonado said:

The problem with the old patch was the bleeding rock seen in the attached screenshot. You asked me back then which plugin was the last to edit that reference, which was BluePalaceTerrace-LegacyOfTheDragonborn-Patch.esp. I don't know how you resolved it, but I interpreted is as you were going to apply certain rules for that plugin. If that is the case, those rules need to be updated to the new plugin, DBM_BluePalaceTerrace_Patch.esp. I have not checked whether the issue has reappeared, just notifying you that if it was resolved that way, some action will be needed on your side.

I haven't saved my log files from that DynDOLOD generation, but the screenshot should be informative enough for you to be able to look up what is currently being done for that reference.

Do not waste time using older versions or reporting problems with older versions. 

Just report actual problems with the latest version for which you can provide screenshots, the log and debug logs etc. and are able to answer follow up questions.

[Gamma_Metroid]

6 hours ago, sheson said:

We could then use a config file that lists the MATO records and their substitute strings similar to how TextureSets worked in the past before the automatic replacement and LOD texture generation.

See ..\DynDOLOD\Edit Scripts\DynDOLOD\Configs\DynDOLOD_SSE_textures_names.txt as example
[pluginname];[zero form id];[string]
zero form ID = load order ID = 00 for full plugin or 00000 for light plugin

Create a new file DynDOLOD_SSE_material_names.txt. Put yours into ..\Data\DynDOLOD\DynDOLOD_SSE_material_names.txt
Make sure to use a hopefully unique string. For example:
Skywind.esm;00345678;sw-moss
Skywind.esm;00654321;sw-moss
...
Next test or alpha version could then look for rocktundraland01_sw-moss_lod_1.nif if a base record uses any of those material records.
In case the filename does not exists, it falls back to normal filename.

That sounds perfect!