DynDOLOD Beta for Skyrim Special Edition, Skyrim VR and Enderal SE 2.98

[sheson]

  On 7/21/2018 at 11:30 AM, mxshn said:

Hello,

 

I am experiencing z-fighting / texture flicker on certain mountains around Whiterun. Using the console, I think the offending records are:

0010d28d
0010d28e
0010d292
0010d917
0010e299
0010e29a

These are all different type of Distant Cloud LOD. 

 

I also noticed that throughout the DynDOLOD_SSE_log.txt there is a message "Missing DATA - Flags 0x4 RealisticWaterTwo.esp _WTRIceFloes01_Anims [MSTT:5403261B]" but I'm not sure if that is related or not.

 

Would really appreciate some help to identify the cause of this.

Clouds typically do not z-fight since they are transparent. DynDOLOD does not change cloud references or their base records. DynDOLOD does not change how the engine works.

 

If plugins cause the large reference bugs texture flicker, solutions are to set uLargeRefGridDistance to 5, convert the plugin to an ESM or to remove the plugin. In case of converting to ESM the data flag 0x4 needs to be set on the MSTT so that the large reference bugs are not triggered.

[Monobloc]

Hi sheson, I have this issue with ultra trees :

 

On nifskope no issues(yes I loaded the 3d mesh) and the 2d counterpart has no issues either :

 

logs sho nothing wrong either

Edited July 21, 2018 by Monobloc

[sheson]

  On 7/21/2018 at 1:58 PM, Monobloc said:

Hi sheson, I have this issue with ultra trees :

 

On nifskope no issues(yes I loaded the 3d mesh) and the 2d counterpart has no issues either :

 

logs sho nothing wrong either

I am assuming the tree model used for LOD is a custom one and not from a mod. LOD does not support all shader settings/types when using "PassThru". It is probably caused by shader flags. Carefully compare shader type/flags/setttings and texture list with 3D LOD tree models included in DynDOLOD Resources to spot differences.

Edited July 21, 2018 by sheson

[Monobloc]

No it's indeed from a mod, https://www.nexusmods.com/skyrim/mods/73161?tab=files

 

file : ELOS Oaks Autumn Colours SSE

 

i'll check that out ty sheson.

Edit : do I need to regenerate after messing with the shaders ?
 

Edited July 21, 2018 by Monobloc

[Monobloc]

I opened your dyndolod ressources/meshes/dyndolod/trees/ztrees file, changed textures, copied it into the enhanced oaks standalone folders and it's still white?

[Monobloc]

welp I just did 2d generations to fix it, no problem.

[mxshn]

  On 7/21/2018 at 11:52 AM, sheson said:

Clouds typically do not z-fight since they are transparent. DynDOLOD does not change cloud references or their base records. DynDOLOD does not change how the engine works.

Thanks for the reply. You'll have to forgive me as I'm quite new to modding, but those records were what the console displayed when I clicked the area that was flickering. I hoped that they might lead to what was causing the issue.

  On 7/21/2018 at 11:52 AM, sheson said:

If plugins cause the large reference bugs texture flicker, solutions are to set uLargeRefGridDistance to 5, convert the plugin to an ESM or to remove the plugin. In case of converting to ESM the data flag 0x4 needs to be set on the MSTT so that the large reference bugs are not triggered.

Do you mean uLargeRefLODGridSize? I can't find any info on uLargeRefGridDistance.

 

Is it possible that other plugins could be triggering the large reference bug and if so, would they also show as errors in the DynDOLOD log? Lastly, should I add the flag 0x4 to the record or will there be a data field that already exists that I need to edit?

[sheson]

  On 7/21/2018 at 6:46 PM, mxshn said:

Thanks for the reply. You'll have to forgive me as I'm quite new to modding, but those records were what the console displayed when I clicked the area that was flickering. I hoped that they might lead to what was causing the issue.

Do you mean uLargeRefLODGridSize? I can't find any info on uLargeRefGridDistance.

 

Is it possible that other plugins could be triggering the large reference bug and if so, would they also show as errors in the DynDOLOD log? Lastly, should I add the flag 0x4 to the record or will there be a data field that already exists that I need to edit?

Ops, yes I mean uLargeRefLODGridSize.

 

z-fighting in the distance between object and terrain LOD is caused by floating point precision errors in the z-buffer. LOD generated by DynDOLOD does not change or fix this engine issue.

 

Large Reference bugs texture flicker (which happen right beyond the loaded cells) can be caused by many reasons and not all are scanned for or reported in the DynDOLOD log. It is easy to test though, toggle LOD with tll in console, if the full object in question still shows past the loaded cells and the flicker is gone, then it is that bug.

 

The flag is a new addition on forms version 44. It seems it should be set on all MSTT base records that are used by large references to avoid the bug to be triggered. In this case there is only a point settings that flag if the plugin is converted to an ESM to also fix the bug being triggered by the overwritten references that use the MSTTs.

Edited July 22, 2018 by sheson

[Saqer]

I'm getting much missing data error while generating dyndolod:

Missing DATA - Flags 0x4 RealisticWaterTwo.esp DLC2OceanWavesStraight [MSTT:0402ADC5] 

And many others from the same esp... However, after checking the esp in sseedite I found out the data are not missing and they are in their destined folder... So why I'm still getting this missing data message?

[sheson]

  On 7/22/2018 at 12:41 PM, Saqer said:

I'm getting much missing data error while generating dyndolod:

Missing DATA - Flags 0x4 RealisticWaterTwo.esp DLC2OceanWavesStraight [MSTT:0402ADC5] 

And many others from the same esp... However, after checking the esp in sseedite I found out the data are not missing and they are in their destined folder... So why I'm still getting this missing data message?

DATA - Flags is a row/setting on MSTT base records with form version 44. 0x4 stands for bit 4 set. xEdit currently names it Unknown2. It needs to be set, or else large references using this base record will trigger large references bugs.

Edited July 22, 2018 by sheson

[Saqer]

  On 7/22/2018 at 1:26 PM, sheson said:

DATA - Flags is a row/setting on MSTT base records with form version 44. 0x4 stands for bit 4 set. xEdit currently names it Unknown2. It needs to be set, or else large references using this base record will trigger large references bugs.

The esp that has these missing messages doesn't have any errors in xEdit... Some of them are unknown 2 and On local map... there is no other option for them in xEdit.

A guide might help.

Edited July 22, 2018 by Saqer

[David2408]

Hey sheson, 

 

I know you are probably aware of this, but I am noticing that when approaching a building like Dragonsreach or farmhouses, there is a certain time span where the full model will already be loaded while the LOD model is still loaded. This results in weird z-fighting. After this span, the LOD model unloads and leaves the already loaded full model visible. 

 

This has not been the case for Oldrim. 

 

Is there a way to tackle this issue? Or is it a flaw embedded in the large reference system that we will never be able to fix?

 

EDIT: Reading through the last page, it could be that I was mistaken and Dyndolod only amplifies this flaw. The culprit would then be other plugins that are .esp and modify large references (?). Although I have to admit I am not really sure if I understand your previous statement about this texture flicker correctly. Can you please clarify? :D

Edited July 22, 2018 by David2408

[sheson]

  On 7/22/2018 at 3:11 PM, David2408 said:

Hey sheson, 

 

I know you are probably aware of this, but I am noticing that when approaching a building like Dragonsreach or farmhouses, there is a certain time span where the full model will already be loaded while the LOD model is still loaded. This results in weird z-fighting. After this span, the LOD model unloads and leaves the already loaded full model visible. 

 

This has not been the case for Oldrim. 

 

Is there a way to tackle this issue? Or is it a flaw embedded in the large reference system that we will never be able to fix?

 

EDIT: Reading through the last page, it could be that I was mistaken and Dyndolod only amplifies this flaw. The culprit would then be other plugins that are .esp and modify large references (?). Although I have to admit I am not really sure if I understand your previous statement about this texture flicker correctly. Can you please clarify? :D

When a new row of cells attaches, the game first loads all object and then unloads LOD. All games using the same old engine do this. That is like a brief second.

 

The large reference bugs caused by plugins overwriting large references is well known and documented in the Skyim SE documentation of DynDOLOD. There are also messages about it listing all plugins/references causing the bug in the DynDOLOD log.

Edited July 22, 2018 by sheson

[sheson]

  On 7/22/2018 at 1:56 PM, Saqer said:

The esp that has these missing messages doesn't have any errors in xEdit... Some of them are unknown 2 and On local map... there is no other option for them in xEdit.

A guide might help.

This is the DynDOLOD support forum. If you require help with xEdit or have feature suggestions you should post that on the appropriate xEdit forums.

 

DynDOLOD will report overwritten large references and MSTT base records which are used by large references where the last overwrite does not have the required flag set.

 

See attached screenshot of xx02ADC5 as example. The plugin removes the flag.

Edited July 22, 2018 by sheson

[mxshn]

  On 7/22/2018 at 10:24 AM, sheson said:

...if the plugin is converted to an ESM to also fix the bug being triggered by the overwritten references that use the MSTTs.

Would it be possible to flag the plugin as an ESL instead so that the records for it are loaded in ESL space or would it need to be converted to ESM?

  On 7/22/2018 at 1:26 PM, sheson said:

0x4 stands for bit 4 set. xEdit currently names it Unknown2.

Good to know! I saw the Unknown2 variable in xEdit but I didn't know it was the 0x4 flag we've been talking about. Thanks for your help.