KRZ
-
Posts
29 -
Joined
-
Last visited
Everything posted by KRZ
-
Apologies, then I must have misunderstood something. I've been using ComplexGrassBillboard=5, so it is no surprise that it happens. I just fail to understand what gets modified. DynDOLOD_SSE.ini states a 4x4 pixel grayscale texture is generated for values other than 0 or 100. But where is stored? Cause that makes it sound like it could be part of the Atlas texture. But changes I made weren't reflected when 'Rebuilding Atlas'. From your explanations I now understand such data can also be stored in the mesh. Am I correct to assume grass object LOD billboard NIFs (what a word, holy hell) of type alt2 just dim a white.dds depending on the ComplexGrassBacklightMask value chosen and I should be 'Executing LODGen' instead for an quick and easy update? In case anyone ever comes across this searching for the same answer, the texture is textures\DynDOLOD\maps\gray_*.dds. * is equal to whatever has been set in DynDOLOD_SSE.ini for ComplexGrassBacklightMask/GrassBacklightMask and probably works similiarly for GrassGlowMap/ComplexGrassGlowMap. Example: ComplexGrassBacklightMask=25 -> textures\DynDOLOD\maps\gray_25.dds The texture can be edited (don't rename) and doesn't require re-running DynDOLOD. In case a suitable value has been found, update the value in DynDOLOD_SSE.ini for future runs.
-
Guess I got it backwards somehow, thank you for clarifying! That makes it slightly more confusing. If I got that right, it's supposed to be a regular texture that does or doesn't come with grass mods? I've just checked some of the meshes used in the grass mod and it doesn't seem to have a backlight/glowmap texture nor flag set. Yet I'm still seeing an effect applied when changing backlightmask values, did I misunderstand something? It's gotta be scaling something, when the grass seems to changing when using backlightmask (even though no texture seems to be set).
-
Hey sheson, I have been wondering whether it'd be possible for the Preview feature in TexGen to make use of certain configurations set in DynDOLOD_SSE.ini (BacklightMask, GrassBrightness*, etc). I get they're two different tools but figured it'd be of great assistance if Direct/Ambient Light changes would already resemble what would be shown in the game. Am I mistaken? Also I checked the Updating Grass LOD section on dyndolod.info and couldn't find a word on how to update the BacklightMask, is it simply part of the Atlas texture? Thank you for your response!
-
Had a feeling it'd be a performance issue but had hoped not. Also been wondering whether it'd be possible to gather all grass data (location, color), create an overlay texture + unique noise and slap that on top of terrain LOD to fake grass fields. But that's pretty much exactly exactly what you suggested should be done via baking. Sounds like mixing landscape textures and grass mods is a lot more disencouraged or trouble to get right for visual consistency than I thought. But that answers my question. Thank you for the insightful answer, sheson!
-
Hey sheson, got a question that's been on my mind for a while now, perhaps you can give me some insight please. In regards to grass LOD, specifically Grass Mode 1. Why is there no option to have userdefined further reduced grass LOD amount displayed in LOD8? I took a picture from High Hrothgar towards the tundra and drew in the lines where grass (Grass Mode 1; 65%) just stops displaying: https://i.imgur.com/TK2c8GQ.jpeg If I wanted grass beyond that I could increase LOD4 draw distance or switch to Grass Mode 2, right? GM2 uses the during the LOD generation set value [0;100] though (I believe?), while increasing LOD4 would otherwise increase load due to it's better quality level compared to >LOD4. To get back to the question, why can we not set a second value for LOD8? Potentially LOD4 % * (x/100) with x being [0;100]? Perhaps just [0;50] or even less? I feel like having just 10% grass in LOD8 would still be better than 0%. Or are there other means to achieve this? Thank you for your reply or if I missed an important bit of information, thank you for your guidance!
-
Sorry I missed the test version and only now respond to 171 It's looking good however. I've attached the xEdit Error Check below but there are no unresolved FormIDs and I've had no crashes either. I think this could be it. Thank you for continously troubleshooting and also for the easy to understand explanation of what's been wrong!! Error Check 171.txt
-
This one's looking good in xEdit. Unknown 2 only. No crashes in game either. I've attached DynDOLOD logs, just in case. DynDOLOD_SSE_Debug: https://mega.nz/file/1OVi3ATa#WQN_Iquyedx69e_4LHhKnCn8BMfQCy4DbkwtNf9cHfw I'll start another run with Sirenroot and SLaWF and share the results once I got them. Great success. Unknown 2 only. DynDOLOD_SSE_Debug: https://mega.nz/file/0GdmWY6B#PuPZGFUWPAUm1a1rM7S0YbUGebjXv7GjKfrk2mmc_TU This one's with Sirenroot + SLaWF. The text-files containing 'Complete' in their title are including Sirenroot + SLaWF. May I ask how the mismatch came to happen? It sounds like something more people should encounter so I'm still sceptical I messed up somewhere. Thank you for all the troubleshooting help! Error Check 170C.txt DynDOLOD_SSE_log.txt Error Check 170C Complete.txt DynDOLOD_SSE_log Complete.txt DynDOLOD.esm Complete.zip
-
Sadly no success. The FormIDs have changed, but xEdit still reports errors. 08 is USSEP. Fwiw, the crashes in Whiterun and Riften are gone. I'm assuming that with the unintended errors in xEdit the crashes only have changed location though. maybe. Just to throw in more ideas what could be causing it: I'm using best of both worlds downgrade to 1.5.97 from 1.6.640, perhaps that's causing a missmatch? Latest available downgrade is from 1.6.1130. Also I'm relying on BEES https://www.nexusmods.com/skyrimspecialedition/mods/106441. And I haven't created new Terrain LOD for the non Sirenroot/SLaWF LO. If that needs updating as well, my bad, I didn't know, please tell. DynDOLOD_SSE_Debug: https://mega.nz/file/4OchDY6S#8eaQcckzsctwFHnhWFHPlCm8NvMY86uFFVX9SAzSlFU Logs 171.zip DynDOLOD.esm
-
To keep it short, there's no errors besides the Unknown: 2, which are expected. For sake of completion I've included it regardless. DynDOLOD_SSE_Debug: https://mega.nz/file/gX1RXL6C#uZKEtw9HJCBm72IbmBkq5LNln1E1j6PDS5Hb675C5EE Edit: It's probably a reach, but I wanna try it anyways: I've deleted a ton of entries from Fabled Forests cause I only wanted the additional tree placement, but never actually cleaned the plugin. I just did and it removed 2000 something identical to master records. I'll try another Alpha 170 and see what's going to happen. Nevermind, nothing's changed Logs Alpha 169 (new 2).zip DynDOLOD.esm
-
I'll get back to you once 169 output is generated DynDOLOD.esm
-
Once again everything's brand new, including TerrainLOD this time, but the crashes persist. DynDOLOD_SSE_Debug: https://mega.nz/file/FDlAwDTa#pI9vxOzqgJoBPAB8x5lMWILKdnqLzjxsXwmVdZ6QzQU Fwiw, I've noticed there are a ton of 0D and FE005 FormIDs in xEdit's error report, which are evgSirenroot.esm https://www.nexusmods.com/skyrimspecialedition/mods/70917 and Landscape and Water Fixes.esp https://www.nexusmods.com/skyrimspecialedition/mods/26138 in my LO. I wonder whether that's related somehow. Peculiar, I've done another Alpha 170 output without Sirenroot and Landscape and Water Fixes, but while all the 0D errors are gone, the FE005 have changed. Everything related to this is in Logs 2 & DynDOLOD_SSE_Debug 2. DynDOLOD_SSE_Debug 2: https://mega.nz/file/9XsBEADa#mMWBomfMs2suBL9rzJLxHOQwFrVpbDRO3ifMmHFhaBs Logs.zip Logs 2.zip
-
I'm getting a couple of errors with both Alpha 169 and Alpha 170, but it's hard to tell whether that isn't caused by me replacing that one patch and adding 3 more patches which had been chosen by the FOMOD. Should I create a new Output for Alpha 169 as well to maintain consistency or does it not matter? I had to replace the patch or xEdit would have thrown a fit and I couldn't check for errors etc. I've attached the findings anyways, but if I have to do another round let me know. Launching without the mod/model did nothing. Nothing touches the original reference 00099F21. Error check.txt
-
Sorry for taking so long, xEdit reported a patch causing errors, so I replaced it and ran Alpha 170 again to see whether that's been the culprit - it was not. I've included a comparison shot of both entries below (Alpha 169 on the left, Alpha 170 on the right). I can't really spot a difference, however it appears that in Alpha 170's output skyrimesm_099F21_WhiterunWorld_DynDOLOD_PARENT_DynDOLOD_NOLO doesn't actually get referenced by anything opposed to Alpha 169's output, which has exactly one reference. The WRHouseStables01.nif is from this mod https://www.nexusmods.com/skyrimspecialedition/mods/120159
-
Welp, you were right that my LO had changed - I've been wondering about that cause the RAM address was different in those crash logs. Below I've attached all logs from a new A170 run with identical LO this time (also identical to A169). Sadly the crashes persisted. I've also tested whether crashes would occur in Markarth, Windhelm or Solitude as well and they didn't (or I just haven't found the spot). DynDOLOD_SSE_Debug: https://mega.nz/file/IGtykIzI#j9kKzjggkK3vStV3a9oIAQIjyyzQurM66J_OjvCuM0M Logs.zip
-
Hey sheson, I'm crashing in cities (only Riften and Whiterun tested) with DynDOLOD A-170 generated output. I've tried disabling the DynDOLOD Output which got rid of the issue and I rolled back to A-169, generated a new output and had no issue. Crash Logs are included in Logs.zip, DynDOLOD_SSE_Debug (https://mega.nz/file/UacwCRLb#BzV3vb1x-dauLDoHt4rHjQOrNXzYHn8fS2_bk4s-4To) as always had been to large. Could you have a look? Thanks! Logs.zip
-
God damnit, you're right. I've removed everything related to DynDOLOD and the issue persisted, even when using default INI settings. What a pain in the a**. I'm terribly sorry for the false report. Thanks for putting up with me and have a nice day! o/
-
Hey sheson, I'm encountering an occlusion(?) issue on the world map. My best guess would be that distant cells somehow get occluded behind mountains that only cover them partially. At least that's what it looks like. I know videos are disliked, but just in case the explanation is lacking. Length is 11 seconds: https://streamable.com/vr87dn Skyrim.ini settings: [MapMenu] bWorldMapNoSkyDepthBlur=0 fMapWorldMaxPitch=90 fMapWorldMinPitch=0 fMapWorldYawRange=400 fWorldMapDepthBlurScale=0.3000000119 fWorldMapMaximumDepthBlur=0.4499999881 fWorldMapNearDepthBlurScale=4 uLockedObjectMapLOD=8 uLockedObjectTerrainLOD=8 Logs attached below, DynDOLOD_SSE_Debug_log here cause too large Thank you for assistance or if you can point me in the right direction cause I use bad settings, that would be equally as much appreciated! LOGS.zip
-
Cool, then I thank you for the quick fix and the explanation!
-
Looking good! I'll run around some more to see whether I find anything but the trees I've sent before are definitely fixed. Visual Confirmation: https://imgur.com/a/RWnYC8Y It's the same pictures as before, but I've added "LOD Fixed" showing the same trees with the updated atlas. Additionally I have not found any issues after looking at a few locations, so I think this has been resolved. May I know what had went wrong or if it'll be part of the changelog that'll be sufficient as well
-
https://mega.nz/file/cCtQWIiI#Uatk9W48xJ4j2LwIoFBRQHKeK_3bJJiwtB10VKTvzi4 Debug Log is 160mb? Additional Info, if that is of relevance. I always copy paste my TexGen_SSE.ini, TexGen.ini, DynDOLOD_SSE.ini and DynDOLOD.ini (and my presets) from the previous version to avoid having to set up some stuff again. Could that be the culprit?
-
https://imgur.com/a/RWnYC8Y https://modwat.ch/u/KRZ I hope I didn't forget anything LODGen_SSE_Tamriel_log.zip
-
I've rerun DynDOLOD for the last couple days and noticed that my 3D tree lods are pretty much devoid of most color, or that's at least what it looks like from afar. Close up the color seems to be still there, there's just lots of white/grey layered over it and I'm puzzled as to where I could have messed up or where that even came from. I feel like I would have noticed this a lot sooner so the issue must be fairly recent but I have nothing of substance to say with certainty. I've checked the lod meshes in MO2, but the colors appear to be fine there. I wanna say it is only the treepineforest01,... treepineforest05 models that are affected, but I don't know really - it's harder to tell on a snowy tree model and what are the chances it's limited to just a region. Is specularity getting turnt into a solid color? I can only speculate (: I have attached TexGen_SSE/_Debug.log as well as LODGen_SSE_Tamriel.log. Here (https://imgur.com/a/k9AYU2X) you can see two pictures of the issue and here (https://imgsli.com/MjI0Njk4) a comparison to a picture from 5 days ago. Take the imgsli with a grain of salt as the time of day in the old picture doesn't adhere to the requested standards, however (I believe) it is still fairly obvious the tree lods weren't nearly as grey as they are now. LODGen_SSE_Tamriel_log.zip
-
Then I'll do that, thank you very much for resolving this!
-
Took a look at 20 previews and they all seem fine now. Thank you!
-
They look fine to me
