z929669

DynDOLOD section, grass config ... expand spoiler

The Step guide. I have corrected it in that post as well now.

I had fixed that a couple days ago. Refresh browser cache

Not significantly if at all. Output may be a bit bigger though

As DoubleYou mentioned above, there is no grass in that area way out there (LOD8). As Phlunder mentioned above, that is your landscape mod(s), and the texture color doesn't work with your grass. Your grass LOD4 looks like a good match. Leave your grass alone for now and get a different landscape mod. I would check Folkvangr mod description and posts for ideas. EDIT: And as has also been mentioned many times elsewhere, DynDOLOD versioning has nothing to do with it. It added HD grass functionality to better support ENB-CG, and you can disable that and not use CG and use the same settings you previously used. DynDOLOD works the same, and your config is not optimized.

DynDOLOD versions don't suddenly change the way LOD looks. Your own config settings and mods to that. updates to DynDOLOD only add functionality. LOD still works the same. To minimize z-fighting in mountains, try setting a mountain mesh rule and use Level0/Level0/Level1. This is why you didn't have this issue before ... because you were using the Step guide as a basis (we set all DynDOLOD mesh rules via config files). You keep changing your entire LO though, so you will obviously need to reconfigure many things when you do that (INI settings, grass/landscape, weather, ENB settings, etc.).

NGIO doesn't work with SSE 1.6.xxx ... you should know this? I have posted many screens of CL grass for you in several topics. See the current Step guide in Performance Tuning as an example. Terrain needs to match the grass as was mentioned above. The reason you had it matching previously is because you were using CL and CL complex grass (Step's landscape config). The grass you are using doesn't work well for the landscape mods you are using (Folkvangr and Tamrielic Textures, I assume).

It doesn't bother me that you think my position is weird. Nevertheless, I find it annoying that we have yet another flavor of this game distinct from existing. It causes more confusion and creates noise all around (unless Nexus parses it out into another 'game', which doesn't seem to be the case). LE/SSE/SSE-GOG are effectively different games with incompatible runtimes. (and are on different dev branches)

I had the same questions, and I am pretty disgusted with this GOG version and the continued disenfranchisement of the modding community at large with all of these opportunistic partnerships-in-cash-grabbing. It's going to cause yet more disruption and confusion for mod users and certain mod authors.

I for one am ignorant with respect to shader config/handling in the mentioned context. I can think of a number of mod authors that may be familiar with this use case. @sheson may be one such person.

xLODGen mips are only enabled for LOD4 and LOD32 (map). The texture sizes are optimized for HD/QHD/4k respectively just as they were in the previous guide. TexGen max texture size should be 2048 at 4k ... I will fix that when I get some time.

DY actually did the Aspens Ablaze reduction for LOD in Blender I think. My assumption is that he configured Decimate as he liked and re-UV'd, but I'm not sure. It may be possible and simplest to use NifSkope > Optimize functions, but I haven't tested that. The general idea is to reduce triangles. There are several algorithms in the respective 3D toolsets that could accomplish this for better/worse results. Alternatively, consider manually combining separate leaf/branch polygons into a single shape using a new combined texture and re-UV that. Either way, the key is to keep the LOD model result as close to the full model result as possible so that transitions are not too obvious in game. This is why an algorithm can be beneficial over manual (tip: constrain overall shape while combining triangles). The latter will often look better, but transitions can be worse without putting in many hours of labor and testing. Trees can be a lot of work, but they have the advantage of randomness with respect to 3D layout.

The settings are all correct and consistent with the previous guide version (2.0.0) but for two differences. First is the Default size setting for xLODGen. This should technically be 256, but it probably doesn't matter, since it is a catch-all that will otherwise use another value I believe. Let us know if sheson explicitly recommends it be set to a value in the doc or a post. Second, we recommend BC7 Quick everywhere, since that seems to be possibly faster and just as reliable. Max should work fine though. I don't see any difference between the two in game. These are terrain textures that don't really look great anyway, and they are only noticeable when missing or when something is really 'bad' (like z-fighting or other GFX anomalies). Regarding mips, we intentionally use them on the map (LOD32) and at LOD4 along with Raise steepness. It isn't clear if either one of these settings make any difference at all. If sheson has evidence that these increase z-fighting issues, we will change them, but I don't think there is evidence either way.

After all this time, it seems like this MAs aren't parsing out the irrelevant changes into separate mods as suggested and is adding more unrelated changes (e.g., farmer/crop ownership). Given all of the mods they have authored, I'm not sure why this one continues to be the target for all of the misc changes. Anyway, they got back to you on the interior flip, and it makes sense ... but for a separate mod, IMO ("misc interior fixes" mod or something ... in addition to "farmers own crops" mod and others). It's a shame, because this mod does add relevant fixes ... but I would also consider dropping.

It's been around for a while and is possibly a better version, but I haven't tested it.

That's too big. Most tree models in Skyrim are between like 1k and 5k triangles give or take. For performance versions, you want less than 2k I would think. Aspens Ablaze trees have around 5-10k and the big ones are closer to 15k, I think. That's a FPS taxing mod.

@TechAngel85 Can you confirm the new Options for use with RS? We need to update this FOMOD accordingly. I am pretty sure I know what we want, but wanted to confirm with you. Thanks

Those were added in 1.8 I think in early-mid Aug, and we have opted for the scripted version as indicated in the wiki instructions

As DY alludes, trunks are typically less than 1/2 the triangles than crowns and contribute to FPS loss proportionately. It depends on the mod. EVT trunks are relatively high poly compared to most tree mods, ranging between trunks being 1/3 to 2x the triangles of crowns. HLT trunks have more like 1/3 to 1/6 the triangles as crowns. Decimate or other reduction algorithms (e.g., InstaLOD) normally don't treat trunks well without constraining the modifications in significant ways. This is all resolved by making hybrids with flat trunks using the DynDOLOD tools. Reducing crowns (merging triangles) and re-UV of those are much more forgiving. If you really do want to tackle trunks, you should focus on the dead trees or those that don't do as well when flattened. You can judge by trunk shape. Straight trunks can be flattened, and bent ones and those with obvious crown branches without foliage hiding them looks more obvious when flattened and should be the focus.

For specific versions, Blender has a NIF export plugin I believe. It should export the proper transparency required as DY mentions. If not, then you should be able to add NiAlphaProperty to the branch node via NifSkope. Collision will be another hurdle too.

I use 3DS Max and Maya, but Blender is the only good open-source, free program and works fine too (it's just difficult to learn). 3DS Max is probably simplest to learn. The main issue with all tools is that none are natively compatible with the Gamebryo NIF format, so custom plugins needed and all are limited to more/less extent.

I've corrected our server time, which was off. I'm also using creative ways to re-index search on forums, since there is evidently no simple way to do this via software admin (as there had been years ago ... this is what happens when UIs are 'upgraded' for dummies). My initial testing seems to have worked, so I am setting the lookback to three years to trigger another index. This will likely take minutes or hours to complete. EDIT: It's fixed now with 3-year lookback. I'd rather have unlimited lookback, but 3 years seems like a viable compromise for 99% of search relevance

@Majorman can assist on this topic, but can you share what was happening and how you resolved?

Discussion topic: Step FalloutNV Guide (curated by Majorman) Changelog Nexus Mods Please submit feedback about the 1.2.0 guide to this topic.

SO ... since you have had your LOD issue with alpha 97, you have since run alpha 95 again to confirm it works? You have run alpha 95 AFTER your alpha 97 failed run? If not, then you cannot say that alpha 95 works and alpha 97 is the source of your issue. The source of your issue is in your configuration as has been mentioned several times. Why can't you consider that you have made a simple mistake that has nothing to do with DynDOLOD?