DynDOLOD 3.00 Alpha 173

[Akidson]

37 minutes ago, sheson said:

Replacing NIF files is safe.

There seem to be a lot of problematic 3D tree LOD models in the the two "3D Hybrid LODs" archives of the mod. The models contain NiSwitch nodes instead of being static 3D tree LOD models as explained in https://dyndolod.info/Help/3D-Tree-LOD-Model. They might work for object LOD generation as LODGen might be able to extract what it needs and remove duplicate stuff on the fly, but the way the NIFs are made they cause CTD when used directly in the game for dynamic LOD. They probably a (couple) dozen references here and there that could be problematic. They need to be fixed.

I made the 3D tree LOD a real static model by copying the actual crown BSTriShape to the root node and removed all the uneeded/interfering blocks. Comparing the NIFs in Nifskope should make it clear.

Oh, so maybe I should remove the 3D Hybrid LODs file and use the 3D full models that come with the main Veydogolt Trees file instead and run TexGen and DynDOLOD again.

[sheson]

41 minutes ago, Akidson said:

Oh, so maybe I should remove the 3D Hybrid LODs file and use the 3D full models that come with the main Veydogolt Trees file instead and run TexGen and DynDOLOD again.

I generally do not recommend using full model trees for object LOD generation because of the performance impact and time required to generate the huge LOD meshes.

A better working solution might be to keep the LOD resources installed and use the usual "tree" mesh rule with Level0 for LOD Level 4, Billboard* for LOD Level 8/16 and just change Grid from "Far LOD" to "Far Full". Then only the few case of dynamic LOD should be using the full models.

Let me know if that works out, e.g. if you do not crash at the spot afterwards or look up the STAT base record (it will have a new form ID but same EditorID) that it uses the full model.

If you do not want to generate LOD again, you can manually update all the STAT base records using such tree LOD models in xEdit to use the full model instead.

[zeuslee766]

I always appreciate your dedication.
I got two problems. I use Castle Volkihar Rebuilt, Worldspace Transition Tweaks and A Clear Map of Skyrim and Other Worlds  
The front right tower of Volkihar Castle disappears from the world map. 
And  I can't see parts of Solstheim at high hrothgar.
I attach a screenshot and log file. Please give me your help me!
https://drive.google.com/drive/folders/1zPeDr2NZYhGb1Fo5CDBs_n7lPofkdFa7?usp=sharing

[sheson]

1 hour ago, zeuslee766 said:

I always appreciate your dedication.
I got two problems. I use Castle Volkihar Rebuilt, Worldspace Transition Tweaks and A Clear Map of Skyrim and Other Worlds  
The front right tower of Volkihar Castle disappears from the world map. 
And  I can't see parts of Solstheim at high hrothgar.
I attach a screenshot and log file. Please give me your help me!
https://drive.google.com/drive/folders/1zPeDr2NZYhGb1Fo5CDBs_n7lPofkdFa7?usp=sharing

The mod Castle Volkihar Rebuilt changes the reference of the tower so it has an enable parent, to switch it out with a version that has the roof fixed. Such reference have dynamic LOD instead of static object LOD. Right now it is not possible to automatically address this, but it is a planed feature for a future versions in case LOD Level 32 is used for map  - since it does not show in the game world and the map could simply use the initial version regardless.

Does the island come into view when you get closer? The game renders about a 100 cells into the distance and everything beyond just vanishes. You might want to increase object LOD distance for LOD Level 16 fBlockMaximumDistance in SkyrimPrefs.INI or  https://dyndolod.info/Help/Mod-Configuration-Menu#Settings so the max distance is shows object LOD on top of the terrain LOD.

[z929669]

13 hours ago, DoubleYou said:

@z929669

See this addition to the documentation with the update:

I think we want to try that UseMipMaps thing he added.

Refer to my previous post for context.

Testing the aspens again using the latest alpha 97 ...

1. The first screen corresponds to test case #4 in contextual link above (this is what is configured in the AA DynDOLOD Add-On mod (performance, autumnal).
2. The second screen is using the same models exactly but referencing the original AA diffuse (test case #1 in the contextual link above) rather than the special version I created from the 256 mip of the original (saved this without mips). UPDATE: since I did not set "UseMipMaps" in the name strings of the crown BsTriShapes of the LOD models, this is effectively DynDOLOD mipmapping of the original AA crown textures.
3. The third screen is based on the same setup as the second screen, but the "UseMipMaps" keyword was added to the BsTriShape name strings of all LOD models:

Note that using the native AA texture mipmaps is much too thin, so it's the correct direction, but too far. The solution would either be to lower the NiAlphaProperty to something like 64, or continue using the custom branch texture as test case #4 described in the contextual link above. The "UseMipMaps" feature may still be useful in some current/future situations, so thatnks for that.

Logs corresponding to the third image: https://mega.nz/file/nMlCRRrb#dPQ4BXCqf_NAiwEUzFdpehj7PyAubK1dUMyFjrevGoo

[Littlerift]

6 hours ago, sheson said:

Thank you for all the help. Use the working version and enjoy.

 

Just to add to the praise and to confirm that it works: I can now run TexGen using the 'working version' using the release version of MO2.

 

Thank you for your help! What a fantastic and responsive dev!

[Akidson]

8 hours ago, sheson said:

I generally do not recommend using full model trees for object LOD generation because of the performance impact and time required to generate the huge LOD meshes.

A better working solution might be to keep the LOD resources installed and use the usual "tree" mesh rule with Level0 for LOD Level 4, Billboard* for LOD Level 8/16 and just change Grid from "Far LOD" to "Far Full". Then only the few case of dynamic LOD should be using the full models.

Let me know if that works out, e.g. if you do not crash at the spot afterwards or look up the STAT base record (it will have a new form ID but same EditorID) that it uses the full model.

If you do not want to generate LOD again, you can manually update all the STAT base records using such tree LOD models in xEdit to use the full model instead.

Ok, so I've run AutoTest and I haven't encountered even a single crash related to DynDOLOD. (There were some random ones but nothing serious as they couldn't be replicated after doing the Auto Test) It seems that was the only problematic model. Thank you so much for the assistance sheson!

[Eumeta]

17 hours ago, sheson said:

Could you check for me which which mod changes ..Meshes\Architecture\Tents\LargeNordicTent01.nif?

There is one mod "Nordic tent" by Pfuscher.

 

[z929669]

Just want to report an ongoing issue with all of the alpha versions since like alpha 33. I haven't reported these for a while, since we got nowhere with a similar but worse issue about a year ago (it was mysteriously resolved for me with a subsequent alpha update).

I will try again. This happens at the very end of running either TexGen or DynDOLOD about 25% of the time for me. The processing completes and the exit/view log dialog appears in a partially-rendered state before the program quits disgracefully ... NO logs or bug report is ever created, since there is no hand-off to the process that creates the logs ... or in the case of DynDOLOD: saves the plugins.

With TexGen, this is not an issue, since I run against the same mod list pretty much constantly in testing, and I know my output bit sizes, which are always consistent, given the nearly identical LO each run. I just use the TexGen output in such cases and move on to DynDOLOD without issue.

With DynDOLOD, it's quite frustrating, as it's a waste of 15-50 minutes of processing, depending. Reason being because the program disgracefully halts without generating the plugins (I could probably reuse those from other runs, but I don't ... they are usually the same exact bits).

Anyway, the only clue is in the Win event log, and it's always the same for either program:

Faulting application name: TexGenx64.exe, version: 3.0.0.0, time stamp: 0x63207073
Faulting module name: KERNELBASE.dll, version: 10.0.22000.918, time stamp: 0xb42fa627
Exception code: 0xc000041d
Fault offset: 0x000000000004474c
Faulting process id: 0x2604c
Faulting application start time: 0x01d8c7dd47b3dae2
Faulting application path: C:\Modding\Tools\DynDOLOD\TexGenx64.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll

Info on the error: https://github.com/dynamorio/drmemory/issues/1355

[sheson]

4 hours ago, z929669 said:

Just want to report an ongoing issue with all of the alpha versions since like alpha 33. I haven't reported these for a while, since we got nowhere with a similar but worse issue about a year ago (it was mysteriously resolved for me with a subsequent alpha update).

I will try again. This happens at the very end of running either TexGen or DynDOLOD about 25% of the time for me. The processing completes and the exit/view log dialog appears in a partially-rendered state before the program quits disgracefully ... NO logs or bug report is ever created, since there is no hand-off to the process that creates the logs ... or in the case of DynDOLOD: saves the plugins.

With TexGen, this is not an issue, since I run against the same mod list pretty much constantly in testing, and I know my output bit sizes, which are always consistent, given the nearly identical LO each run. I just use the TexGen output in such cases and move on to DynDOLOD without issue.

With DynDOLOD, it's quite frustrating, as it's a waste of 15-50 minutes of processing, depending. Reason being because the program disgracefully halts without generating the plugins (I could probably reuse those from other runs, but I don't ... they are usually the same exact bits).

Anyway, the only clue is in the Win event log, and it's always the same for either program:

Faulting application name: TexGenx64.exe, version: 3.0.0.0, time stamp: 0x63207073
Faulting module name: KERNELBASE.dll, version: 10.0.22000.918, time stamp: 0xb42fa627
Exception code: 0xc000041d
Fault offset: 0x000000000004474c
Faulting process id: 0x2604c
Faulting application start time: 0x01d8c7dd47b3dae2
Faulting application path: C:\Modding\Tools\DynDOLOD\TexGenx64.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll

Add realtimelog=1 to TexGen_SSE.INI/DynDOLOD_SSE.ini and upload that log if it happens again.

See if it happens when using the default "Windows" theme.

[z929669]

7 hours ago, sheson said:

Add realtimelog=1 to TexGen_SSE.INI/DynDOLOD_SSE.ini and upload that log if it happens again.

See if it happens when using the default "Windows" theme.

TexGen ran fine this time. DynDOLODx64.exe had the 0xc000041d error though. Running non default Windows theme under Win 11 this time.

logs (no bug report produced)

Admin Event

Log Name:      Application
Source:        Application Error
Date:          9/14/2022 8:41:38 AM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DHVP
Description:
Faulting application name: DynDOLODx64.exe, version: 3.0.0.0, time stamp: 0x63207073
Faulting module name: KERNELBASE.dll, version: 10.0.22000.918, time stamp: 0xb42fa627
Exception code: 0xc000041d
Fault offset: 0x000000000004474c
Faulting process id: 0x5038
Faulting application start time: 0x01d8c83a4d7ca852
Faulting application path: C:\Modding\Tools\DynDOLOD\DynDOLODx64.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: 1e08a2da-ad58-4b3b-8ea1-ec7b15462800
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>100</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2022-09-14T13:41:38.6155810Z" />
    <EventRecordID>1538</EventRecordID>
    <Correlation />
    <Execution ProcessID="49696" ThreadID="0" />
    <Channel>Application</Channel>
    <Computer>DHVP</Computer>
    <Security />
  </System>
  <EventData>
    <Data>DynDOLODx64.exe</Data>
    <Data>3.0.0.0</Data>
    <Data>63207073</Data>
    <Data>KERNELBASE.dll</Data>
    <Data>10.0.22000.918</Data>
    <Data>b42fa627</Data>
    <Data>c000041d</Data>
    <Data>000000000004474c</Data>
    <Data>5038</Data>
    <Data>01d8c83a4d7ca852</Data>
    <Data>C:\Modding\Tools\DynDOLOD\DynDOLODx64.exe</Data>
    <Data>C:\WINDOWS\System32\KERNELBASE.dll</Data>
    <Data>1e08a2da-ad58-4b3b-8ea1-ec7b15462800</Data>
    <Data>
    </Data>
    <Data>
    </Data>
  </EventData>
</Event>

 

[sheson]

2 hours ago, z929669 said:

TexGen ran fine this time. DynDOLODx64.exe had the 0xc000041d error though. Running non default Windows theme under Win 11 this time.

logs (no bug report produced)

  Reveal hidden contents

Log Name:      Application
Source:        Application Error
Date:          9/14/2022 8:41:38 AM
Event ID:      1000
Task Category: (100)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DHVP
Description:
Faulting application name: DynDOLODx64.exe, version: 3.0.0.0, time stamp: 0x63207073
Faulting module name: KERNELBASE.dll, version: 10.0.22000.918, time stamp: 0xb42fa627
Exception code: 0xc000041d
Fault offset: 0x000000000004474c
Faulting process id: 0x5038
Faulting application start time: 0x01d8c83a4d7ca852
Faulting application path: C:\Modding\Tools\DynDOLOD\DynDOLODx64.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: 1e08a2da-ad58-4b3b-8ea1-ec7b15462800
Faulting package full name:
Faulting package-relative application ID:
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Application Error" />
    <EventID Qualifiers="0">1000</EventID>
    <Version>0</Version>
    <Level>2</Level>
    <Task>100</Task>
    <Opcode>0</Opcode>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2022-09-14T13:41:38.6155810Z" />
    <EventRecordID>1538</EventRecordID>
    <Correlation />
    <Execution ProcessID="49696" ThreadID="0" />
    <Channel>Application</Channel>
    <Computer>DHVP</Computer>
    <Security />
  </System>
  <EventData>
    <Data>DynDOLODx64.exe</Data>
    <Data>3.0.0.0</Data>
    <Data>63207073</Data>
    <Data>KERNELBASE.dll</Data>
    <Data>10.0.22000.918</Data>
    <Data>b42fa627</Data>
    <Data>c000041d</Data>
    <Data>000000000004474c</Data>
    <Data>5038</Data>
    <Data>01d8c83a4d7ca852</Data>
    <Data>C:\Modding\Tools\DynDOLOD\DynDOLODx64.exe</Data>
    <Data>C:\WINDOWS\System32\KERNELBASE.dll</Data>
    <Data>1e08a2da-ad58-4b3b-8ea1-ec7b15462800</Data>
    <Data>
    </Data>
    <Data>
    </Data>
  </EventData>
</Event>

 

Are you clicking/doing anything after it prompts to save/exit?

Switch to default theme to see if it makes a difference.

Upload a debug log from TexGen or DynDOLOD from a successful run.

[z929669]

5 hours ago, sheson said:

Are you clicking/doing anything after it prompts to save/exit?

Switch to default theme to see if it makes a difference.

Upload a debug log from TexGen or DynDOLOD from a successful run.

When the run completes, I am usually at the keyboard waiting for it. I try not to maximize the LODGen CMD windows or have other windows open. The save/exit dialog appears over the xEdit processing window. 50-75% of the time, I simply click Check Log or Save/Exit without issue, but the rest of the time, the dialog is not fully rendered, which indicates to me that the process governing that is about to close disgracefully (and does).

I will test default windows theme to see if it helps.

I just completed successful runs of TexGen and DynDOLOD 97, so here's those logs.

[blueetenicolet]

Seem there are some bugs with glacierswere some ，the LOD object generated by DynDOLOD overlaps the original LOD object and cause z-fighting. It happends on many ice near winterhold or windhelm.

video here: https://mega.nz/folder/fAokTAbY#s-U8K5ejI0CduQtR2Thxpg

If i uninstall DynDOLOD completely, the LOD objects that appear to have lower resolution and brighter colors（sometimes snowcovered） will disappear and no longer have Z-fighting problems. I have reason to think that these brighter LODs are produced by DynDOLOD. Is there any way to get DynDOLOD not to make LODs on them?

DynDOLOD: Alpha 97

[sheson]

1 hour ago, blueetenicolet said:

Seem there are some bugs with glacierswere some ，the LOD object generated by DynDOLOD overlaps the original LOD object and cause z-fighting. It happends on many ice near winterhold or windhelm.

video here: https://mega.nz/folder/fAokTAbY#s-U8K5ejI0CduQtR2Thxpg

If i uninstall DynDOLOD completely, the LOD objects that appear to have lower resolution and brighter colors（sometimes snowcovered） will disappear and no longer have Z-fighting problems. I have reason to think that these brighter LODs are produced by DynDOLOD. Is there any way to get DynDOLOD not to make LODs on them?

DynDOLOD: Alpha 97

Read the first post which log and debug log to upload when making posts.

See  https://dyndolod.info/FAQ answers for "Object LOD model and full model show at the same time causing texture flicker" and maybe "Object LOD shows in active exterior cells"