Jump to content

z929669

Administrator
 View Profile  See their activity

  • Posts

    13,028

  • Joined

  • Last visited

 Content Type 

Everything posted by z929669

  1. 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
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. z929669
    As I have already mentioned on this topic and another now:
  9. 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.
  10. 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.
  11. z929669
    I use this one: https://www.nexusmods.com/skyrimspecialedition/mods/5682 It should work with any gamepad.
  12. 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.
  13. 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 ^
  14. 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
  15. z929669
    FYI: I have confirmed that using "End Task" to force-kill AMD Adrenaline and other related AMD processes on my system resolves the long-running TexGen process. Tested with same LO, and my 35 minute TexGen run was reduced to about 4 minutes as expected. I haven't tested with DynDOLOD runtime yet. Running latest Adrenaline drivers and Alpha 118
  16. z929669
    I don't thing EVLaS is really the culprit but rather reveals the problem (as sheson inferred in the last statement of his previous post). EVLaS gives us shadows from distant (non-LOD version) objects, and the reason the foreground is so dark in my last screen in previous post is due to EVLas allowing that big distant mountain to occlude 'sunlight' point source. This is how we want it, but the problem is that LOD is agnostic of EVLaS shadow effects and only responds to the light source (ambient/direct) without 'seeing' shadows cast via EVLaS mechanism (this is me guessing not a statement of facts). The mountain shadow did creep along the ground as the sun dipped, but it was only apparent on the loaded grass. I took the shot after the shadow reached me to illustrate the LOD/loaded difference. So the sun did light up the CG loaded grass as in the first image, but it became darker when occluded by the mountain shadow (thanks to EVLaS) and not as bright as if the sun were behind me. The effect of light on CG should be that when the sun is behind the PC, it lights up the side of the grass facing the PC, and when the sun is opposite the PC, the grass facing the PC is more shaded (depending on SubSurfaceScattering settings). The strength and behavior of this effect depends on the quality of the normal/specular of the CG grass and grey value of the flag area in the normal (this is why the CG grass I created for Cathedral Landscapes has different lighting than the one created by the Compendium CG mod). This effect only pertains to loaded grass though and not LOD grass, which lights up like other non CG objects. LOD also does not get shadows, so LOD grass will never react to light/shadow like loaded CG grass, but I think with the proposed changes to the next Alpha, we may see better approximation, given the game limitations.
  17. z929669
    I know that ENB-CG settings themselves can exacerbate issues. Some presets have the CG settings optimized, and some do not. Some of the CG settings only apply to 'basic' (non-CG grass) and others only impact CG grass. LOD grass obviously cannot be impacted by this, so we've found that keeping the settings moderate is best for LOD compatibility. Also, if certain grasses are not using a CG-compatible atlas, they will be overly bright in full grass. As I understand, you are saying that it's the LOD grass than can be very bright at certain ToD with respect to loaded grass. I can corroborate that this is indeed true with Step SSE as well, and it sounds like the Back_Lighting flag may be part of the issue. We use Cathedral Landscapes Complex Grass for ENB and our own custom ENB preset (Heavy version), which is drastically simpler than many presets. ENB for SSE 0.488. If I find the time, I can test with these two mods over vanilla and see if I can't mitigate with the flag setting. I'm swamped with work, RL, and multiple projects right now, so no promises. For now, this is the effect with all settings optimized for CG-LOD compatibility: While the sun is overhead or even still peeking over the mountain and lighting up both foreground and background, things look as expected: ... but as it dips behind the mountain, one expects the shadow to creep from the mountain to the player, which indeed it does, but it doesn't impact LOD grass much at all, only the loaded grass: The LOD grass will stay lit up until most of the ambient sunlight is gone. This is also true of other LOD objects, but it's not as pronounced/obvious (e.g., distant mountains, trees, and objects are a bit brighter than those in the loaded foreground but its pretty acceptable, IMO ... I think the loaded area is pretty obvious from the second screen). EDIT: the so-called 'optimized' settings for our CG-LOD config are partly TexGen Direct/Ambient as indicated here, DynDOLOD grass T/B brightness all at 0.500, and ENB-CG settings moderate (with EFFECTs UseOriginalBloom=true UseOriginalPostProcessing=true). We are using Cathedral Weathers in those shots with Ambiance. This must partly be a game limitation, but I'm intrigued if the grass LOD flag can mitigate without messing things up in full daylight or when the sun is behind the PC.
  18. z929669
    Don't unpack the BSA. It doesn't make anything 'easier' for DynDOLOD. If you aren't running the CC content, there could be some minor grass placement issues.
  19. z929669
    Tech will be looking at SS in relation to SLaWF in the coming days I think, so creating the bug report on SS would be good, since it will be a reminder to validate your findings against both SLaWF and LFfGM. EDIT: actually, Tech created a Big Report on SS as a reminder, so you could add your findings as a comment to that.
  20. z929669
    I saw that, and now, of course, I get it
  21. z929669
    @TechAngel85 The latest SLaWF update patches some things that overlap with the Smooth Shores patches. Example: Tundra Homestead patching now included with SLaWF. We may or may not want to use that new feature from this mod, given that SS is also doing it. I just want to coordinate our approach.
  22. z929669
    A "Bug Report" on the SLaWF page? I'm not following. There's no bug, per se, just redundancies that SS patches should take into account ... maybe in coordination with WizKid, but IDK.
  23. z929669
    Just install the Main File. Mod page instructions removed.
  24. z929669
    Thanks. This is fixed.
  25. z929669
    I've also seen one-time issues with a particular savegame with Dragon Bridge and related characters, so testing on a new game could magically resolve the issue. Otherwise, there is a plugin conflict or missing dependency of some kind, I would guess.
×
×
  • Create New...

Important Information

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

  I accept