Jump to content

Blackread

Citizen
  • Content Count

    59
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Blackread

  • Rank
    Thane

Contact Methods

  • Discord
    Blackread#0954
  • Nexus Mods
    Blackread

Profile Information

  • Preferred Pronoun
    He/Him/His/Himself
  • Favorite Mod(s)
    Project ja-Kha'jay by allonsywisegirl
  • Diamond in the Rough
    Typography for Skyrim https://www.nexusmods.com/skyrimspecialedition/mods/34182 Can't overstate the importance of good fonts in the game.

    Kabu's Argonian Fins https://www.nexusmods.com/skyrimspecialedition/mods/65428 Stuff for beast races always flies under the radar.

    RedBag's Rorikstead https://www.nexusmods.com/skyrimspecialedition/mods/56114 A criminally underrated mod, as are the rest of RedBag's overhauls.

    Free Housecarls https://www.nexusmods.com/skyrimspecialedition/mods/27571

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Of course, that is a perfectly valid workaround, why didn't I think of it before Thank you, the test build fixed the Item not found bug.
  2. Debug log reported that only one thread was used. I was inspecting the latest run I did with Process Explorer to get a better grasp of what is going on, and as soon as DynDOLOD started updating the height map the number of Private Bytes spiked up sharply, staying above 20 GB for the majority of the time and peaking at 28 GB. Process Explorer also reported over a dozen active threads for DynDOLOD during that and the number of active threads correlated pretty well with the memory usage, so I was wondering if it's possible, that Windows or something else circumvents the thread limit somehow? Although I'm not sure how reliable Process Explorer actually is for these things. Do I need to have an Occlusion.esp already in my LO when doing the occlusion? I tried first generating LODs with Occlusion unticked, and then running again with only Occlusion data and Plugin ticked, but when I hit ok to start the process DynDOLOD asked me whether I want to update my plugins, and a few seconds after hitting Yes I got an Item not found error.
  3. Yes, it fixed it indeed, thank you. Looks like the one run that was successful without Out of memory errors was a random occurrence, haven't been able to repeat it since. It seems that HD Grass was the last straw. I was able to generate occlusion without 3D trees, without a grass LOD, or with 3D trees and a grass LOD using regular grass, but using 3D trees and an HD grass LOD tips it over the edge. Maybe I just need to get more RAM. I tried generating Occlusion with xLODGen afterwards, but that failed too. I couldn't figure out how to do it with DynDOLOD. The mentioned BTO files open in Nifskope without problems, although some of them take several seconds to load. Not all though, some open near instantly. It's the ones with a lot of grass that take the longest. The sizes of the reported files range from 4.95 MB to 59.39 MB, with most of them falling in the 10-30 MB territory. There are larger bto files in there though, the largest being around 80 MB. Generating just Tamriel with 3D trees and HD grass with 20 density takes around 40 minutes.
  4. Updating to Alpha 100 seems to have solved the memory issues, at least I didn't get any Out of memory errors during my latest run. 03010F54 is overwritten by Lux Orbis - Master plugin.esm only, it changes the emittance in addition to adding the location value. 03016DF1 is overwritten by Lux.esp, it adds an emittance value and a location value. The form IDs of the LOD reference are 380A258F (base, DynDOLOD.esm) and 6E67B45B (ref, DynDOLOD.esp), assuming this is what you meant https://i.imgur.com/E3EWJyH.png DynDOLOD_Tamriel_Objects.txt from the output Logs in case they are needed
  5. Thank you for the LOD Level explanation, I understand it better now. I tried to solve the out of memory issue by setting the OcclusionMaxThreadsObjectLOD to 1, but it didn't help. This time there was an access violation. I forgot to copy the error window, but here are the logs along with the bugreport. I looked into other possible solutions too, but the grass LOD is already quite low density, and the 3D trees are from Happy Little Trees which should be adequately optimized I believe. When it comes to other full models in object LOD I'm not entirely sure, the only mod I definitely know to use full models is More Wooden Bridges. I feel like something has maybe changed in the way the height data is calculated from object LOD, because back in the beginning of August I successfully generated a grass LOD with 100 density (with the same grass mod and settings). It took at least 15 minutes for the height data for Tamriel to be calculated and maybe 1.5 hours for the whole generation (Tamriel only), but there were no errors. The HearthFires building should not be there, I was straight out of the alternate start room. I ran from Honningbrew Meadery along the east side of Whiterun to the whitewatch tower, where I first noticed the misplaced building. It is fully replicable on that LOD generation (I haven't successfully completed another one yet). I hadn't altered my speed mult, it was vanilla (or very close to it at least). Edit: Forgot to mention, nothing in Papyrus logs. Edit2: Did another DynDOLOD run without Occlusion just to see if the HearthFires building is still there, and it looks like it is. Logs Seems it is replicable at least on this mod list. Still nothing in Papyrus logs. I'll root out the memory issues when I have the time.
  6. While I was running around the Whiterun area doing some testing I came across this: Looks like it's a part of the Pale Hearthfire house. It stayed visible in the large ref grid but disappeared when the cell loaded in. Here are the logs: https://mega.nz/file/xX0TBJAQ#-L1jMJHERaUd7bimCeaqP5xQ1y6TyXxoGf50SVlLUoA I noticed there were some Out of memory errors, maybe they are related. I also had some trouble with my LOD 4 distance. It seems that there is some lower limit under which it won't go no matter what I set in the ini. Using the sliders in the DynDOLOD MCM I estimated the distance the LOD 4 is displayed at to be somewhere around 40 000 units. Increasing the distance above that will extend the LOD 4, but dropping it below 40k has no effect. Is there some other setting I also need to adjust to drop it further, or is it somehow tied to near / far grid or the large ref grid size?
  7. Yeah, MaxStdio is set to 8192. Unfortunately it looks like after packing the Missives mod to an archive and unpacking it I am no longer able to reproduce this issue. Maybe it was some random fluke or some obscure yet undiscovered bug. I'll update this if it returns and I'm able to perform more testing. Edit: Here's a quick video of the same LODs now: https://www.youtube.com/watch?v=4DGjMtBSnvs
  8. Thank you for the tips. It is indeed a case of z-fighting between object LOD and object LOD. The youtube compression ruins the image so it's not so clear, but here's another video that should display it better: https://www.youtube.com/watch?v=piHXL1DE9CM I also found a solution: remove ini files from the data folder for an amount that adds up to at least 8 lines of text. Commenting out lines of settings with a semicolon (;) works too. It doesn't matter what settings they are or which mod they are from, or whether the settings are overridden by another ini file from a later loading plugin. As long as at least 8 lines are removed the z-fighting is gone. It also looks like ini files intended to be read by various SKSE plugins (KID, SWAP, DISTR, LID, FLM, etc.) are included in this count. Removing any of these files that have at least 8 lines of text removes the z-fighting. The file I remove can also be in a subfolder. It doesn't even have to be an ini file at all, it can be a json file or a txt file such as a changelog, or a readme. Script source files (.psc) also work. Reseting my base inis to default also fixes the z-fighting. I would imagine this is because it effectively removes at least 8 lines of text from them, as the BethINI Tweaks add several new settings to the files. I also tried packing one of my mods that had loose script files into a bsa, and this too removed the z-fighting. Putting all of the above together seems to suggest that there is some sort of engine limitation on the number of lines there can be in loose files with text content in the data folder. Or something along those lines.
  9. With a few of my recent DynDOLOD generations I've had issues with flickering distant LOD. Here's a video with a couple clips that demonstrate the problem: https://www.youtube.com/watch?v=U9o7jh5UYUI I don't think this is a large reference issue, as the affected cells are way too far to be included in the uLargeRefLODGridSize range, which I have set to 11. Also it often affects trees, which can never be large references anyway. To my eyes it looks like two different LOD levels are fighting in the affected cells, rapidly switching between LOD4 and LOD8 or similar. The issue is quite sporadic. With each LOD generation the affected cells are different. Sometimes I don't find any affected cells at all. When I tried approaching the bugged cells some of the LOD in the cells failed to properly unload. All non-bugged cells always unload without a hitch. Here are some logs. Logs 1 should correspond to the first clip on the video, and Logs 2 to the second clip. What kind of troubleshooting steps would you recommend? Is there a chance this is related to the large ref workarounds? Should I try generating LODs without them active? I tried setting uLargeRefLODGridSize to 5 just in case, but it had no effect on this as expected. Edit: Checked Papyrus logs, no DynDOLOD related messages.
  10. https://mega.nz/file/oat2xDAL#3NTc17b6JZDCJd4V1huBohZTubFeAeFiTvMrK4_NAIg Here's a plugin with just that one large ref changed. I did a test having only that plugin active in addition to the base game files, and at least on my setup that was enough to trigger the bugs. But I haven't tested with the latest alpha 99 yet. Update: Tested with Alpha 99, no change. Here are the logs for that run.
  11. There is no Tamriel_Disciple_%38_2 in -38,2, only Tamriel_Worshipper_%38_2. Yes, I've done the standard fix for the moved reference in Update.esm: moved the original one back to its original position and disabled it, and created a new duplicate where the original was moved to by Update.esm. However, I've been meaning to remove all the plugins that fix moved large references and custom updates to stuff like lighting mods in favor of the new workarounds and see how things work out, just haven't found the time to do it yet. I'll let you know of the results when I do. Thanks for looking into the Rorikstead situation! Completely missed that there was another model on top of the large ref one.
  12. Just finished doing the tests. After converting the records to proper UDRs and generating the LOD there were no bugs, disabling the spire reference showed no LOD underneath. However, after generating large refs and LOD the bugs returned. I checked all the added large references in that cell but couldn't find any obvious causes of this. Here's the plugin if you want to look into it further. I'm personally satisfied with using the workarounds though as they seem to be working well, so if you have other things demanding your time there's no need to spend it on this, at least not on my account.
  13. I did a bit of further testing and found out, that disabling and enabling one of the affected objects in cell -38, 2 will unload the LOD for all of them. The same did not happen for the rock cliff near rorikstead. I had Papyrus logging enabled during this. I did not notice anything LOD related in the log, but then again I don't really know what I should be looking for. Here's the log: https://mega.nz/file/hK0ABS4R#Cbd0-QnDBGndefdG_p6iBfP0bhm_6bYvoIt8Lda4Urk
  14. Ah thanks for the explanation, I wasn't aware that references disabled via enable parent also trigger the bugs. I can test this too. In the meantime, seeing as this will probably be the way moving forward, I generated full LODs with the workarounds enabled and checked the cells reported having bugs in the logs - which was painful, I doubt I'll do this ever again. I found very few references that had both the full and LOD model appear at the same time. Here's the full rundown: Here are the logs for the generation: https://mega.nz/file/oK0EXKZA#-j__STXxB7dBA8srl5Z7XqSgfQE-gMe932k_kSWJILg I also included the custom RedBag's Rorikstead plugin and my modified version of the main plugin it was designed to be used with. If this interests you and there's anything you need let me know. Of course my load order isn't super massive and it is already prepared for large references using the old methods, so I'm probably not the ideal test subject.
  15. Using the workaround got rid of the issue. I found the workarounds guide a bit confusing though. It says that the advanced mode has a new checkbox Downgrade FarGrid references to NearGrid which is necessary without the workarounds, but it's available only when enabling the workarounds. Does that mean that if the workarounds are disabled the checkbox is always selected but hidden?
×
×
  • Create New...

Important Information

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