Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Phlunder

  • Rank
  1. 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.
  2. 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.
  3. 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
  4. Oh, I didn't mean to imply that anything was lost in the process. Thanks for clearing it up!
  5. 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:
  6. 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?
  7. 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.
  8. 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.
  9. 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.
  10. 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!
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.