z929669

This is interesting for Step if you can recommend any lore-consistent add-ons if necessary. Normally, we wouldn't look at anything that changes the vanilla look/feel, but in the case of the overused lock graphic in the minigame, I think it's reasonable to assume there would be variation at least with respect to common and ornate variants, depending on the lock.

It's been "Accepted" as denoted by the Topic tag. You can always create new mod topics using the ▲ editor tool. Then we could tag the topic for testing and ultimately accept or not.

It notes the mod list in the left pane and not the plugin list in right pane. The mod list is what it is, depending on how the CC content was installed and detected by MO and Steam during validation ... it really doesn't matter, because the plugin list is the same. I will reorder so that they agree though.

The OP has all of this information.

I went with the 10% reduction, and I think this is about right, IMO.

Just beneath this phrase, are the instructions and table for configuring the tools in MO. Just open up the spoiler instructions and continue forward. I will rephrase that sentence.

As I said, it's hardly noticeable and no issue, IMO. Your setup exacerbates the problem, and I have mentioned several ways to mitigate with vanilla-based pine mods. It IS the tops of the trees and due to the normal faces pointing out, as I have mentioned a few times in the two or three topics where you have brought this up. Those are very different and custom meshes in no way taken from vanilla. The top branches are situated similarly to the bottom branches.

Create the mod pages on the SE Mods forum and provide a description for each below the horizontal line to invoke the review process. Use the editor tool with the change icon.

Discussion topic: Obsidian Mountain Fogs Tweaked by Cathedral Team - Scott Clam Wiki Link

This is EVT 2.2.1 Lush Trees file with SFO v1 textures, and the Step ENB ... no issues, IMO: Some EVT texture options may behave differently in combination with some mesh options as well as TexGen/DynDOLOD settings, ENB, and weather mods. With 'good' settings and configuration, the different brightness at tops of trees (can be darker or brighter, depending) is avoidable. The root cause is due to lighting reflecting differently at tops of pine trees, because the branch planes face out at varying angles rather 'up' towards the sky like lower branches. This causes light to behave differently ... but it can be mitigated by configuration choices as I said. The same happens with pine trees in other tree mods to varying degrees.

EVT has many texture options.

Choose different textures with default mesh

My guess is you need to rebuild you grass cache and that CGID Wyrmstooth is effectively overriding GID Wyrnstooth (game engine may be using the former). There may be a key piece of info you need to generating Wyrmstooth grass. @DoubleYou will know about that.

This is with the CL CG mod installed and not default CL, correct?

Sounds like a plan. I assume you noticed that the testing with the normals-only prepass FX Boris provided on the Discord reveals that the grass LOD normals aren't rendered for some reason. If that's the case, then getting them to render would be key. It may be that they don't resolve in game against the terrain normals, but IDK. On another note for your testing, I learned (DoubleYou suggested) that grass fill/LOD matching is better with constant DynDOLOD_SSE.ini T/B-RGB values of 1.0 0.5 (so no color bias; other brightness settings at your defualt), and reduced TexGen direct/ambient. This is the best matching I've gotten for complex grass in all weathers and ToD on the tundra. I assume that without the color bias, snow, Rift, and Reach grasses will also match well: That's with ENB-CG active and FakeLighting/SSS > 0 in ENB (so with 'optimal' ENB-CG lighting bias). Here's recommended DynDOLOD/TexGen (≥alpha 96) settings for the record: ;Without ENB complex grass ; grass LOD brightness multipliers GrassBrightnessTopR=0.500 GrassBrightnessTopG=0.500 GrassBrightnessTopB=0.500 ; make bottom darker to fake shadowing GrassBrightnessBottomR=0.500 GrassBrightnessBottomG=0.500 GrassBrightnessBottomB=0.500 ;With ENB complex grass ; grass LOD brightness multipliers ComplexGrassBrightnessTopR=0.500 ComplexGrassBrightnessTopG=0.500 ComplexGrassBrightnessTopB=0.500 ; make bottom darker to fake shadowing ComplexGrassBrightnessBottomR=0.500 ComplexGrassBrightnessBottomG=0.500 ComplexGrassBrightnessBottomB=0.500 *NOTE: DynDOLOD defaults for the above settings correspond to the vanilla game and the vanilla game using "Vanilla Complex Grass for ENB" mod and default ENB 0.475. TexGen Grass Direct=110, Ambient=15 (this should be close but untested) TexGen HD grass Direct=0, Ambient=160 EDIT: the grass also looks fuller in LOD with these settings. And from this angle with 5000 timescale, all weathers/ToD look good. Presumably, this would also work for non-CG grass with and without ENB with slight proportional decrease of TexGen direct/ambient EDIT: Link to latest discussion from second round of testing: https://discord.com/channels/708699116519161907/708703386161381387/997244135880790098 EDIT: The important thing to note about top/bottom DynDOLOD brightness settings above is that they are all equal to allow color tone to be governed by the game, textures, shaders, and underlying configuration. This eliminates DynDOLOD itself as a source of bias to color. To allow controlled bias by the end user, setting a constant of 0.5 as opposed to 1.0 may be preferable. TexGen Direct/Ambient can be used to compensate.

If you are using Billboard1 or Billboard4 at any LOD level, then I think those are both HD tree. Other billboard stuff is just Tree. Adjusting by larger increments is useful at first to get into the right neighborhood. Increments of +/-10 are good once you are in the right neighborhood.

Sheson can help more, but while he is away, I would try loading up a vanilla instance to see if DynDOLOD runs correctly with that. This will rule out a mod-specific issue.

You need to test with values of like 135/55 (default I think), 155/75. 110/75, etc. Ten isn't really enough to tell much difference. That's why there is a preview in TexGen. Use it for a better idea of the degree of difference.

Look at the pinned topic in this very forum or use search. This sounds like the same issue with Windows Security 'features'

The normal map needs a alpha specular map with rgb(127,127,127) pixels in lower left corner for SSS. Pixels for normal lower left must be valid normal like rgb(127,127,255). THis is what ENB is reading for the effect to work. I have inspected the TexGen temp folder created during processing and have seen how the atlas is split apart presumably to grab the diffuse/normal for the atlas, so keeping the specular alpha in the normal atlas may be possible if grasses were split from the combined DynDOLOD texture atlas. But who knows what the mesh needs on the grass billboard node ...

I poked Boris and some others thinking about this on the ENB Discord. https://discord.com/channels/708699116519161907/708703386161381387/996783478446235688 I don't have the knowledge to be of much assistance on either side (but I can test).

@sheson I am wondering if you have looked at complex grass support in LOD. I don't know if it's even possible, given the ENB requirements vs DynDOLOD atlas-texture requirements, but there is no way I can find to get a good LOD match in all lighting/weather conditions with LOD grass behaving similarly to loaded grass in terms of light sources and observer PoV. Basically, ENB-CG looks at lower-left pixels of 2:1 (vertical:horizontal) texture atlas with diffuse/normal, opacity/specular in the alpha. I'm not sure if this could work using the DynDOLOD atlas and grass components of the super meshes, but figured you would have some idea of the limitations for LOD. I created CG for vanilla and Cathedral Landscapes for testing purposes if you ever have appetite for looking into it.

As I have mentioned in the other topic, the normal faces don't point towards the sky light source like lower branches do, so you can get T/B differences in different lighting situations (weather and ToD). This can be exacerbated by the textures chosen for EVT and to some extent the mesh Lighting Effect values. I don't recommend using the darker meshes, as those probably also exacerbate the issue. Go with the defaults for installing EVT, or choose a few different options , and install as different mods (there are hundreds of combinations and results). Run different outputs of TexGen and DynDOLOD for compares.

The effect is only barely visible wihtout your ENB, and your ENB exacerbates the issue dramatically more than other ENBs. Yes, those settings for TB. Preview in TexGen to see the effect on a tree.

It seems to me that Landscape fixes isn't at all the problem and that you likely changed > 1 thing in your method or config that allowed GID to work as expected. There is no way LFfGM could cause GID/CGID to work any differently than expected. More likely, you had GID/CGID active in your LO and DynDOLOD settings mismatch or other config inconsistencies. This is precisely why we recommend people follow the System Setup Guide and use other best-practice methjodology, because it removes much of the noise and inconsistency from the equation. I still think this is the root cause of many of your issues ... inconsistency/unpredictability, and altering > 1 variable between tests.