Phlunder

I thought about using full textures too (similar to LOD0 mountain meshes) but it just made the meshes invisible. This may be due to the alpha of the diffuse? I didn't generate with using full textures though, I just swapped out the files with full textures after the fact. I try generating with full textures assigned in the LOD meshes and will report what DynDOLOD does. Thanks for the hint, I was wondering what is the better choice in terms of performance, it makes sense that its the full texture as its already loaded into VRAM anyway. I'll report back.

I realized that now too. Unfortunately, the glacierslabreallod.dds is 4x tiled so I can't assign it for the glacier meshes, as I would have to redo/rescale the UVs. I don't wanna create any complications for you of course, or make TexGen generate redundant files. So I understand if its not a priority.

It seems to be fixed! Thank you so much, looks great now.

Base ID is 1ef3b, ref ID is 201114b. I had to switch to smaller worldspace (falmervalley/Forgotten Vale) to not generate gigabytes of output again, sorry. Just was faster to check.

I reran with the new executable and the issue seems to be the same - comparison with old and new LODGenx64 executable:

The issue is the same for a lot of rock/cliff LOD assets. Here are just 2 examples: RockCliff02Snow01 [STAT:0001EF3B] Example ref ID: [REFR:00097F0B] RockCliff08_HeavySN [STAT:0002ED7A] Example ref ID: [REFR:00028C51]

I already checked, I use no mods that edit the snow shader/Material Object records, and the mountain LOD meshes in question are provided by Resources 3.00 Alpha 17.

Yes, issues are exactly the same with DynDOLOD Alpha-59 and Resources 3.00 Alpha 17. Just had the time to regenerate with the latest update now. Edit: Just realized that I posted in the wrong thread, sorry. And yes I will upload logs shortly. The Ref ID for the Riften building is 63df7. The Ref ID of the rock/mountain piece is 6e1ed. But pretty much all LOD rocks are affected by this. Logs: https://ufile.io/f/n6unf I hope this helps to show what I mean with different LOD snow shader coverage:

Thanks for the update! I hope I can bother you with another question. I read the info page on snow/ash shaders and LOD on your new DynDOLOD page carefully, but I still can't figure out these 2 tiny problems I ran into. For one, the RTSnowShodHouse01 [STAT:00063DF7] in Riften has snow cover on its roof for some reason. I have no mods that edit the cell or the reference itself. What could cause that? Edit: Wait, didn't I read there was some logic that detected if snow was in the base ID name? Its of course just the family name from the house owners - so that might be a unintended side effect of that detection? Sorry if I'm way off here. The other thing I noticed is that LOD rock/mountain meshes that are in snowy areas are now fully covered in snow. I hope it makes sense what I say - the snow shader is directional for the full model, so just the top part has dynamic snow applied. As I understood LOD handles dynamic snow the same way as in loaded cells? Maybe its the fault of my retexture too, I am not sure. Here's a picture of what I'm referring to: These were generated with the DynDOLOD version and Resources released before the update today. I can upload logs if needed as well.

Ah, so they are currently not using the atlas, but the glacierslablod textures directly? I thought of the glacier LODs similar to the LOD0 mountain meshes (which I use in all LOD stages with a rule in DynDOLOD) so I assumed that method was okay? Similar to mountainslab, its also just a single tiled texture for the whole object. I guess, this is a bigger problem with complex meshes like farmhouses or other buildings that use multiple texture sets. And all of them not using the atlas would degrade performance quickly. Simplygon sounds interesting, thanks for mentioning it!

Thanks for taking care of those trees! Regarding the glacier LOD meshes, touching the UVs was something I tried to avoid, haha. But thanks for making me aware of that! I know about the UV range of 0.0-1.0 for older games like Fallout 3, as the LOD textures were broken if they were outside of that range. Is there any way to take care of that in Blender, without redoing them by hand? Because that sounds like a nightmare... I checked the draw calls with ENB to make sure the performance impact is minimal, but if possible I would of course optimize them further. And thanks, I missed that glacierslabreallod.dds (glacierslabreallod_n.dds too I guess) was generated by TexGen. I will change the assigned texture then!

Hey sheson. I have to circle back to a conversation from years ago. In recent runs of DynDOLOD, I noticed that a few trees in the Forgotten Vale were missing LOD again. Then I remembered when I worked on Seamless Billboards that I had to include a plugin to give some duplicate winter aspen trees (as statics) the Has Tree LOD flag to be picked up. As I don't use my billboards or the plugin anymore, this just caught my attention. Maybe you could include them? The statics in question are: DLC1TreeWinterAspenSnow01 [STAT:0200CE13] DLC1TreeWinterAspenSnow03 [STAT:0200CE11] DLC1TreeWinterAspenSnow05 [STAT:0200CE12] I also worked on those replacers for the glacier LOD meshes we talked about a while ago. As you suggested I used the full models and decimated them by hand and with Blender's tools. If you're interested, you can find them here.

Ahh, so it was Noble Skyrim which caused it. Thank you for explaining the issue (that was my own doing) in detail. I already tried to assign the same whoutwall texture to that part, but it was still darker than the adjacent parts. Turns out I had to match the Vertex Colors too! I also renamed the NiTriShape to Windhelmbridge:2 as you suggested. Looks perfect now. Thanks again, and happy holidays to you!

Hey sheson! I noticed that the Windhelm bridge LOD model (both windhelmbridge_lod.nif and windhelmbridge_lod_1.nif) has a black spot in the latest DynDOLOD Resources 3.00 Alpha 15. The windhelmbridge_lod_2.nif is not affected. A picture of the issue with comparison to the full model: I did notice that this part of the model uses a different texture than the rest of the outer wall, though the issue isn't apparent on the full model or the vanilla LOD model.

Thanks, I was unaware of that command! I always use DynDOLOD's MCM to figure out my current cell, heh. Thank you for the FO4LODGen Resources by the way, brings sanity to the sometimes messy and unfinished state of the vanilla LOD assets.

I had to figure out that I have to disable precombines first to even be able to click any static reference. I think I found the cell, and the issue? It has the data flag No LOD Water in vanilla, for whatever reason. I am not sure how to find the water record in question though. Edit: Removing the No LOD Water flag and regenerating terrain LOD fixed it! Thanks for bringing me on the right track!

I ran into a small issue generating terrain LOD meshes for FO4 using the latest beta 85. The xLODGen output seems to disable LOD water in a specific cell. I know this technically shouldn't be a thing, but toggling the xLODGen output off shows that cells water LOD again. The area I am referring to is under the highway overpass. The LODGen log shows no errors: https://pastebin.com/mXTqLStF

Sorry, for now I couldn't reproduce it, it was crashing (task not responding for a moment) at: [00:06] <Warning: File not found Meshes\enderal\clutter\propertysign°.nif. Used by Skyrim.esm _00E_PropertySign "Property Sign" [ACTI:0006A13E]> And then just said file not found. Now it runs through just fine, also with seperate Occlusion ESP unchecked. Using latest Windows 10 21H1 with only Windows Defender and all game and tool folders in exceptions of course. If I run into it again, I'll post the debug log right away. I didn't know its being replaced each time.

Yes, those stones are looking fine now, thanks for looking into it! Regarding the Occlusion ESP, with the latest Alpha-48 the separate Occlusion ESP option is definitely checked by default when in Enderal mode. I tested this on a new instance of DynDOLOD to be sure that no presets/changes of mine were still there. When I disabled the separte plugin option, DynDOLOD crashed on generation, due to a seemingly unrelated issue with some sign mesh. Logs with bug report here: https://ufile.io/f/3ofql The second run where I let the option for a seperate Occlusion ESP checked ran through fine. Not sure if related.

I was about to report a similar thing. I am currently only testing on Enderal LE, and with the previous builds, no Occlusion plugin was created, but it seemed that the data was included in the main DynDOLOD ESP, and the log also showed that it was being created. Now with the latest build, it created a separate Occlusion ESP. Not sure what changed, settings were exactly the same. Here are the logs from last running DynDOLOD with Alpha-48 and Resources Alpha-14, also regarding the black LOD meshes for the stones that were added. Everything seems fine with the LOD mesh and its texture path, and it displays fine in NifSkope, can't make any sense of it: https://ufile.io/f/zqn1l

Oh, I didn't mean to imply that anything was lost in the process. Thanks for clearing it up!

Thanks for the update! I tested both the TexGen scaling changes for billboard resolution and the Riften house and stone LOD issue. The TexGen scaling seems perfect now, but its gone both ways, some billboards are now generated smaller, some are 4x bigger than before. But all changes seem reasonable and consistent, just from flying around the map and checking the billboard sizes and according resolution. The custom Riften house LOD is now fine, I guess the LOD mesh is split in parts now? The stones are okay now too, but they seem to have a very dark texture assigned, or its the mesh itself, not sure. Here are some pics. No other mods are used, ENB is disabled:

Again, you were right, it was indeed 0008E83A that had the weird LOD model issue from my original post. There were so many placed close and on top of each other that I must have clicked on the one right next to it. Come to think of it, weird that the ones I misclicked have no LOD meshes assigned but the others do. From my experience (working on textures) these ancientruins and medievelpack assets can be very crude. The specific stone meshes are so simplistic they should act well as LOD meshes too heh. Edit: Sorry, I think I get it now. Those stones have no LOD, DynDOLOD just grabbed the other LOD mesh because it has the same naming convention?

Yes, you are right, just checked with tll command and the issue also happens with LOD toggled off. I guess the LOD switching of regular billboards just makes it less visible, or even hides the issue... not sure. I never noticed it before I switched to billboards as object LOD. Sorry for bothering you with that then. I'll look into potential issues with the full model. I'll revert to traditional billboards if necessary, that's fine. Another question regarding billboard generation with TexGen. The screen resolution scaling works like a charm for Skyrim trees, I'd even argue the automatically picked lower resolution for smaller trees helps with the appearance when rendered from afar. Though for some Enderal trees, like the "kapok01_0009093f" the scaling seems to pick something too small for their full model size. Is that because some trees were just scaled up from their default size? For some, like the widely used "kingstree01_0014f9a6" the scaling is fine, as it picks the max size (1K resolution on either axis). The logs are still relevant for that question, if they are of any help in that regard. I know I can overwrite the automatic size scaling manually, just trying to understand how it picks relative billboard resolution.

Here are the logs: https://ufile.io/f/2hfza Yes, I checked the TexGen output for any curiosities, but diffuse and normal for the tree in question (in the screenshot) look fine.