sheson Posted July 21, 2018 Author Posted July 21, 2018 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 0010e29aThese 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 Posted July 21, 2018 Posted July 21, 2018 (edited) 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 Posted July 21, 2018 Author Posted July 21, 2018 (edited) 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 eitherI 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 Posted July 21, 2018 Posted July 21, 2018 (edited) 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 Posted July 21, 2018 Posted July 21, 2018 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 Posted July 21, 2018 Posted July 21, 2018 welp I just did 2d generations to fix it, no problem.
mxshn Posted July 21, 2018 Posted July 21, 2018 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.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 Posted July 22, 2018 Author Posted July 22, 2018 (edited) 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 Posted July 22, 2018 Posted July 22, 2018 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 Posted July 22, 2018 Author Posted July 22, 2018 (edited) 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 Posted July 22, 2018 Posted July 22, 2018 (edited) 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 Posted July 22, 2018 Posted July 22, 2018 (edited) 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 Posted July 22, 2018 Author Posted July 22, 2018 (edited) 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 Posted July 22, 2018 Author Posted July 22, 2018 (edited) 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 Posted July 22, 2018 Posted July 22, 2018 ...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?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.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now