sheson Posted March 24 Author Posted March 24 1 hour ago, aazz said: DynDOLOD_SSE_Object_Report.7z 451.97 kB · 1 download https://imgur.com/a/9Mch4rs What should I check here now?? I am already using Glacier LOD Meshes. I have also modified all the paths of the meshes. The requested DynDOLOD log and debug log were not provided. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs None of the screenshots seem to show the full model with more informative console information. See https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots. The used full model filename or base record form ID of the full model can be used to look up in the object report which LOD assets are actually being used. make sure the LOD assets shipping with the mod overwrite DynDOLOD Resources.
z929669 Posted March 25 Posted March 25 I'd like input regarding the 'usemipmaps' keyword in the shape name of the modified external grass billboard, DynDOLOD_flat_4x2alt2_lod.nif. When I modify the original billboard included with DynDOLOD, save into a new NIF, and modify my DynDOLOD_SSE.ini likewise to use the new billboard model, I get an unexpected result. Clearly, the mipmaps generated by DynDOLOD for grass (in this case Cathedral Landscapes Complex Grass for ENB), use a method that differs from the mipmaps of the textures. From the result, it looks like some of the LOD grasses may be correct, but many are much too bright and wrong, so I cannot say for certain. The obviously wrong grasses are from 1024x2048 source cg textures saved with a2c threshold of 128, while those that look a bit more as expected correlate to 2048x4096 source textures saved at a a2c threshold of 106. I've been carefully testing the optimal thresholds of these grasses, and with respect to the grasses in the scene below, these are optimal for loaded grasses (not too thick or thin and no alpha color bias). Thus, I wanted to test using them for LOD. using default NIF using modified NIF logs Note that the version of the mod I'm working with is in development, so if you want any particular files, I will post them. PS: I'm not sure how mipmaps work for object LOD. I've seen that the TexGen billboards make it into the DynDOLOD_Tamriel.dds atlas, but the closest LOD grass seems brighter than the TexGen source billboard textures when usemipmaps keyword is used. How can I check the mip levels compared to my source? PSS: I've checked the DynDOLOD_Tamriel.dds atlas mip levels now, and am seeing that higher mip levels are particularly opaque/bright for the problem grasses. Might the cause be that I am using the Kaiser algorithm for generating mipmaps? This works nicely for non-LOD textures, but it may be that opacity needs to be reduced at each mip level for LOD to avoid overly-bright grasses at lower mip levels. I'm not sure if the closest grass LOD uses mip 0 (from the TexGen billboards) on the atlas, because those aren't as bright as mipmaps at higher levels on the atlas. If the grasses on the atlas (and only the grasses) are now using my mipmaps, then Kaiser may be 'bad' for use with DynDOLOD. PSSS: Well, it occurs to me that the TexGen billboard mipmaps shouldn't be getting used, since the usemipmaps keyword applies to generation subsequent to generating the billboards with TexGen, so I have no clue
sheson Posted March 25 Author Posted March 25 1 hour ago, z929669 said: I'd like input regarding the 'usemipmaps' keyword in the shape name of the modified external grass billboard, DynDOLOD_flat_4x2alt2_lod.nif. When I modify the original billboard included with DynDOLOD, save into a new NIF, and modify my DynDOLOD_SSE.ini likewise to use the new billboard model, I get an unexpected result. Clearly, the mipmaps generated by DynDOLOD for grass (in this case Cathedral Landscapes Complex Grass for ENB), use a method that differs from the mipmaps of the textures. From the result, it looks like some of the LOD grasses may be correct, but many are much too bright and wrong, so I cannot say for certain. The obviously wrong grasses are from 1024x2048 source cg textures saved with a2c threshold of 128, while those that look a bit more as expected correlate to 2048x4096 source textures saved at a a2c threshold of 106. I've been carefully testing the optimal thresholds of these grasses, and with respect to the grasses in the scene below, these are optimal for loaded grasses (not too thick or thin and no alpha color bias). Thus, I wanted to test using them for LOD. using default NIF using modified NIF logs Note that the version of the mod I'm working with is in development, so if you want any particular files, I will post them. PS: I'm not sure how mipmaps work for object LOD. I've seen that the TexGen billboards make it into the DynDOLOD_Tamriel.dds atlas, but the closest LOD grass seems brighter than the TexGen source billboard textures when usemipmaps keyword is used. How can I check the mip levels compared to my source? PSS: I've checked the DynDOLOD_Tamriel.dds atlas mip levels now, and am seeing that higher mip levels are particularly opaque/bright for the problem grasses. Might the cause be that I am using the Kaiser algorithm for generating mipmaps? This works nicely for non-LOD textures, but it may be that opacity needs to be reduced at each mip level for LOD to avoid overly-bright grasses at lower mip levels. I'm not sure if the closest grass LOD uses mip 0 (from the TexGen billboards) on the atlas, because those aren't as bright as mipmaps at higher levels on the atlas. If the grasses on the atlas (and only the grasses) are now using my mipmaps, then Kaiser may be 'bad' for use with DynDOLOD. PSSS: Well, it occurs to me that the TexGen billboard mipmaps shouldn't be getting used, since the usemipmaps keyword applies to generation subsequent to generating the billboards with TexGen, so I have no clue The point of TexGen and DynDOLOD is to not having to manually edit any of their outputs but instead use the existing settings and options to get the desired results or to report problems with the automatically generated output in order to have them troubleshooted and addressed. https://en.wikipedia.org/wiki/Mipmap In computer graphics, mipmaps ... are pre-calculated, optimized sequences of images, each of which is a progressively lower resolution representation of the previous. Mipmaps are simply a list of images. https://dyndolod.info/Help/3D-Tree-LOD-Model Note that by default mipmaps of textures that are added to the tree LOD or object LOD texture atlas are ignored and instead are generated from the largest resolution with an alpha-to-coverage algorithm so that small details do not fade into full transparency the further away they are. To use the mipmaps of the original texture defined by the LOD model, add the term UseMipMaps to the BSTriShape/NiTriShape name. This should preferably be done for all LOD models using this texture. Use an unique filename for such textures, so there are no problems with other mods modifying the same vanilla filenames. https://stepmodifications.org/forum/topic/20141-dyndolod-300-alpha-190/page/539/#findComment-274396 https://stepmodifications.org/forum/topic/19077-optimizing-texture-alpha-threshold/https://dyndolod.info/Help/Texture-Resolution https://dyndolod.info/Help/Texture-Resolution#Determine-Sensible-Texture-Resolutions has explanations how to see in the game if the largest mipmap is actually used.
z929669 Posted March 25 Posted March 25 18 minutes ago, sheson said: The point of TexGen and DynDOLOD is to not having to manually edit any of their outputs but instead use the existing settings and options to get the desired results or to report problems with the automatically generated output in order to have them troubleshooted and addressed. To be clear, I'm not modifying the outputs of the LOD patch. Rather, I am working with the source cg textures and generating LOD from those. Specifically, I'm optimizing the mipmaps of the Cathedral Landscapes Complex Grass for ENB grasses, because many of the finer grasses were too thin at distance: From the documentation, DynDOLOD mipmaps are probably like this: I will experiment using the cutout alpha, MipMapTests parameter in DynDOLOD, and solidifying specific TexGen grass billboards. I'm still not clear on what UseMipMaps keyword is doing in this situation when applied to the grass billboard NIF. What explains the huge brightness difference? This would seem to have noting at all to do with TexGen, since the supposedly used mipmaps are in the source texture used by the full grass model as shown above.
sheson Posted March 25 Author Posted March 25 26 minutes ago, z929669 said: To be clear, I'm not modifying the outputs of the LOD patch. Rather, I am working with the source cg textures and generating LOD from those. Specifically, I'm optimizing the mipmaps of the Cathedral Landscapes Complex Grass for ENB grasses, because many of the finer grasses were too thin at distance: From the documentation, DynDOLOD mipmaps are probably like this: I will experiment using the cutout alpha, MipMapTests parameter in DynDOLOD, and solidifying specific TexGen grass billboards. I'm still not clear on what UseMipMaps keyword is doing in this situation when applied to the grass billboard NIF. What explains the huge brightness difference? This would seem to have noting at all to do with TexGen, since the supposedly used mipmaps are in the source texture used by the full grass model as shown above. I'd like input regarding the 'usemipmaps' keyword in the shape name of the modified external grass billboard, DynDOLOD_flat_4x2alt2_lod.nif. DynDOLO/object LOD does not use full grass textures. The billboard NIFs are used together with billboard textures. Billboard textures generated by TexGen typically do not have mipmaps, since they are generated by DynDOLOD when textures are added to the object LOD atlas. TexGen by default ignores mipmaps of complex grass full textures when rendering billboards. UseMipmapsComplexGrass setting in TexGen_SSE.INI
z929669 Posted March 25 Posted March 25 7 minutes ago, sheson said: I'd like input regarding the 'usemipmaps' keyword in the shape name of the modified external grass billboard, DynDOLOD_flat_4x2alt2_lod.nif. DynDOLO/object LOD does not use full grass textures. The billboard NIFs are used together with billboard textures. Billboard textures generated by TexGen typically do not have mipmaps, since they are generated by DynDOLOD when textures are added to the object LOD atlas. Okay, so is it accurate to say that DynDOLOD generates mipmaps using the TexGen billboard texture as a basis at mip 0? If that's the case, I still don't understand the following. It implies that the mipmaps defined in the full texture are used rather than them being generated by DynDOLOD (because TexGen billboard textures do not have mipmaps, as you said): https://dyndolod.info/Help/3D-Tree-LOD-Model#Shape-Names - usemipmaps - if the textures used by this shape are added to the texture atlas, use original mipmaps instead of generating them. See above. where above exactly? What is the "original mipmaps"?
LiterallyACat Posted March 25 Posted March 25 I have been informed of a lack of these two LOD meshes, as well as 3 textures: Warning: File not found Meshes\dyndolod\nohavok\fireplacewood01burning_nohavok.nif. Used by DynDOLOD.esm FireplaceWood01Burning_DynDOLOD_BASERECORD [MSTT:53002106] Warning: File not found Meshes\dyndolod\nohavok\siltstrider01_nohavok.nif. Used by DynDOLOD.esm SiltStrider_DynDOLOD_BASERECORD [MSTT:5300243A] ... Warning: File not found textures\clutter\woodfire003.dds. Used by Meshes\dyndolod\nohavok\campfire01landburningup_nohavok.nif DynDOLOD.esm Campfire01LandBurningUp_DynDOLOD_BASERECORD [MSTT:53001F19] Warning: File not found textures\clutter\woodfire004.dds. Used by Meshes\dyndolod\nohavok\campfire01landburningup_nohavok.nif DynDOLOD.esm Campfire01LandBurningUp_DynDOLOD_BASERECORD [MSTT:53001F19] Warning: File not found textures\clutter\woodfirecap004.dds. Used by Meshes\dyndolod\nohavok\campfire01landburningup_nohavok.nif DynDOLOD.esm Campfire01LandBurningUp_DynDOLOD_BASERECORD [MSTT:53001F19] My quick search for 'fireplace', 'woodfire00', and 'siltstrider' did not seem to yield any results in these forums, and my check of the MO2 VFS also verified that they don't exist in an incorrect location. Is this an issue that needs to be rectified? Link to the full logs, if desired. DynDOLOD_SSE_log.txt DynDOLOD_SSE_Debug_log.txt Additionally (in the same logs), I noticed these: [00:06] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F] [00:06] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F] [00:06] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F] [00:06] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F] [00:07] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F] I haven't seen these errors before and can't find any info on them.
sheson Posted March 25 Author Posted March 25 41 minutes ago, z929669 said: Okay, so is it accurate to say that DynDOLOD generates mipmaps using the TexGen billboard texture as a basis at mip 0? By default a billboard texture has no mipmaps, so there is only one resolution to use. https://dyndolod.info/Help/3D-Tree-LOD-Model Note that by default mipmaps of textures that are added to the tree LOD or object LOD texture atlas are ignored and instead are generated from the largest resolution with an alpha-to-coverage algorithm so that small details do not fade into full transparency the further away they are. 41 minutes ago, z929669 said: If that's the case, I still don't understand the following. It implies that the mipmaps defined in the full texture are used rather than them being generated by DynDOLOD (because TexGen billboard textures do not have mipmaps, as you said): https://dyndolod.info/Help/3D-Tree-LOD-Model#Shape-Names - usemipmaps - if the textures used by this shape are added to the texture atlas, use original mipmaps instead of generating them. See above. where above exactly? What is the "original mipmaps"? I linked and quoted the "above" from the same page already: https://dyndolod.info/Help/3D-Tree-LOD-Model To use the mipmaps of the original texture defined by the LOD model, add the term UseMipMaps to the BSTriShape/NiTriShape name. This should preferably be done for all LOD models using this texture. Use an unique filename for such textures, so there are no problems with other mods modifying the same vanilla filenames. The page explains 3D tree LOD model creation and the use of full textures for the branches. The original mipmaps of the texture defined by the NIF, e.g. the 3D tree LOD model. In case of a billboard NIF, the defined textures are replaced by the actual billboard textures, so their mipmaps if they have any.
sheson Posted March 25 Author Posted March 25 9 minutes ago, LiterallyACat said: I have been informed of a lack of these two LOD meshes, as well as 3 textures: Warning: File not found Meshes\dyndolod\nohavok\fireplacewood01burning_nohavok.nif. Used by DynDOLOD.esm FireplaceWood01Burning_DynDOLOD_BASERECORD [MSTT:53002106] Warning: File not found Meshes\dyndolod\nohavok\siltstrider01_nohavok.nif. Used by DynDOLOD.esm SiltStrider_DynDOLOD_BASERECORD [MSTT:5300243A] ... Warning: File not found textures\clutter\woodfire003.dds. Used by Meshes\dyndolod\nohavok\campfire01landburningup_nohavok.nif DynDOLOD.esm Campfire01LandBurningUp_DynDOLOD_BASERECORD [MSTT:53001F19] Warning: File not found textures\clutter\woodfire004.dds. Used by Meshes\dyndolod\nohavok\campfire01landburningup_nohavok.nif DynDOLOD.esm Campfire01LandBurningUp_DynDOLOD_BASERECORD [MSTT:53001F19] Warning: File not found textures\clutter\woodfirecap004.dds. Used by Meshes\dyndolod\nohavok\campfire01landburningup_nohavok.nif DynDOLOD.esm Campfire01LandBurningUp_DynDOLOD_BASERECORD [MSTT:53001F19] My quick search for 'fireplace', 'woodfire00', and 'siltstrider' did not seem to yield any results in these forums, and my check of the MO2 VFS also verified that they don't exist in an incorrect location. Is this an issue that needs to be rectified? Link to the full logs, if desired. DynDOLOD_SSE_log.txt DynDOLOD_SSE_Debug_log.txt Additionally (in the same logs), I noticed these: [00:06] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F] [00:06] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F] [00:06] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F] [00:06] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F] [00:07] <Warning: File [A7] DynDOLOD.esp with Group GRUP World Children of WhiterunWorld "Whiterun" [WRLD:0001A26F] is missing an overriden record for WhiterunWorld "Whiterun" [WRLD:0001A26F] I haven't seen these errors before and can't find any info on them. The normal DynDOLOD log does not contain the initial output generation from scratch. The initial generation from scratch or maybe a later update generation should have generated the nohavok meshes to the output folder. The nohavok meshes are copies of full models with flags unset in the BSX block. Either the reported textures were always missing or the textures were deleted at some point as well. The "is missing an overriden record" is a message from the xEdit code. I believe it means group record is orphaned with references in the plugin.| Was the plugin loaded/edited in CK or other tools than xEdit? You should generate new output for the current load order from scratch as the message "Update existing plugin(s)? If this is not successful start from scratch" suggests.
z929669 Posted March 25 Posted March 25 1 hour ago, sheson said: TexGen by default ignores mipmaps of complex grass full textures when rendering billboards. UseMipmapsComplexGrass setting in TexGen_SSE.INI 28 minutes ago, sheson said: The page explains 3D tree LOD model generation and the use of full textures for the branches. The original mipmaps of the texture defined by the NIF, e.g. the 3D tree LOD model. Okay, so 'usemipmaps' keyword does not apply to the DynDOLOD source LOD models (e.g., DynDOLOD_flat_4x2alt2_lod.nif) when used for grass but does work for trees? I'm still confused by the very bright LOD grass result I posted at the start of this conversation when using this keyword in the model and assigning it to ComplexGrassBillboard. Was that just me breaking something that might cause that outcome?
z929669 Posted March 26 Posted March 26 Since I've not gotten further clarification/confirmation on my last post, I'm moving on to another issue. In my continued testing, I've noticed a cg grass that is not treated as such by DynDOLOD. It's being treated as a basic grass. The coloring is controlled by GrassBrightness* rather than ComplexGrassBrightness* in DynDOLOD_SSE.ini. This can be seen in my most recent run where I've set GrassBrightness* to be pure blue. cg grass colored by GrassBrightness* After looking more closely, I believe the grass to be fieldgrassTU (1).nif (fieldgrasstu (1).dds), which is a cg texture included with Cathedral Landscapes Complex Grass for ENB. It seems that the TexGen debug log stumbles a bit on this and a few other textures in the TwRender.* process. I can't find anything suspicious with this model in the DynDOLOD debug log. I'd like to understand the cause, because this issue isn't consistent between DynDOLOD runs. In my previous run, this blue was very dense and impacted larger areas. I didn't get a screenshot then because I was testing with MipMapTests and didn't want to conflate the two results (that's another matter). Anyway, it explains why my LOD results are inconsistent in terms of matching full with LOD grasses if some grasses are being treated as basic as opposed to complex by DynDOLOD. I think grass placements can vary at generation and/or cell load time, so that may explain why I have less blue this run and this same save. suspect grass logs
sheson Posted March 26 Author Posted March 26 6 hours ago, z929669 said: Okay, so 'usemipmaps' keyword does not apply to the DynDOLOD source LOD models (e.g., DynDOLOD_flat_4x2alt2_lod.nif) when used for grass but does work for trees? The shape names in the billboards NIF that are for DynDOLOD like usemipmaps or noatlas should have no effect since the billboards NIFs are not processed to find textures to be added to the object LOD atlas. In addition, billboards have no mipmaps that could be used. 7 hours ago, z929669 said: Okay, so 'usemipmaps' keyword does not apply to the DynDOLOD source LOD models (e.g., DynDOLOD_flat_4x2alt2_lod.nif) when used for grass but does work for trees? I'm still confused by the very bright LOD grass result I posted at the start of this conversation when using this keyword in the model and assigning it to ComplexGrassBillboard. Was that just me breaking something that might cause that outcome? I would assume there is also something else different between the two generation, either in the billboard NIF and/or billboard textures. I can not really answer this question without the different assets being used.
sheson Posted March 26 Author Posted March 26 3 hours ago, z929669 said: Since I've not gotten further clarification/confirmation on my last post, I'm moving on to another issue. In my continued testing, I've noticed a cg grass that is not treated as such by DynDOLOD. It's being treated as a basic grass. The coloring is controlled by GrassBrightness* rather than ComplexGrassBrightness* in DynDOLOD_SSE.ini. This can be seen in my most recent run where I've set GrassBrightness* to be pure blue. cg grass colored by GrassBrightness* After looking more closely, I believe the grass to be fieldgrassTU (1).nif (fieldgrasstu (1).dds), which is a cg texture included with Cathedral Landscapes Complex Grass for ENB. It seems that the TexGen debug log stumbles a bit on this and a few other textures in the TwRender.* process. I can't find anything suspicious with this model in the DynDOLOD debug log. I'd like to understand the cause, because this issue isn't consistent between DynDOLOD runs. In my previous run, this blue was very dense and impacted larger areas. I didn't get a screenshot then because I was testing with MipMapTests and didn't want to conflate the two results (that's another matter). Anyway, it explains why my LOD results are inconsistent in terms of matching full with LOD grasses if some grasses are being treated as basic as opposed to complex by DynDOLOD. I think grass placements can vary at generation and/or cell load time, so that may explain why I have less blue this run and this same save. suspect grass logs No clue what TexGen debug log stumbles a bit on this and a few other textures in the TwRender.* process is supposed to mean. The detection if a grass full texture is complex depends on the full texture. The TexGen debug log shows that the texture is being split into 2 temp textures, which should mean it was detected as complex. If LODGen applies the ComplexGrassBrightness* values depends on the line Complex=True in the billboard txt. That should not randomly change. https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots To get closer to LOD, toggle to the free fly camera with tfc in console.
z929669 Posted March 26 Posted March 26 5 hours ago, sheson said: The shape names in the billboards NIF that are for DynDOLOD like usemipmaps or noatlas should have no effect since the billboards NIFs are not processed to find textures to be added to the object LOD atlas. In addition, billboards have no mipmaps that could be used. I would assume there is also something else different between the two generation, either in the billboard NIF and/or billboard textures. I can not really answer this question without the different assets being used. Thanks for confirming why usemipmaps won't work on the NIF when the texture path of the NIF points to a texture that has no mipmaps. This makes sense now and confirms that my understanding of how it works is not totally off. I'm baffled as to shy there was a brightness change on that run though, as none of the textures changed. It may be related to the other issue with the blue GrassBrightness* values, which were set to be very bright that run. 4 hours ago, sheson said: No clue what TexGen debug log stumbles a bit on this and a few other textures in the TwRender.* process is supposed to mean. The TexGen debug I posted has over ten thousand lines processing the NIF I posted (and a few others before that): [01:32] [SplitComplexGrassTexture] <Debug: Processing textures\landscape\grass\fieldgrassTU (1).dds> [01:32] [dynLoadImage] <Debug: [textures\landscape\grass\fieldgrassTU (1).dds] ResourceExists> [01:32] [dynLoadImage] <Debug: [textures\landscape\grass\fieldgrassTU (1).dds] DXGI_FORMAT_BC7_UNORM> [01:32] [dynLoadImage] <Debug: [textures\landscape\grass\fieldgrassTU (1).dds] Executing "C:\Modding\Tools\DynDOLOD\Edit Scripts\Texconvx64.exe" -nologo -gpu 0 -y -m 1 -aw 256 -f R8G8B8A8_UNORM -srgb -o "C:\Users\David\AppData\Local\Temp\TexGen_SSE" "C:\Users\David\AppData\Local\Temp\TexGen_SSE\5B1472EAA4EC4240B73F173B983A1608.dds"> [01:32] [SplitComplexGrassTexture] <Debug: Splitting complex grass textures textures\landscape\grass\fieldgrassTU (1).dds into C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds 1 1, 0 0, 0 0> [01:32] [SplitComplexGrassTexture] <Debug: Splitting complex grass textures textures\landscape\grass\fieldgrassTU (1).dds into C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds> [01:32] [dynSaveImage] <Debug: Saving C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds> [01:32] [dynSaveImage] <Debug: Saving C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds> [01:32] [TwbRender.Render] <Debug: Used Model 4b Meshes\landscape\grass\fieldgrasstu (1).nif 1> [01:32] [TwbRender.LoadTexture] <Debug: Used Texture 2 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif -1> [01:32] [TwbRender.LoadTexture] <Debug: Loading C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds Cathedral Landscapes.esp FieldGrassTU_1_NoGrass [GRAS:FE0658A0]> [01:32] [TwbRender.MakeCurrent] <Debug: LoadGLMultiImage C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds Result: 4C011A7E aRC: 30000 (Textures) aDC: 0> [01:32] [LoadGLMultiImage] <Debug: Loading C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds> [01:32] [TwbRender.ReserveID] <Debug: Creating 7 LoadGLMultiImage C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds> [01:32] [LoadGLMultiImage] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds mipmap max 10> [01:32] [LoadGLMultiImage] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds done 10> [01:32] [TwbRender.MakeCurrent] <Debug: LoadGLMultiImage C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds Result: 0 aRC: 0 () aDC: 4C011A7E> [01:32] [TwbRender.LoadTexture] <Debug: Used Texture 2 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif -1> [01:32] [TwbRender.LoadTexture] <Debug: Loading C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds Cathedral Landscapes.esp FieldGrassTU_1_NoGrass [GRAS:FE0658A0]> [01:32] [TwbRender.MakeCurrent] <Debug: LoadGLMultiImage C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds Result: 4C011A7E aRC: 30000 (Textures) aDC: 0> [01:32] [LoadGLMultiImage] <Debug: Loading C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds> [01:32] [TwbRender.ReserveID] <Debug: Creating 8 LoadGLMultiImage C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds> [01:33] [LoadGLMultiImage] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds mipmap max 10> [01:33] [LoadGLMultiImage] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds done 10> [01:33] [TwbRender.MakeCurrent] <Debug: LoadGLMultiImage C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds Result: 0 aRC: 0 () aDC: 4C011A7E> [01:33] [TwbRender.LoadTexture] <Debug: Used Texture 2 textures\landscape\grass\fieldgrassTU (1).dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif -1> [01:33] [TwbRender.LoadTexture] <Debug: Loading textures\landscape\grass\fieldgrassTU (1).dds Cathedral Landscapes.esp FieldGrassTU_1_NoGrass [GRAS:FE0658A0]> [01:33] [TwbRender.MakeCurrent] <Debug: LoadGLMultiImage textures\landscape\grass\fieldgrassTU (1).dds Result: 4C011A7E aRC: 30000 (Textures) aDC: 0> [01:33] [LoadGLMultiImage] <Debug: Loading textures\landscape\grass\fieldgrassTU (1).dds> [01:33] [TwbRender.ReserveID] <Debug: Creating 9 LoadGLMultiImage textures\landscape\grass\fieldgrassTU (1).dds> [01:33] [TwbRender.MakeCurrent] <Debug: LoadGLMultiImage textures\landscape\grass\fieldgrassTU (1).dds Result: 0 aRC: 0 () aDC: 4C011A7E> [01:33] [TwbRender.LoadScene] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Loading Meshes\landscape\grass\fieldgrasstu (1).nif> [01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.LoadScene C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 4C011A7E aRC: 30001 (Meshes) aDC: 0> [01:33] [TwbRender.LoadScene] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Vertexdata: 9> [01:33] [TwbRender.LoadScene] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E FieldGrass01:0 Meshes\landscape\grass\fieldgrasstu (1).nif 0 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds 7> [01:33] [TwbRender.LoadScene] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E FieldGrass01:0 Meshes\landscape\grass\fieldgrasstu (1).nif 1 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds 8> [01:33] [TwbRender.LoadScene] <Debug: Checked 1 FieldGrass01:0 Meshes\landscape\grass\fieldgrasstu (1).nif> [01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.LoadScene C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 0 aRC: 0 () aDC: 4C011A7E> [01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.Draw C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 4C011A7E aRC: 20002 (Render #0) aDC: 0> [01:33] [TwbRender.SceneSet] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E 1> [01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.Draw C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 0 aRC: 0 () aDC: 4C011A7E> [01:33] [TwbRender.Render] <Debug: Used Model 5b Meshes\landscape\grass\fieldgrasstu (1).nif 0> [01:33] [TwbRender.Render] <Debug: Used Model 4b Meshes\landscape\grass\fieldgrasstu (1).nif 1> [01:33] [TwbRender.LoadTexture] <Debug: Used Texture 1 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif 334203> [01:33] [TwbRender.LoadTexture] <Debug: Used Texture 1 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif 334203> [01:33] [TwbRender.LoadTexture] <Debug: Used Texture 1 textures\landscape\grass\fieldgrassTU (1).dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif 334203> [01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.Draw C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: FFFFFFFFEF0117F4 aRC: 20002 (Render #0) aDC: 0> [01:33] [TwbRender.SceneSet] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E 1> [01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.Draw C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 0 aRC: 0 () aDC: FFFFFFFFEF0117F4> [01:33] [TwbRender.Render] <Debug: Used Model 5b Meshes\landscape\grass\fieldgrasstu (1).nif 0> [01:33] [TwbRender.Render] <Debug: Used Model 4b Meshes\landscape\grass\fieldgrasstu (1).nif 1> [01:33] [TwbRender.LoadTexture] <Debug: Used Texture 1 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65.dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif 334640> [01:33] [TwbRender.LoadTexture] <Debug: Used Texture 1 C:\Users\David\AppData\Local\Temp\TexGen_SSE\2C5F5123826A420B8A4B4AB3EB1F0E65_n.dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif 334640> [01:33] [TwbRender.LoadTexture] <Debug: Used Texture 1 textures\landscape\grass\fieldgrassTU (1).dds 1 Meshes\landscape\grass\fieldgrasstu (1).nif 334640> [01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.Draw C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 4C011A7E aRC: 20002 (Render #0) aDC: 0> [01:33] [TwbRender.SceneSet] <Debug: C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E 1> [01:33] [TwbRender.MakeCurrent] <Debug: TwbRender.Draw C:\Users\David\AppData\Local\Temp\TexGen_SSE\45AC5C6EF2224F6FB5028652F19E6D7E Result: 0 aRC: 0 () aDC: 4C011A7E> [01:33] [TwbRender.Render] <Debug: Used Model 5b Meshes\landscape\grass\fieldgrasstu (1).nif 0> [01:34] [TwbRender.Render] <Debug: Used Model 4b Meshes\landscape\grass\fieldgrasstu (1).nif 1> ...these last 20-ish lines repeat similarly for hundreds more iterations and thousands more lines for this one model. No other but a handfull of textures consume this volume of log space just before it. 4 hours ago, sheson said: The detection if a grass full texture is complex depends on the full texture. The TexGen debug log shows that the texture is being split into 2 temp textures, which should mean it was detected as complex. If LODGen applies the ComplexGrassBrightness* values depends on the line Complex=True in the billboard txt. That should not randomly change. https://dyndolod.info/Official-DynDOLOD-Support-Forum#In-Game-Screenshots To get closer to LOD, toggle to the free fly camera with tfc in console. The full texture of all these tundra grasses are constructed in the same 1x2 format as the texture I posted with the model previously. The TexGen preview of every single grass in my game registeres as cg. Therefore, if I have these patches of blue grass, some of them are being treated as basic grass by DynDOLOD for some reason. I'm pretty sure it's fieldgrasstu (1), but it's not easy to distinguish from the low-res LOD model using tfc. Since I cannot use MIC, there's some guesswork involved. I'm hoping you will trust the facts though and that some cg grasses are not being treated as complex. I've reloaded this save on this generation several times, and the same grasses appear as blue. As I mentioned, in a previous generation, the volume of blue tundra grasses was much higher. Later today, I will exit and reload these cells to see if the pattern and frequency changes. It may have something to do with rendering from the grass cache, IDK, but it's a 'thing'.
sheson Posted March 26 Author Posted March 26 1 hour ago, z929669 said: The TexGen debug I posted has over ten thousand lines processing the NIF I posted (and a few others before that): ...these last 20-ish lines repeat similarly for hundreds more iterations and thousands more lines for this one model. No other but a handfull of textures consume this volume of log space just before it. What matters are the generated billboard textures and text file for the grass record. Verify those are as expected. 1 hour ago, z929669 said: The full texture of all these tundra grasses are constructed in the same 1x2 format as the texture I posted with the model previously. The TexGen preview of every single grass in my game registeres as cg. Therefore, if I have these patches of blue grass, some of them are being treated as basic grass by DynDOLOD for some reason. I'm pretty sure it's fieldgrasstu (1), but it's not easy to distinguish from the low-res LOD model using tfc. Since I cannot use MIC, there's some guesswork involved. If LODGen applies the ComplexGrassBrightness* values depends on the line Complex=True in the billboard txt. That should not randomly change. Check if the billboard text file contains that line. LODGen multiplies the vertex colors of the billboard NIF with these values when they are added to the object LOD meshes. 1 hour ago, z929669 said: I've reloaded this save on this generation several times, and the same grasses appear as blue. As I mentioned, in a previous generation, the volume of blue tundra grasses was much higher. Later today, I will exit and reload these cells to see if the pattern and frequency changes. It may have something to do with rendering from the grass cache, IDK, but it's a 'thing'. No sure if reloading cells refers to loading in the game. That will not change the vertex colors in the LOD meshes. Nothing is rendered from the grass cache. The cache files are used for position, rotation, scale, brightness (single value applied to all 3 vertex color channels equally).
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