HunterZ
-
Posts
20 -
Joined
-
Last visited
Everything posted by HunterZ
-
Thanks. The weird thing is that I definitely saw and enabled that, but it still wasn't generating a separate textures BSA until I tried stuff like ticking the incompressible BSA option and creating a custom profile. Tried replicating with a fresh install of CAO with the base FO4 profile and it does the correct thing, so I have no idea why that was happening. TLDR: It's probably worth verifying that you actually get a textures BSA after archiving.
-
Uh, what? This is the thread for the STEP FO4 guide (not FNV), which specifically instructs people to use CAO to archive xLODGen object and terrain data so that it doesn't have to be installed as loose files. As indicated in my edit, the problem seems to be that the default CAO settings result in all of the data being packed into a "xyz - Main.ba2" archive, but apparently the game will only accept the data if it's instead split between that and an "xyz - Textures.ba2" archive. Not sure why the STEP guide recommends CAO if it's not the best tool for the job.
-
When I archive xLODGen object & terrain outputs into ba2+esp packages using Cathedral Assets Optimizer and try to use them, I get corrupt trees and vanilla terrain textures - same effect as not loading them at all. If I instead install the outputs as loose files, everything works fine. Any idea what I might be doing wrong? Update: I think I got it working - apparently the game doesn't like everything being packed into just a "Main" BA2. I enabled the separate BSA options in CAO and go "Main" and "Textures" BA2's, and those seem to be working as expected.
-
Sorry if this has already been asked, but if there is a future update, can this be fixed to respect the output directory command line parameter instead of writing occlusion.esp to the game directory? This seems to be the only tool in the xLODGen/DynDOLOD suite that doesn't support this mode of operation.
-
The snow textures on the landscape meshes for Throat of the World, the textures on TotW's rock objects, and the land textures on the island in the middle of the lake to the right of TotW all look extremely low-fidelity to me with the tweaked setting compared to the vanilla values. It's entirely possible that the tweak has a different effect if fully following STEP, but I'm not doing that. I've come across A Quality World Map, but I'm confused as to what exactly it is/does. My impression was that it's probably just custom, tweaked pre-generated LOD32 data or something, which isn't interesting to me on its own. If I end up posting more map screenshots in the future, I'll try the standalone cloud removal option. -
Here is the world map with contrast=64, gamma=1.2. The difference seems subtle - maybe a little more color detail in this one, although this is also post-DynDOLOD. With the exception of snow application, the world map rendering seems to be pretty forgiving of tweaks to these settings: And here it is with the fMapMenuOverlay(Snow)Scale=0.00001 settings. I think it looks awful. Seems to force many of the landscape and object textures to be rendered at a much lower resolution: Here are a couple of in-game flyover videos as well - lots of pop-in and z-fighting, but a lot of this is because I'm at speeds and elevations that wouldn't commonly be experienced during normal gameplay:
-
I edited the link to see if it would help. Tested it in a private browser window to ensure it's not a permissions thing. Thanks for the tips and suggestions. I'll try them out the next time I regenerate, although it might be a bit because I've set aside xLODGen for now to work on setting up DynDOLOD.
-
Regarding snow on the world map: sheson's brightness threshold theory appears to be correct! I tried generating Tamriel LOD32 data with brightness=128, contrast=0, gamma=1.0, and the result is that the entire map is a snowy wasteland: Repeatedly dividing the brightness by 2 each iteration and regenerating got me a closer-to-vanilla result at brightness=16, contrast=0, gamma=1.0: Brightness=0, contrast=0, Gamma=2.0 looks possibly even better: Finally, here is brightness=0, contrast=128, gamma=1.0, which I think may look best of all (details seem to pop, and colors look pretty similar to vanilla): I was curious whether these changes might show up in-game, so I regenerated with -255 brightness for LOD4/8/16 so that everything would be black except for the nearby full-detail cells and LOD32. It was hard to tell due to mountains being primarily made up of rock objects, but LOD32 seems to only get used in-game for super-distant stuff like land beyond the borders of Skyrim. Personally I think this makes it pretty safe to optimize LOD32 settings for the world map use case and not worry about in-game effects. Edit: In case anyone is interested in some of the intermediate tests, you can find more screenshots here: https://imgur.com/gallery/JPMuJAr
-
These sound like starting points, not answers. Does this mean that nobody has cracked the snow thing and shared what they did? Does everyone either play with reduced snow on the world map, or use someone else's pre-generated LOD32s that might not match installed landscape mods? Yikes! Is there a way to get xLODGen to only generate LOD32 textures and skip LOD4/8/16 so that I can save time playing with this?
-
So the vanilla world map has visible snow on some of the mountains, and xLODGen's generated world map does not. I don't care if it's accurate or not - vanilla looks subjectively better to me. My understanding is that this is because Bethesda pulled some kind of trick when generating the vanilla LOD32 textures, to make up for the fact that dynamic snow is not applied on the world map? Has anyone replicated the vanilla trickery? If it involves brightening snow textures prior to LOD32 generation, does anyone have a decent set of textures available? It also looks like maybe the entire vanilla world map is brighter, so maybe I'll try cranking the gamma way up on LOD32 and see what happens. Vanilla world map (note snow on mountain): xLODGen world map (note lack of snow on mountain): xLODGen in-game (note snow on mountain):
-
Looks like even 80% white might be a bit darker than the full quality textures: noise.dds: Over land: Over snow: Edit: Here is a noise.dds that I think works pretty well without changing the darkness of the LOD textures: https://mega.nz/file/mtlBXKLL#-AUQTa2l2g4V0aJRCp-davpR1KM5sqYmeq5s794JO3k It has greyscale values between 192 and 255 (basically 75-100%).
-
[Display] bEnableLandFade=0 seems to be a massive improvement. It's also a misleading name, because the game still does a non-instant change from LOD4 to full detail when a new cell comes into range - it just doesn't try to do the dithering thing. I wonder what would happen if xLODGen had the option to generate meshes that are just slightly lower than they should be, though. On the separate subject of noise textures: I've been messing with generating my own, and I'm curious what grey level is considered neutral, such that it wouldn't change the LOD texture brightness at all. Does anyone know? Also, I noticed that lowering opacity (such that the texture is more translucent in the paint program) appears to actually darken the LOD textures, so I've been leaving it at 100% opaque (zero translucency).
-
Update: Tried generating meshes with various LOD4 quality levels: 5: almost no flickering / much closer to vanilla 2: fair amount of flickering, but the pattern is triangles instead of little squares 0: tons of flickering and little squares (this is what I've been using) -1: fair amount of flickering, game crashed after a minute or so Not sure why STEP recommends LOD4 quality 0 when it flickers so badly.
-
Using vanilla meshes with xLODGen textures, there is - except for some large non-flickering triangles - a smooth transition between full-quality and LOD textures via a fading pixel-level dithering effect: With xLODGen meshes+textures, there is a highly pronounced pattern of little squares that flicker a bunch and seem to be exempted from the fading pixel-level dithering:
-
Confirmed - using just LOD4 meshes still results in flickering. Here are the settings used. Log reports app version SSELODGen 4.1.3b EXTREMELY EXPERIMENTAL Terrain LOD BETA x64 (B97D7181):
-
Update - it's definitely the meshes that are involved in the cell edge flickering: Everything with mipmaps enabled: FlickerJust meshes: FlickerJust textures: No flickering Trying some different mesh options: Reducing LOD4 mesh quality 1 and 2: FlickerTurn off protect borders: FlickerTurned off baked normals (don't think this applies but I'm grasping at straws now): FlickerGenerated without SSE-Terrain-Tamriel.esm and with Bashed patch active: Flicker Went back to vanilla LOD data, and verified no flicker, so I'm at a loss as to what else I can do. Maybe disable various mods before generating meshes?
-
I used the STEP settings, which have mipmaps disabled: https://wiki.step-project.com/STEP:0.3.0b#Generation Someone said in another thread that you told them that mipmaps aren't used, so apparently we're all confused about what to do now: https://forum.step-project.com/topic/15184-xlodgen-terrain-settings-compare/page-2?do=findComment&comment=242498 To my knowledge, I'm not using any textures that are larger than what come with Skyrim SE - just higher quality versions of some of them. It sounds like I should try the following to diagnose the flickering, until/unless one of them is spotted as the culprit: Generate with mipmaps enabled? Generate only meshes and see what happens. Generate only diffuse/normal maps and see what happens?
-
I mention the z-fighting because it's not there with the vanilla LOD. Note that this is not water z-fighting, but rather it seems to be LOD failing to blend with full-quality terrain at cell borders or something. The screenshots are only useful as comparisons with each other, as they are heavily orange-tinted as a result of being at dawn. Both of my flyover videos are recorded at just after midday game time.
-
I'm assuming CL refers to Cathedral Landscapes. Note that per the mod list in my previous post I am not using that mod, because I'm trying to start more conservative than STEP. What I think I'm getting out of your replies (thanks BTW) is that the bright white stuff in the vanilla LODs is considered to be an undesirable artifact (or possibly artistic license) on Bethesda's part, and does not reflect the actual landscape? Since I'm not using CL, should I be messing with noise textures, or is the 1.25 gamma just as good, or something else? I understand this may be a controversial topic, so all opinions are welcome. Another issue I noticed is that there seems to be some weird z-fighting at the edge of grass range (probably where LOD4 kicks in?). I made xLODGen and vanilla LOD flyover videos to demonstrate. Note that I have installed Better Dynamic Snow SE and regenerated with STEP settings since my previous post. Vanilla: xLODGen:
-
I recently started playing Skyrim SE and decided to try playing with xLODGen (*no* DynDOLOD yet). Despite following various guides closely, I've had some indeterminate results such as Skyrim crashing on save file load and xLODGen crashing during generate. I was ultimately able to get it to work with various settings, however, and collect results. One major thing I noticed is that xLODGen generated LOD data seems to no longer have any of the white (snow?) that is present in the vanilla LOD. Is this expected? The "improved" snow shader is OFF, and mod list is at the bottom of this post. Vanilla LOD - note white snow highlights: LOTD LOD - very dark textures: STEP LOD - not as dark, likely due to 1.25 gamma recommendation: Mod list: [spoiler=mod list](Part 1) Engine Fixes-17230-5-4-0-1597134892 All in one-32444-2-1582543914 Better Dialogue Controls v1_2-1429-1-2 Better MessageBox Controls v1_2-1428-1-2 Cathedral - Weathers-24791-2-22-1583904997 Cathedral Weathers MCM-24940-1-3-1578270480 Enhanced Ore Veins - 2K - 8.0-1306-8-0-1595238568 Flora Respawn Fix SSE - 2.1.3.zip-13186-2-1-3 Immersive HUD - iHUD-12440-0-2b JContainers SE-16495-4-1-12-1574419908 kart_CSSET-38775-1-2-1596977529 KeyboardShortcutsFix_SKSE64-3620-1-0-0-2 More Informative Console for SKSE 2.17-19250-0-34-1574384572 More Visible Arrows and Bolts SSE-5626-2-0-1550387867 output Relighting Skyrim SSE v1.1.0-8586-1-1-0-1573083114 Skyrim_Particle_Patch_for_ENB-SSE SkyUI_5_2_SE-12604-5-2SE SMIM SE 2-08-659-2-08 SSE Display Tweaks-34705-0-4-5-1597351089 Unofficial Skyrim Special Edition Patch-266-4-2-3-1587854191 Vidani's Bag of Holding-16977-2-1 VioLens - A Killmove Mod SE 2.22a-668-2-22a-1560801018 Plugin list: [spoiler=Plugins]Skyrim.esm Update.esm Dawnguard.esm HearthFires.esm Dragonborn.esm Unofficial Skyrim Special Edition Patch.esp kart_CSSET.esp kart_CSSET0.esp kart_CSSET00.esp kart_CSSET000.esp kart_CSSET0000.esp SSE-Terrain-Tamriel.esm SkyUI_SE.esp FloraRespawnFix.esp SMIM-SE-Merged-All.esp Cathedral Weathers.esp CathedralWeatherMCM.esp CC'sEnhancedOreVeinsSSE-HearthfirePatch.esp RelightingSkyrim_SSE.esp Particle Patch for ENB SSE.esp VioLens SE.esp Vidani's Bag of Holding.esp iHUD.esp Bashed Patch, 0.esp
