Phlunder

Sorry for being an idiot and ignoring the big highlighted text in the first post. I'll get you the logs shortly. I am not sure about the stones, and yes there is no rock2b_lod.nif. I just looked at Enderal's rock LOD assets because I couldn't figure out where it was getting it from. I realize now that the naming convention has to match up too. The ref ID of the building in question is 98273. The stones with the described issue are right next to it, maybe that helps too. Regarding the visual artifacts on transition from object LOD to full model for trees, the issue doesn't happen when I use the traditional billboard system, just tested that. But maybe the logs will clear that up. Give me a minute to rerun everything.

I've been testing the new alpha on Enderal LE, on a new vanilla test profile. So far, almost everything seems fine. I ran into two issues, one of them I hopefully already identified. The first is that there is an incorrect LOD stone mesh packaged with Enderal, its base ID is 8e844. It has been assigned very different shaped, sized, and textured LOD mesh found here: "meshes\enderal\lod\rocks\rock02_lod_1.nif" In the screen its also visible that the LOD mesh of the building has a different shape, but I guess that's because its a vanilla Riften house (RTMeadery01 [STAT:0008C018]), with just a certain part reused in Enderal? Comparison screens are in the spoiler: The other issue is a bit harder to grasp for me. Certain tree types (haven't identified them all, one is _00E_NOaktree08 [TREE:001130D4]) have very weird visual artifacts when transitioning from object LOD to full model. I'm using the high preset and ultra trees, which means for Enderal trees in object LOD with normals. Textures have been freshly generated with TexGen beforehand. Here's a screenshot of the issue: Thanks again for your continued work and dedication on DynDOLOD and xLODGen!

Thanks for the quick response! Yes, I noticed, due to the missing capability I had to make changes to the LOD textures to take the visual impact of the parallax effect on full models into account. Now that I think of it, to give those full models as LOD a different texture, I would have to make them a different mesh with unique texture path assigned. I wonder if it would make sense to just replace the LOD models with the full ones, and assign a special texture to it. Not sure why they've gone through the trouble of making so many unique LOD meshes for those glaciers, they don't really have much shape complexity to begin with. Thanks for the ideas! I'll try to figure something out. Best way would be to create new reduced LOD models for the glaciers of course... Just beyond my capabilities.

Hey sheson! Thanks for all the latest improvements to DynDOLOD 3.0. The renderer for custom object and tree LOD textures is really something else, perfect match now! Having trees with normal maps in object LOD helps a lot too, once they are matched in terms of brightness of the diffuse, they blend well in every situation! Good stuff! I still have issues with blending the damn glaciers, even with custom made LOD textures to match, their horrible UVs make it hard to make them look good. For mountains/unique, I used a suggestion of yours from a while ago, creating a ruleset that pushes certain LOD stages farther out. The LOD4 step of mountain LOD almost always uses the full mountainslab texture, so pushing that step out to LOD8 helps a lot. Could a similar thing be done with glaciers as well? Their LOD4 model already uses custom textures though. Maybe pushing the full model (they are not very complex in terms of shape) out to LOD4 or LOD8? Would that be possible with rules? Performance impact is a given of course.

Just now got around to testing 3.0 alpha, great work! The addition of the TexGen renderer is incredible, saves so much work when using custom textures. For object LOD, this looked great so far in my testing. Tree LOD billboard creation also works flawlessly, I just ran into a small thing while playing around with it. The atlas is saved with mip-maps, which has some downsides in how those distant objects with these kind of alphas display. Especially the aspens look very "blurred" for lack of a better word, they loose a lot of detail. Resaving the atlas without mip maps fixes that. The testing was done on vanilla trees with vanilla textures. Would it be possible to add an option to save the tree LOD atlas without mip maps directly? Maybe its also an issue with alpha testing/threshold values, not sure.

Setting the Has Tree LOD flag directly in the Dawnguard.esm worked! So its really not picking up on it in overwrite records. This time, DynDOLOD also immediately listed it at the start together with the other available billboards. Before it just mentioned it because its missing a normal map. Still added it to the atlas but I guess the placement data was never written into the BTT file? Again, thank you for looking into this. I know it was kind of an edge-case.

That did indeed work! The 3D LODs now all show up fine. Thanks a lot for looking into this. I didn't check out the mesh folders for the 3D trees before, but the naming mismatch issue immediately jumped at me when I did. I had to rename them differently though, without the additional "nif" in between the record name and passthru. So dlc1treewinteraspensnow03passthru_lod.nif instead of dlc1treewinteraspensnow03nifpassthru_lod.nif for example, just like the 01 variant is named. Does that mean the regular billboard system will work for this specific case too with the next update?

That makes sense. Really not sure whats going on then. I just tested it with ultra trees, and its the same issue. I believe not all of those DLC1TreeWinterAspenSnow trees have 3D LOD models included in DynDOLOD, but the "01" variant has for sure. For all the other trees this works flawlessly, and the 3D LOD models look great by the way. But all the DLC1TreeWinterAspenSnow01/03/05 are missing their full 3D LOD model (in case of 01) and their fallback billboard as well. A screenshot of one of those places where the missing 3D LODs/billboards are noticable (also notice the 2 WinterAspen04 billboards working): https://i.imgur.com/lf7oL4L.png https://i.imgur.com/JhTzJX4.png

Thanks for the fast reply! I probably should have mentioned that I'm on LE, not SE. Or are large references also a thing in LE? I currently don't use ultra trees. Not sure what could be the problem then, the trees/statics in question are positioned perfectly upright, not sure how to tell if they are dynamic though. Its not a big deal, I just thought I was overlooking some limitation or rules to assign billboards to them.

Hey sheson, first thank you for your continued work on DynDOLOD and xLODGen! Maybe you can help me with a minor problem I've ran into. I created new tree billboards for the Soul Cairn and Forgotten Vale, which don't have any billboards at all by default. The billboards work and show up fine, but some trees in the Forgotten Vale are for whatever reason statics, not tree records. An example would be DLC1TreeWinterAspenSnow01 [sTAT:0200CE13]. I also created billboards for those statics plus the appropriate text files, but they won't be recognized by DynDOLOD. If I give those statics the flag "Has Tree LOD" DynDOLOD picks up on them and adds them to the texture atlas (with alpha) but the billboards still don't show up. Is there a way to give those statics billboards without replacing them with actual trees?