Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    10,775

  • Joined

  • Last visited

Everything posted by z929669

  1. z929669
    Finally got a bug report with these added debug settings. Note that I cancelled this process myself by gracefully aborting DynDOLOD when I noticed I had not killed all AMD Adrenaline processes beforehand, which makes TexGen/DynDOLOD take forever when active. Perhaps we'll get some insights as to what in the hell AMD software is doing to add this unnecessary overhead. I personally think it's some sort of AMD texture-mediation algorithm due to Adrenaline not understanding that DynDOLOD is not a game.
  2. z929669
    That was it. file out of sync, due to multiple generations combined here manually. The trees of Veydogolt just have too many triangles on average and the LODs need to be decimated a BTO of 0.5 Gb is an order of magnitude bigger than it should be. Some of these hybrids have crowns with 40,000 triangles, so they need to be decimated. Thanks
  3. z929669
    On game launch with the the output generated by this run (logs above), I am getting an in-game message "can not find master in DynDOLOD_None" ... I searched your doc and didn't find anything on this issue. DynDOLOD is 'inactive', so I assume dynamic LOD won't work, but I have static LOD. Testing on a new game.
  4. z929669
    Could this be useful for grass LOD compatibility as well? Specifically thinking of ENB complex grass LOD compatibility.
  5. z929669
    I don't run Open Cities, so I don't know offhand. The DynDOLOD documentation has details on how to generate for OC.
  6. z929669
    TrueDirectionalMovement was my next contender. I'm pretty sure you will just need to patch them (or fix the offender)
  7. z929669
    Yeah, I'm working with him on that ... too many irons!
  8. z929669
    Looks like a mesh issue in Better Third Person Selection. Disable that mod to confirm. Then you will need to report it to the MA.
  9. z929669
    Added those params to the INI, and of course, I got no errors this time for the first time after like 10 attempts. It took 6.5 hours for LODGen to finish so DynDOLOD could create the plugins, and the output is massive (39+ Gb). I attribute this to the diversity and complexity of the Veydogolt Trees and corresponding LODs. This will be address but is beside the point Here's the logs, but probably don't reveal much: Logs Now I will work on invoking the issue by reattempting. The failure happens early on in the process when it does happen, so I will abort and keep trying until I get a useful bugreport. EDIT: To verify my config and environment, I had already tested on my mod list without any of the Veydogolt stuff using the most recent Alpha and non-NG DLL, and it ran just fine in about 15-20 minutes. So the problem runs are due to Veydogolt. Note that there are several normals named in non-standard fashion like *_4n.dds ... DynDOLOD issues these warnings, but I'm pretty sure they are benign, but IDK. EDIT2: I'm unable to reproduce the bug report. I have had three non-errors (just aborted once LODGen process began, as the error happens in initial creation of Tamriel *_glow.dds. I've had a couple of ungraceful closing of DynDOLOD (the window just disappears without bugreport). I will keep those params in the INI though and report back when I get a bug report.
  10. z929669
    This mod is not in our guide, so it's not of interest in this topic
  11. z929669
    Where are you in the guide? Per the instructions, do a smoke test after 02-Extenders, but do not test the game until most other mods are installed per instructions. If you only have half the mod list installed, things will not work properly. If you follow along with the guide, all instructions are provided.
  12. z929669
    DynDOLOD created a bug report while processing but did not close or provide any additional messages. I was able to close the program gracefully after the but report was created: logs & bug report Context: Using Alpha 118 with standard DLL after a system overahul of bloatware and disabling XMP to avoid any stability issues caused by that. System hardware is not overcloked. Windows manages memory. System specs in sig. Nothing relevant in the Event Logs EDIT: This issue has been happening after many attempts in a similar manner on the mod list but without the bug report. I finally got the bug report after disabling XMP in BIOS and cleaning out Armory Crate and other bloatware. I suspect that one of these actions may have been disrupting creation of the bug report since forever. I'm currently testing if this is reproducible. EDIT2: Second attempt halted similarly, but no bug report. Logs
  13. z929669
    I'm currently running a difficult DynDOLOD run that takes hours, so I cannot provide it right now. ACMoS was created by a member of our team, so the screenshots on that Nexus page are using our SSE guide setup and show how it should look. This is why I keep mentioning the CL temp mod, because your screens of the map look exactly like they would if you ran object LOD with that mod active.
  14. z929669
    Whatever YouTube guide you are following is not giving you instructions for SSE apparently. You need to run DynDOLOD for SSE by using the command-line switch -sse in the Vortex DynDOLOD EXE controller or by renaming the DynDOLOD executable. This is all explained in the DynDOLOD doc and in our guides, but we use MO not Vortex.
  15. z929669
    %LOCALAPPDATA%\Skyrim Special Edition\Plugins.sseviewsettings This post explains what to do to prove that xLODGen produces LOD versions of the textures that are not darker/lighter than the source. If you map looks off, it's due to game INI settings or something related to ACMoS mesh rules or settings. Your response here doesn't mention the testing mod list. I understand the first image is vanilla, but the second is xLODGen with CL for all we know, since that's what you were testing with in your previous post. CL LOD textures will be different from vanilla. Also, the Step guide settings instruct xLODGen gamma to be 1.25, but in that post you said we instruct 1.0.
  16. z929669
    Then you have something else going on and either didn't follow the 2.2.0 guide exactly or have added other mods. Also, the snow and terrain of CL requires a slight boost to gamma (1.25), since it uses a custom approach for landscape (and why it requires the temp terrain mod for xLODGen). This is indicated in the 2.2.0 guide. If you aren't following the Step guide, you haven't said so yet. Use the standard vanilla or SRO noise map with CL. As sheson mentioned in his last post, xLODGen isn't the issue here.
  17. z929669
    It has noting to do with EVLaS and CG. They work together as expected. LOD just doesn't cast/receive shadows from full objects. It's a game limitation, and recent discussion on this topic concluded that the next Alpha will have back_light flag unset by default with possibly some other functionality to customize grass LOD for better tuning with CG grass.
  18. z929669
    I'll mention it again here: Be certain the Cathedral Landscapes Temp mod was deactivated before you ran TexGen/DynDOLOD. That piece of CL is only enabled when generating terrain LOD. If you didn't disable the CL terrain LOD add-on, then you r map will have greenish snow with ACMoS. If you left it enabled, you will need to rerun TexGen/DynDOLOD after disabling it.
  19. z929669
    As I have already mentioned on this topic and another now:
  20. z929669
    BDS material shaders are responsible for difference in color of snow on objects versus landscape. You never mentioned on the other topic if you had forgotten to disable Cathedral Landscapes Temp mod before TexGen/DynDOLOD. This will make th map snow greenish yellow if not disabled prior to TexGen/DynDOLOD. If you are following the 2.2.0 guide exactly, your snow will match. Otherwise, this is the wrong forum for posting this issue.
  21. z929669
    In LODGen_SSE_<worldspace>_log.txt, I see: Output: C:\Modding\Tools\DynDOLOD\DynDOLOD_Output\Meshes\Terrain\Tamriel\Objects\ Using UV Atlas: C:\Modding\Tools\DynDOLOD\Edit Scripts\Export\LODGen_SSE_ObjectAtlasMap_Tamriel.txt Using Flat Textures: C:\Modding\Tools\DynDOLOD\Edit Scripts\Export\LODGen_SSE_FlatTextures.txt Using Alt Textures: C:\Modding\Tools\DynDOLOD\Edit Scripts\Export\LODGen_SSE_AltTextures_Tamriel.txt Generating object LOD meshes for worldspace Tamriel Reading C:\Modding\Tools\DynDOLOD\Edit Scripts\Export\LODGen_SSE_Terrain_Tamriel.bin Threads: 32 Concs: 8 Isn't the last line supposed to read "Cores" rather than "Concs"? I'm doing some experiments with LODGenThreadSplit settings and this threw me off a bit.
  22. z929669
    I use this one: https://www.nexusmods.com/skyrimspecialedition/mods/5682 It should work with any gamepad.
  23. z929669
    Be certaion the Cathedral Landscapes Temp mod was deactivated before you ran TexGen/DynDOLOD. That piece of CL is only enabled when generating terrain LOD. If you left it enabled, you will need to rerun TexGen/DynDOLOD after disabling it.
  24. z929669
    Be certain the Cathedral Landscapes Temp mod is disabled after generating terrain LOD. Also be sure you are running only mods in the 2.2.0 guide and nothing additional until you confirm everything is looking right. Also see advice in previous responses ^
  25. z929669
    LODGen failed after quite a long time testing a new land/grass setup with Veydogolt Overhaul, Veydogolt Trees, and Veydogolt Trees - Extra Trees after cleaning out all of the redundant NIFs (found by deduction using combinations of the DynDOLOD xEdit scripts) and re-making all of the LODs correctly. Only DynDOLOD.esm was saved. No bugreport.txt generated. Error: LODGenx64Win.exe failed to generate object LOD for DLC2SolstheimWorld. LODGenx64Win.exe returned C0000005. Check C:\Modding\Tools\DynDOLOD\Logs\LODGen_SSE_DLC2SolstheimWorld_log.txt Error: LODGenx64Win.exe failed to generate object LOD for one or more worlds. Check for error messages in the listed LODGen log(s) Logs suspect plugins This mod has lots of grasses. I have 64 Gb RAM, and memory use never went above 60%, but CPU maxed at times for LODGenx64. By the way, the fixed Veydogolt tree you posted earlier I think is mislabeled as treepineforest03, but I have this one as treepineforest04_F7CE5204passthru_lod.nif and have verified against the full source that is referenced by skyrim.esm. Veydogolt Trees has no plugin and is supposed to only be providing models for vanilla with custom textures. A variant of treepineforest04 also exists in the tree mod under a subfolder with corresponding treepineforest04_02B81171passthru_lod.nif. I have fixed this by placing that subfolder under the appropriate mod, Veydogolt Trees - Extra Trees, whose plugin references this tree. Anyway, my issue is related to LODGen and not in-game CTD. I don't think the LODGen fail is related to trees after applying my fixes, but there are three full models with radius 0.00 that I did not fix, so not sure if that would disrupt. I'm thinking it's related to all the grass records in Veydogolt.esp. My next step is to generate by worldspace and possibly run occlusion separately. System specs are in my sig. EDIT: After attempting a run on only DLC2SolsteimWorld, LODGen_SSE_DLC2SolstheimWorld_log.txt failed at different coordinates than in the first run, so it's not any particular BTO, I assume. LODGen_SSE_DLC2SolstheimWorld_log.txt
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.

  I accept