Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Shad0wlife

  • Rank

Profile Information

  • Gender
    Not Telling
  1. Ok, so I browsed around https://srmap.uesp.net/ for a bit and searched for a pattern... seems like: Pine tree intensive areas are x4 to x4.5 the poly count vs EVT and Aspen tree intensive areas are x10 or more. Guess I found the big problem. Aspens have more fancy trunks that cause tons of polys, while the pines have simple trunks but higher poly branches which I could remove for the lod... So Step 1: How to make the Billboard trunks? Step 2: Add billboard trunks to the models Step 3: (a little bit of) profit... I'm actually trying to see if I can piece together Lod meshes for S3D Trees from the other lod meshes by scaling the needles and stacking them onto each other so they result in about the same outline as the S3D Needles... But if the Aspens are the major problem, then that won't really help that much...
  2. Ok, I have now disabled the fallback and put the tree meshes with the passthru and CRC32 name in the correct place. And even though they should "only" have up to 4 times as many triangles as the EVT hybrid trees, some cells have 10x as many triangles while other only have 1.5 times as many... I'll take a closer look at that ingame I guess...
  3. Yeah, I know that using the high poly leaves will keep the file size up, but I wanted to reduce the poly count at least a bit, so I removed all the branches which are not part of the trunk model, and also removed all the high poly snow and instead created a bit snowy textures. That doesn't make the models proper LQ Lod models, but at least I reduced them in size by 20 to 60%, which hopefully SOMEWHAT helps with the LOD size. Ok, so if the meshes have the name modelname_CRC32_lod.nif, is that enough or does it have to be modlename_CRC32passthru_lod.nif? The trees do not even seem to search for lods: TreePineForest01 [TREE:0001306D] meshes\landscape\trees\treepineforest01.nif Billboard found, replaced tree, 3D LOD found LOD4: meshes\landscape\trees\treepineforest01.nif ... While the fern and so on seem to be handled as trees and get loaded as their full models: TreeFloraSnowberry01Snow "Snowberry" [TREE:000BCF34] meshes\plants\florasnowberry01snow.nif, new tree, 3D LOD not found <florasnowberry01snow_e8ee0773> fallback Full Model LOD4: meshes\plants\florasnowberry01snow.nif So I guess that not only the full tree models get used (it didn't even say that it hasn't found 3D lod) and that all the plants like fern and bushes get a fallback to the full model too... I'll try adding the CRC to the (a little bit) reduced meshes and see if that helps finding them...
  4. Hmm. I put my clutter reduced mesh files into meshes\DynDOLOD\lod\trees but the generated Lod is still the same size even if some meshes were reduced to below half their file size (and probably even more in poly count)... I didn't do the crc32 and passthru stuff since i mostly followed the "Create Static Tree Meshes Manually" Tutorial which just says "Save the updated empty_lod.nif as [original filename of full model tree]_lod.nif", so I saved my files as treeaspen01_lod.nif for example. Or is the issue that I simply used the original file and deleted unneeded parts from the mesh instead of pasting into the "emptypassthru_lod.nif" file (there's no "empty_lod.nef" file as in the tutorial), because the pasted BSTriShapes became invisible (maybe a problem when copy pasting from a BSLeafAnimNode to a BSFadeNode? If so, how would I avoid that?) Or is it that I did not save or use any dedicated lod textures in the textures\lod folder? BTW, the highest poly count with the full models that I saw for a cell on a quick glance was 5,081,285 triangles. I guess that counts as "not considered usable anymore", right? xD
  5. Actually, I'm fine with the way the Lod meshes from EVT look. Would it be possible to use the S3D Trunk and change the shape of the green stuff (depending on tree) so that it mostly matches S3D tree's shapes? That way, one would have 3D Lod Trees with a lower performance impact, right? Biggest problem now is - how to actually make the shapes match? For example, S3D's pine 1 is much wider towards the top than EVT's... Would just pulling the vertices in place with blender or so be sufficient? (Yeah I know that that is a TON of work.) EDIT: For now, I'll just try and see how much actual impact the 37gb of lod has. Maybe it's tolerable...
  6. Wanted to edit again, but can't anymore, so sorry for double post [feel free to merge or so]. Found where EVT keeps its static meshes and checked - Skyrim 3D Trees doesn't have the DynDOLOD/lod/trees/{meshes} folder, so that's probably the culprit of my massive btos... Gonna try and generate them myself, now that I have actually found my way through the rest of the DynDOLOD documentation, where that is nicely explained. Request: could you maybe make some kind of index page for the docs which briefly explains what some files do and links them with relative paths (if possible, have very little experience with html stuff)?
  7. Alright. I actually do understand what TreeFullFallBack=1 does, but I just wasn't expecting such an extreme change with so little mod change. Just for clarification: The OLD setup used EVT and also Ultra Trees with TreeFullFallBack, the NEW one now uses Skyrim 3D Trees instead. Maybe S3DTrees' meshes are just that much higher in polycount, or at least it's LOD meshes are. I wasn't complaining about how long it took, just surprised by the Size I got (37.7gb final size) and wanted to ask if that is correct, because that is like a multiple of the whole original skyrim game (so the lods are already more detailed than the vanilla game? :O) EDIT: How can I see if a mod has a 3D Lod model or not? (So if the Fallback would revert to the full mesh?)
  8. So, I'm currently running DynDOLOD 2.36 with Dynamic lod and Hybrid/Full trees... It's been running at least for 2.5h on the tamriel worldspace, the main DynDOLOD executable gave up on waiting and LODGen is still going. The output is now 27.3gb large, and still growing... Is that normal or did I mess up some setting? The only change from my last DynDOLOD run (~6gb large) was the switch to dynamic lod and replacing Enhanced Vanilla Trees (Lush, Large) with Skyrim 3D Trees...
  9. Additional info (couldn't edit anymore): With the last crash (but also in the other cases) there was much more stuff that's not in unlceseano's log. --- Crash location here was: [00:15:14.257] Reading Large Reference Data for DLC1HunterHQWorld "Dayspring Canyon" [WRLD:02001DB8] [00:15:14.344] Update static LOD data for 144 large referencesBut after those lines, I always get the warnings for deleted references like this: [00:15:14.371] Deleted references were found. [00:15:14.371] [00:15:14.371] Below is a list the plugin names and the references: [00:15:14.371] [00:15:14.371] Update.esm [REFR:0010FB55] (places FXRapids02 [MSTT:00106A1D] in GRUP Cell Temporary Children of [CELL:0000BCB9] (in Tamriel "Skyrim" [WRLD:0000003C] at 32,-23)) [...]and then [00:15:14.383] References with z height = 0.0 were ignored by DynDOLOD. [...]and then [00:15:41.031] Missing models were ignored by DynDOLOD. [00:15:41.031] [00:15:41.031] References using base records with missing models can cause CTD. [00:15:41.031] Below is a list of base records with missing models which are used by references: [...]which is Bruma's missing models only. Only after that comes the section [00:15:41.032] Checking for esp overwriting large references causing LOD flicker [00:15:41.032] Reading Large Reference Data for Tamriel "Skyrim" [WRLD:0000003C] [...]which is followed by the thousands of large references. Yes, I know I have to clean my DLC masters (they are the most of the deleted references).
  10. Yes, I am. But why did my lodgen with the EXACT same load order and the new executable work then? I guess I'll have to do some testing with the old executable again later, but each run of dyndolod takes about 20 minutes for me (on a i7 6700k, mostly at 100% cpu load - props to a well multithreaded software here!). Also - could you give me a source for the problems with Royal Armoury? I'd like to read about them a bit, because my game keeps crashing as soon as my char gets up from the chopping block and I don't think it's script based as only some thieves guild and dark brotherhood quest scripts are overwritten. (Yes I know, this is the wromg place for this, I'll stop now.) I will report back with my findings later after running dyndolod some more times and potentially replicating the crash. Edit from other PC after checking my backupped logs from the beginning: The first crash happened with the last worldspace being [00:05:25.010] Reading Large Reference Data for arnimaDUPLICATE003 "The Reach" [WRLD:09000D62] [00:05:25.024] Update static LOD data for 0 large references The 2nd time it was with [00:01:57.663] Reading Large Reference Data for Tamriel "Skyrim" [WRLD:0000003C] [00:02:05.771] Update static LOD data for 34801 large references --- Insert 2nd Edit --- found one more crash that wasn't deleted from the current log (the run before the successful one was still in the log) Crash location here was: [00:15:14.257] Reading Large Reference Data for DLC1HunterHQWorld "Dayspring Canyon" [WRLD:02001DB8] [00:15:14.344] Update static LOD data for 144 large references --- End insert edit--- I sadly forgot to back up the logs of the following cases of the crash. But if I can reproduce it again, I'll post where it happens then.
  11. It's not that specific worldspace. I had the error happen 3 or 4 times. Always with different worldspaces (last one was dayspring canyon from dawnguard I think), and the last line was always that Gray Cowl thing. But still, I for myself only have this happening when generating the 3d trees. Oh, and this is line 305: fExport := LODGenExportWorldspaceEnd(LODGenWorld, sWorld, sExport, fExport, slExport, slExportAltTextures, slCache, olEDIDFormID, olXCLCCache); that function LODGenExport... is declared in the obsolete script it seems (which is not imported anymore). At least that's the only other file Ultrasearch found it in. €dit: This time it seems to work alright. Tamriel worldspace finished just a few seconds beofre the log check and Dyndolod waits for Lodgen64 to finishe falskaar.
  12. I have no idea. I'm also still stuck with the error, and my post above is only a suspicion. My point is that running Dyndolod without 3d trees and the same load order works just fine. The lines are also in the log, but no crash appears then. The NEXT thing that happens is a check for the Lodgen logs (at least that's what's the dyndolod log says). And that log can't be checked in my crash case since the file is still empty because lodgen is not finished with the tamriel worldspace yet. Basically, my suspicion is that Dyndolod is TOO FAST in comparison to Lodgen.
  13. I think this actually is a veri niche crash with a very funny background. I obviously have it too, that's why I'm replying. At first I thought that Gray Cowl was the problem since it's the last thing shown in the log. But when I ran Dyndolod WITHOUT Hybrid Trees, everything worked. Comparing the logs, I could see why: The next step that is done after the Reading Large Reference Data for mannyGFDesert "Alik'r Desert" [WRLD:08200000] line is that Dyndolod checks the log files of Lodgen to see if everything worked alright. BUT - when running Dyndolod with hybrid trees, the Tamriel worldspace takes so long that lodgen is not finished for it when dyndolod wants to check its log. The log is still empty then, which I suspect to be the cause of the crash. Lodgen is still running fine at that point, and waiting a few more minutes it finishes without errors, but sadly after Dyndolod tried to check its log. This error occured on multiple tries, always at the same point in Dyndolod, and Lodgen was always still running for the tamriel worldspace. Thanks for checking this! Extra info: using Dyndolod v2.32 for SSE and tons of high resolution mods, massive worldspace mods like Bruma, and Beyond Reach, etc.
  • Create New...

Important Information

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