z929669
-
Posts
13,028 -
Joined
-
Last visited
Everything posted by z929669
-
Where? in DynDOLOD or xLODGen "Object LOD" tool? is it even relevant in xLODGen, given hat DynDOLOD exists? The terrains stuff shouldn't be impacting object LOD at all (hence my questions about the relationships among all four tools inside of xLODGen and to DynDOLOD/TexGen). Still not understanding how these settings can affect what we're doing in xLODGen "Terrain" tool. These INI settings would seem to be limited to the res of the source files. Apologies for all the Qs, but I've found poured over doc and posts to little avail.
-
Unfortunately, I've been unable to find much of anything relating to xLOGGen doc outside of what comes with the program: Terrain-LOD-Readme.txt - definitions of settings only ... no context as to how it relates to other LOD gen tools like DynDOLOD or SSELODGen -- > links to this Nexus page, but no clue as to the relationship to this toolSkyrim-Occlusion-Readme.txt - Technical aspects of the 'Occlusion' tool in xLODGen but not a lot of context.NO doc on "Object LOD" tool and relationship to or redundancy with DynDOLODNO doc on Trees LOD tool and relationship to or redundancy with DynDOLODOne of the main reasons for the existence of STEP is to explain this otherwise disjointed information within a contextual framework that makes sense ... to provide an easy-to-comprehend summary of modding tools, relationships, actions, and reasons. To bring it all together for a common understanding and disambiguation. Much is needed on that front with respect to LOD gen tools as they exist today. I have little doubt that ALL of the needed info is scattered among the official doc, links to ancillary doc, and within forum threads, but nowhere can I find it consolidated and brought together for the layman except for in our main guide, which skims over most of the relevant context.
-
Placehoder. We'll be discussing DynDOLOD settings, requirements, and relationship to other LOD gen processes like TexGen and xLODGen.
-
I think this post answers your question. The DynDOLOD doc does as well, but I have yet to read through it with any real understanding. I've read it and need to read it again and again ... my brain does not easily extrapolate to "ah-ha!" with limited explanation, which I think is the case with the DynDOLOD doc. It assumes that the reader understands some prerequisites, without which, the doc can look like word noise. Tech has more XP than I at this point regarding relationship of TexGen textures and DynDOLOD object texture generation, but from what I am reading in that post, I want to be certain that my "Max Tile" equals my TexGen res. Leaving all as default should be good enough for most custom replacers, but with all the high res stuff out there now, I'm inclined to use 1024 for everything if performance isn't an issue. I think you can go higher than this even. Not sure if that is necessary or dependent on replacers in the load order, but it seems like it. From TexGen doc: I'd like to improve the TexGen and DynDOLOD instructions in our guide to provide more context and explanation of settings used and their interrelationships, which at this time are limited and we are not saying much about the relevance of the DynDOLOD Resources SE 'mod', when to activate/deactivate, Max Tiles, and relationship to TexGen to name a few. I plan on starting another thread for this testing and disambiguation. I don't think that process is in any way interdependent on the xLODGen process described here; although, it all contributes to total LOD gen.
-
Do these settings tell the game what LOD level to use for the map? Won't there be a cap based on available LOD for the map? Do you help to maintain the INI wiki? I see these values in that, but advice there does not match yours for these settings, and the defs there don't really explain what these settings are doing.
-
The stems and leaves are pretty much the same in vanilla/CL/Hybrids. Hybrids flowers appear a bit more lush, but they actually look more like flowers. Vanilla/CL inflorescence look like fake plastic from the hobby shop to me.
-
Compare set 3: xLODGen Final Result Compares To summarize, the following compare is the final compare showing 1. native CL terrain vs 2. xLODGen CL terrain with new optimal settings: SPM stats are included in the images (you can do this in Windows using ALT + WinKey + Prtscn while SPM is running). NOTE: all of these compares look at terrain LOD ONLY. Do not be fooled by crappy tree and object LOD - DynDOLOD modifications are NOT included here so that we can examine STEP under different xLODGen quality scenarios. Also, do not be fooled by smoke and clouds. These are dynamic in some shots, so many diffs noticed when toggling between any given compare set are due to this texture interference in SOME compare sets. [spoiler=Final Result Compares] ConclusionI think we can agree that the xLODGen version is staying true to the CL terrain texture patterns and blending. There is a notable difference in brightness in the first compare set and less so in some of the other darker terrain compares (the new optimal settings are a bit darker and more saturated, but it's not noticeable on lighter terrains), but I think it still blends nicely. There is no real brightness difference in most of these compares though, and saturation is a bit better with the new settings (I slightly prefer the xLODGen results). We could arguably increase gamma to 1.26-1.28 to eliminate the brightness difference if necessary ... thoughts?? Now to address LOD32 and map quality ... I found that we can lower the quality of LOD32 to '4' from Tech's value of '0' without any noticeable impact to quality, further reducing the output size and gen time by small fractions. The following show the diff. The first set uses a quality of 0 under the old 'optimal' settings without any brightness correction and the second uses the "new optimal" settings. Although the brightness difference is a bit distracting, I think that there is no perceptable quality loss: [spoiler=LOD32 Map Compare]
-
Compare set 2: xLODGen Brightness Settings Compare Now that we have a 'good' starting point for xLODGen quality settings (see previous post), we will examine the best way to fix the 'dark' LOD problem next. The following compares use xLODGen quality settings where applicable as described in the previous post ... with the exception of the HDT noise map compare set: rather than capturing the screens yet again, I opportunistically used a set where I had the 'otional' settings active + HDT Light noise map, because we already agreed that there is NO difference in the quality output of these settings (see previous post). Additionally, I experimented with brightness and gamma xLODGen settings. SPM stats are included in the images (you can do this in Windows using ALT + WinKey + Prtscn while SPM is running). NOTE: all of these and forthcoming compares look at terrain LOD ONLY. Do not be fooled by crappy tree and object LOD - DynDOLOD modifications are NOT included here so that we can examine STEP under different xLODGen quality scenarios. Also, do not be fooled by smoke and clouds. These are dynamic in some shots, so many diffs noticed when toggling between any given compare set are due to this texture interference in SOME compare sets. These and forthcoming compares examine 9 different locations. For this set, we are looking at five variants per location in the following order (including xLODGen generation time and output size): (Tech's) revised settings 23:45, 2.91 GB >> 'optimal' settings + HDT Light noise map 36:22, 4.19 GB >> revised settings + brightness = 8 24:23, 2.91 GB >> revised settings + brightness = 2 & gamma = 1.20 24:04, 2.91 GB >> revised settings + brightness = 0 & gamma = 1.25 24:05, 2.91 GB[spoiler=Brightness Compares] ConclusionxLODGen produces LOD textures that are too dark, presumably due to it's using the base textures as the input ... which for reasons I don't understand wind up looking darker than expected in LOD. The fix is to either brighten using a noise map (as suggested by sheson) or using brightness/contrast/gamma settings in xLODGen. Altering the applicable noise map (not included in this compare) may be viable, but simply using a noise map not meant to be used with Cathedral Landscapes (or whatever the STEP landscape mod may be at any given time) is not appropriate. While it has the effect of brightening terrain as desired, the noise filter just doesn't facilitate the desired blending as the CL authors intended (especially noticeable on the darker, more colorful terrains). This is fixed by modifying brightness or gamma settings during LOD gen. It turns out that either works well and results in good blending, but using gamma settings produces the desired correction and also retains more of the color saturation of the original textures (especially noticeable in the Riften and other darker terrain compares), so I'm proposing that we use gamma to alter brightness (gamma modifies mid tones without affecting darkest/lightest, whereas brightness lightens everything in a linear fashion) ... this post explains it nicely. ... see next post for final results
-
Compare set 1: xLODGen Quality Settings Compare First post of my fairly exhaustive testing. This first set looks at xLODGen quality setting differences between the latest 'optimal' settings and Tech's "Custom Settings". The main difference is that the 'optimal' settings use higher resolutions and quality = 0 (highest quality). Tech's revised settings use lower resolutions and slightly lower quality. NOTE: The revised settings used here are identical to Tech's settings with the exception of LOD32, where I set Quality = 4 rather than 0 as Tech has it. These textures are almost never seen except for when looking at the map (proof coming in a later post). SPM stats are included in the images (you can do this in Windows using ALT + WinKey + Prtscn while SPM is running). NOTE: all of these and forthcoming compares look at terrain LOD ONLY. Do not be fooled by crappy tree and object LOD - DynDOLOD modifications are NOT included here so that we can examine STEP under two different xLODGen quality scenarios. Also, do not be fooled by smoke and clouds. These are dynamic in some shots, so many diffs noticed when toggling between any given compare set are due to this texture interference in SOME compare sets. These and forthcoming compares examine 9 different locations. For this set, we are only looking at two variants per location in the following order (including xLODGen generation time and output size): 'optimal' settings 36:22, 4.19 GB >> Tech's revised settings 23:45, 2.91 GB[spoiler=Compares] Conclusion Hopefully, everyone will agree that there is NO quality difference. There is also NO significant performance difference. Variants of Tech's settings will be used for the remainder of these compares (see following posts).
-
Skyrim Special Edition Upscaled Textures (by Kartoffels)
z929669 replied to TechAngel85's topic in Skyrim SE Mods
Given what we've found with CSSET, we should probably also look more closely at this. Tech is including SSEUT in his compares on other threads just after vanilla ... so far, these seem to be a slight improvement in those cases. Looks like these versions have slightly increased gamma and saturation compared to vanilla SE, which adds some detail ... not sure if this also affects mips, but it would need to to be consistent. -
I don't know for certain, but that snow may be object LOD that would be fixed by DynDOLOD (not xLODGen). To test, try increasing your terrainManager settings in skyrimprefs.ini ... try these setting and see if it's fixed: [TerrainManager] fBlockLevel0Distance 106496 fBlockLevel1Distance 348160 fBlockMaximumDistance 393216If so, then DynDOLOD should fix (and you can revert your INI to whatever you had it before).
-
I get it ... just sayin' though.
-
Rally's looks like it's tiling (I notice the tiling more, rather). I like STEP better
-
Agree ... at least for frozen puddles for sure
-
Yeah, sorry. I had been looking at thistle just previously, so I had thistle on the brain. I meant lavender I think Hybrid's is the best depiction of actual lavender.
-
Ditto
-
ACCEPTED Superior Mudcrab - 4k Retexture (by Shoyguer)
z929669 replied to TechAngel85's topic in Skyrim SE Mods
Ditto -
I'd like to see the lone tree and the one behind Ria close up compares to determine if the mips are messed up in CSSET. Agree with Tech though. I've lost a bit of faith in this mod, since it seems like it may have been created hastily using broad strokes (batch-file processed, BSAs packed incorrectly, identical-to-vanilla textures included, vanilla replacement BSAs). I suspect that all of the hard work of examining and verifying each texture in game has not been done (and I don't blame the MA for not doing if that's the case ... let the community nitpick to find the issues).
-
Better Dirt Cliffs and Alphas (by cthunsthrall)
z929669 replied to TechAngel85's topic in Skyrim SE Mods
I like where this mod is going and in many cases seems like an improvement ... but I think the dirt is too dark in some cases and contrasts too much with the bedrock. The third compare set really shows this. Looks like there was an oil spill. I would love it if the author lightened the dirt up just a bit. LOD would look really stark. Vanilla doesn't look good either, but blends better, especially in the distance. -
Yeah, current STEP seems best.
-
ACCEPTED Superior Chaurus - 4k Retexture (by Shoyguer)
z929669 replied to TechAngel85's topic in Skyrim SE Mods
Thanks ... I know that we have compared AMB to vanilla, but that was LE. It seems like any vanilla SE texture is fair game for a reevaluation if it has been enhanced (no idea if that's the case for chaurus stuff). Outside of the banding you found, I like superior best (and also because it restores the vanilla chaurus with an improved and more vanilla friendly version. Otherwise, I think current STEP is best for all others. -
Hybrids is true to vanilla and looks to be using the vanilla texture for the entire plant but for the flowers/receptacle and the buds. I actually like the vanilla flowers/receptacles best, but Hybrids adds a bit of variation to the little buds. If vanilla SE plants all look as good or better than Hybrid's variants, then I question using that mod as well. I vote not to use Mari's thistle.
-
I think this is true. Quality of quick may be theoretically better, but you will never see the diff if that's the case. @Lexy sheson has verified indirectly that terrain probably doesn't use mips for diffuse, and I tested that it probably does not for normals either (VRAM is pretty much unchanged with/without). Makes sense too, because terrain probably just doesn't need mips, and I don't see how there would be any benefit. The detail is really not as important as blending for terrain LOD. Also, the settings on the wiki right now are probably overkill. The settings Tech found in a previous post seem to be just as good with half the size and time and slightly better performance. I'm still running a big set of compares under varying conditions, but the final result looks to be closer to Tech's settings. I even have some evidence that the xLODGen result may not be as good as just skipping this part of LOD gen ... at least with Cathedral Landscapes. Terrain LOD Gen seems to bork the otherwise nice blending of CL landscapes with landscape objects ... final determination coming soon in a post to this thread.,
-
Indeed. Just a baaad idea. @tech I mean a closeup of the tree in the OP ... The pine cloeseup looks softer with CSSET ... could be why it loses more detail in mips. The problem with batch editing anything is that you may fix some issues and introduce others that don't fit the batch specs. Unless the result is a net gain in performance or appearance, it's not worth it. So far, I'm not sure if this is a net benefit or not, so I will defer to your judgement.
-
I vastly prefer Hybrid's. Maris looks like it adds grass that is totally out of place. Thistle is not a monocot and would never grow any grassy leaves, and it is very hardy. Curious: what does vanilla look like? Even Hybrid's leaves don't look like thistle (which has many varieties, so some leeway is understandable). I think we should try to include vanilla for replacers if it's not current STEP, since that is what we are trying to improve upon. SE vanilla may be better than we remember with LE vanilla when we decided on the current replacer.
