DynDOLOD 3.00 Alpha 182

[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!

[sheson]

22 hours ago, Gamma_Metroid said:

That sounds perfect!

Download this test version https://mega.nz/file/0VQTRIza#GWFTh1_F1WMBPhchppc3CzkJ5X59gl-WRbIU2PdOAIE

The filename needs to include the alphanumeric only version of a pluginname like ..\Data\DynDOLOD\DynDOLOD_SSE_material_names_skywindesm.txt

Let me know if this work, otherwise upload the log, debug log and DynDOLOD_SSE_Object_Report.txt.

[PioniereKatze]

Hi I found weird additional window glow nearby blue palace door at daytime.

It is caused by Dyndolod resourceS SE 3

Screenshot here

Edited August 11 by PioniereKatze

[Gamma_Metroid]

12 hours ago, sheson said:

Download this test version https://mega.nz/file/0VQTRIza#GWFTh1_F1WMBPhchppc3CzkJ5X59gl-WRbIU2PdOAIE

The filename needs to include the alphanumeric only version of a pluginname like ..\Data\DynDOLOD\DynDOLOD_SSE_material_names_skywindesm.txt

Let me know if this work, otherwise upload the log, debug log and DynDOLOD_SSE_Object_Report.txt.

I believe I have it set up correctly, but it seems to be looking for files with part of the base object EDID in them as well:

[00:40] [MaterialName] <Debug: Processing sw-moss 0.9.9.63_gamma.esp _LSC_Eb_DryRockTundraLand01Grass01 [STAT:05101261]>
[00:40] [BuildBaseRecords] <Debug: Looking for rocktundraland01_LSC_Eb_DryGrass01_sw-moss for 0.9.9.63_gamma.esp _LSC_Eb_DryRockTundraLand01Grass01 [STAT:05101261]>
[00:40] [BuildBaseRecords] <Debug: Looking for rocktundraland01_LSC_Eb_DryGrass01 for 0.9.9.63_gamma.esp _LSC_Eb_DryRockTundraLand01Grass01 [STAT:05101261]>
[00:40] [BuildBaseRecords] <Debug: Looking for rocktundraland01 for 0.9.9.63_gamma.esp _LSC_Eb_DryRockTundraLand01Grass01 [STAT:05101261]>

Full logs: https://ufile.io/2i16u7be

I included the material names config file as well in case that helps.

[sheson]

5 hours ago, PioniereKatze said:

Hi I found weird additional window glow nearby blue palace door at daytime.

It is caused by Dyndolod resourceS SE 3

Screenshot here

DynDOLOD Resources 3 does not change the Solitude Palace full model or adds Windows to it.

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.

Provide a useful screenshot with more informative console as explained in https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots

https://dyndolod.info/FAQ#Out-of-place-or-floating-objects

[sheson]

51 minutes ago, Gamma_Metroid said:

I believe I have it set up correctly, but it seems to be looking for files with part of the base object EDID in them as well:

[00:40] [MaterialName] <Debug: Processing sw-moss 0.9.9.63_gamma.esp _LSC_Eb_DryRockTundraLand01Grass01 [STAT:05101261]>
[00:40] [BuildBaseRecords] <Debug: Looking for rocktundraland01_LSC_Eb_DryGrass01_sw-moss for 0.9.9.63_gamma.esp _LSC_Eb_DryRockTundraLand01Grass01 [STAT:05101261]>
[00:40] [BuildBaseRecords] <Debug: Looking for rocktundraland01_LSC_Eb_DryGrass01 for 0.9.9.63_gamma.esp _LSC_Eb_DryRockTundraLand01Grass01 [STAT:05101261]>
[00:40] [BuildBaseRecords] <Debug: Looking for rocktundraland01 for 0.9.9.63_gamma.esp _LSC_Eb_DryRockTundraLand01Grass01 [STAT:05101261]>

Full logs: https://ufile.io/2i16u7be

I included the material names config file as well in case that helps.

That is a texture set diffuse texture filename variation from before it was automatic.

This test version should work https://mega.nz/file/lEIgjCSA#EeHmiInUPpCJwDRhc01ZM-j7V0Kbs3kd-vsQoVejqO4

[Gamma_Metroid]

1 hour ago, sheson said:

That is a texture set diffuse texture filename variation from before it was automatic.

This test version should work https://mega.nz/file/lEIgjCSA#EeHmiInUPpCJwDRhc01ZM-j7V0Kbs3kd-vsQoVejqO4

Looks like that did the trick, thanks!

[Andrewhahalee]

Hi, there's a strange behavior on 177 where lods would not disable in close proximity, here's an example: https://imgur.com/a/gjD6OOZ

Here's my log if you need it: https://drive.google.com/file/d/1usfrVN0rUuzVb3JXrO_5Bgb6O8EWeVfn/view?usp=drive_link