HunterZ
-
Posts
20 -
Joined
-
Last visited
HunterZ's Achievements
Citizen (2/12)
0
Reputation
-
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):
