Phlunder

I've seen these errors, unfortunately Enderal has a few of those. I will look into covering those missing normals. I checked the normal map atlas for the tree LOD, and the only thing that stands out is that the trunks of some of the trees have flat normals, the crown is always covered. And two tree types not shown in the screenshots have flat normals too. Here's the output atlas, if it helps: https://drive.google.com/file/d/1EaqpfUik1h8DTPHO3tuy1ap7nF9YG78i/view?usp=sharing I thought its maybe something with those trees brightness too, but then again, there are other trees in the game (and in vanilla Skyrim) that are brighter, like snow pines, and they don't have this issue. They are also seen in the screenshot. Near the glaciers.

Hey sheson, thanks for updating so fast to include the new resources for Enderal! They work great! If you remember, quite a while ago I posted some pics of visual artifacts when using ultra trees in Enderal. You were right back then, it was the fault of some of the custom tree models in Enderal. I was finally able to fix these meshes, so they don't show visual artifacts when fading in from object LOD. The results are great, and I'm happy to finally be able to use ultra trees (Billboard4) in Enderal: The only thing that still gives me headaches are the tropical trees. There is now great blending for all tree types, but for some reason these are unnaturally glowing. I can't figure out why. I included a shot where you can see other tree LODs that look fine from the same view point. ENB is not used in the shots, and I also tried other weathers (fw 81a) but its always the same result: An example reference would be 11F62D. Logs are here: https://drive.google.com/file/d/1iavFfJ24R-tDT1hqwuxLolyApltIvdPi/view?usp=sharing

No issues to report, Alpha 73 working great here! I have a small suggestion regarding the LOD resources for Enderal. The Powder Desert has a variation of Blackreach pillars which are missing LOD. DynDOLOD's Resources already cover the Blackreach variant, the only difference of the Enderal variant is that the top part has a sand texture assigned. Maybe it would be possible to reuse the Blackreach pillar resources here? The statics in question are: _00E_SandDesertPillar01 [STAT:000431DA] _00E_SandDesertPillar02 [STAT:000431DB] _00E_SandDesertPillar03 [STAT:000431DC] _00E_SandDesertPillar04 [STAT:000431DD] _00E_SandDesertPillar05 [STAT:000431DE] _00E_SandDesertPillar06 [STAT:000431DF] An example reference would be 6216C.

Reducing fBlockLevel0Distance to 44000 fixes it in 99% of cases in FO4. Since using that value, I personally didn't run into that issue at all anymore. Its another value in SSE but using DynDOLOD and sheson's suggested settings I never seen it there either.

I didn't see an increase. Not sure if I'm looking in the wrong place though. I brought the UVs into the 1x1 range with NifSkope. Covered all Riekling architecture now. They all use shared textures from the atlas, and it all works on the fly when generating with DynDOLOD, very nice! They are probably still a bit too detailed, but I guess its fine:

Thanks for all the helpful insight. I am not sure how to check triangle count after generating LOD. Are you referring to the model in the BTO mesh? Regarding UVs, for these models it was relatively easy to get them in the 1x1 range, as they were in 2x2 range by default. It was just daunting to do that for models like the glaciers. The models are indeed very small so I'll see what works best there, maybe isn't necessary to have them in all LOD stages. For now I just created a single LOD model for each object. I know that this wouldn't work with ones that have many references. The models also aren't as optimized as the ones in the DynDOLOD Resources or vanilla game, I am aware of that. I always try to reduce them to roughly 1/5th their full model poly count/vertices but at a certain point it breaks the shape and UVs. And yes I inherited the NiTriShape names and structure of the model. I realize that on a big scale with many references (Tamriel worldspace mostly) these models wouldn't be ideal. But Solstheim is too small for any impact probably.

Just a short report on DynDOLOD 3.00 Alpha 60 working as intendend! I started cover some of the Riekling architecture. Created decimated meshes, and tweaked the UVs inside the range of 0.0-1.0 as you suggested. I kept the full texture assigned in the model. DynDOLOD automatically created downscaled textures from the full ones and added them to the atlas. I didn't assign any LOD to the static record, DynDOLOD picked it up automatically from the standard naming scheme I used (I guess?) "full model name"_lod.nif. I also tried Simplygon, but its Blender plugin seems to be broken right now... but the native tools helped as well. If this doesn't belong here, feel free to tell me so!

I used Billboard1 with HD Tree LOD in object LOD for quite a long time now, and while it does react better to light than regular billboards, Billboard4 is really perfect now. I'll try not to miss your suggestions the next time, the whole site has always been a great resource for me!

That makes sense. It just took me a while to figure out it was even an option. Its a drastic improvement, and its performance friendly too. Great alternative to 3D tree LOD indeed, as stated on the info page.

While reading through your new info page, I stumbled upon your suggestion to try Billboard4 for HD Tree LOD in object LOD. I have to say, I am blown away. I never saw such good blending and reaction to lighting from billboards. No need to change anything about lighting settings in TexGen either. Perfect blending with every setting on default - with or without ENB - no matter which weather mod. This is great, I just wanted to leave a big thank you - again! I just have one question: Why isn't this setting used by default?

Your suggestion worked out perfectly. The fact that this texture is slightly darker helps, because of the slight visual difference that is still there due to LOD not supporting parallax. The effect does make the mesh darker - kind of - so that's a perfect match. I will just assign this texture for all of them. Yes, its funny that people just notice the flickering/Z-fighting on transitions now... I reduced the scale to 0.99 and it fixes it, but of course the mesh "grows" a tiny bit on transition from LOD to full model. I guess this is due to glaciers being such large objects to begin with. I'll see what value works best. Screen using glacierslabnoalpha.dds/glacierslabnoalpha.dds_n:

It seems it didn't work out, they didn't use the full textures as assigned in the mesh, and the UVs seem to be broken. I didn't see anything before atlas creation regarding glacierslab textures in the log. Log: https://ufile.io/f/8af5s Mesh in question is base ID 0401b927, ref ID 0401459b: Another small question. People are complaining about a slight Z-fighting on LOD transition. I know this is because I didn't change the size/scale of the LOD meshes when creating them, compared to full model. Could I use the scale option of the NiTriShape in NifSkope to just scale them to say 0.95 or 0.9 to fix that?

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!