GUIDE Skyrim Special Edition Grass LOD Guide

[z929669]

17 hours ago, Mousetick said:

They're not helping because they're incorrect, misleading or wasteful. They're confusing because they mix different concepts, procedures and tools together in a single overly long and complicated process. Some of these concepts are outdated or irrelevant when GCF is used and NGIO is no longer used in-game. It's very hard for users to understand cause > effect, role or dependency relationships with such convoluted and unstructured descriptions, making it impossible to troubleshoot when something goes wrong. It's just one big nebulous blob.

Case in point: This topic's OP believed the grass cache was only used for grass LODs, not for full grass. I'm not surprised. That's precisely the kind of confusion the current guides induce.

The-Animonculory guide in particular shows the author doesn't really understand how NGIO precaching or GCF truly works (DO NOT ACTIVATE YET!), and is often parroting bits of advice from different sources, some copy-pasted from the (outdated) STEP Grass LOD Guide. 

For example, some fluff can be eliminated from either guide by first removing details and instructions pertaining to NGIO in-game rendering, which are completely irrelevant when NGIO is used only for precaching. Another example, asking users to edit Skyrim.ini [Grass] settings, which are then overridden by GCF's own INI, is useless and misleading.

The only correct "grass cache" guide, from my perspective, is the very succinct Usage section of the GCF mod page, which assumes an already existing NGIO grass cache (generated separately), and makes Grass LODs (using DynDOLOD) optional. It's fairly straightforward, and is exactly the same for both Skyrim 1.5.97 or 1.6.x. It's only concerned with NGIO grass cache usage, either for full grass, or for LODs, or both.

• NGIO grass cache generation is left as an exercise to the user. Arguably the more complicated and delicate part, it deserves its own separate guide, without any consideration for LODs generation, as no consideration is necessary whatsoever.
• Alternatively the user can use a 3rd-party pre-generated cache for a specific load order or modlist (assuming it matches "perfectly").
• The STEP Grass LOD guide could be trimmed down to only the LOD generation part with DynDOLOD, using an already existing NGIO grass cache configured with GCF as a requirement.

Apologies for the ramble.

15 hours ago, DoubleYou said:

I think the important thing to understand here is that usage of NGIO and grass LOD are extremely advanced modding concepts that most users are not going to perform because it is time-consuming and difficult. Ultimately the best solution would be to create an application to automate the process, and would be far easier to do than to maintain documentation for the many intricacies involved with the grass cache and LOD. The information is out there for the advanced modders who want to learn how it all works, but I must say that trying to make a beginner friendly guide for this seems like a lost cause IMHO. There are simply way too many moving parts.

All the information on the Grass LOD guide is relevant to me, especially the documentation on what the NGIO settings do and how they behave.

I also use it as a reference, and it is quite valuable to me "as is". I also think it's useful to most other people in this context; however, I do get the point that it's not straight forward for beginners (and never really could be unless the beginner is a quick study with adequate, self-service technical aptitude).

After a quick review, I've made two simple edits to the first two sections of the guide that I think resolve this pretty well. The first 7 steps apply to everyone, regardless of grass LOD being intended in the end. The only piece I'm not satisfied with is Step 5 (downgrade), which only pertains to those intending to use 1.6.xxx runtime in the end. This is stated, but I would begin with this optional at Step 1 (after my 1.6.xxx build is 100% polished). It's just a nitpick though.

It's worth a look, as it's always possible I missed something.

EDIT: We could also modify the title of the page as "Grass Cache & LOD Guide", which would increase relevance via organic search for those interested in Skyrim grass cache.

[Mousetick]

On 7/14/2023 at 3:35 AM, DoubleYou said:

I think the important thing to understand here is that usage of NGIO and grass LOD are extremely advanced modding concepts that most users are not going to perform because it is time-consuming and difficult.

The information is out there for the advanced modders who want to learn how it all works, but I must say that trying to make a beginner friendly guide for this seems like a lost cause IMHO.

I agree it's extremely advanced modding. However I didn't mean the information should be beginner friendly, and I disagree it allows advanced modders to learn how it all works.

I think the published information fails to explain anything actually. It's just a long series of steps to follow blindly as if it were geared towards mindless newbies. The extremely advanced modders are smart enough to understand, so they can be given more information than simply: do this, then do that, doesn't work at the end? tough, restart from the beginning. If things were really explained, extremely advanced modders would be better equipped to troubleshoot issues or tweak things on their own. Like DynDOLOD-style documentation, but without the dry inscrutable phrasing, and with lots of pictures to illustrate.

Moreover the published information is riddled with useless noise or incorrect details.

It's doing a disservice to the intended audience, who doesn't really learn anything, or learn falsehoods.

On 7/14/2023 at 3:35 AM, DoubleYou said:

All the information on the Grass LOD guide is relevant to me, especially the documentation on what the NGIO settings do and how they behave.

Sure. Some of it is irrelevant and confusing/misleading when it comes to grass precaching, though.

Example, Step 4 of the STEP Grass LOD Guide:

UseGrassCache = True
ExtendGrassDistance = True
ExtendGrassCount = False
EnsureMaxGrassTypesPerTextureSetting = 15    ;set to max count of grass types for the grass mod. This is for Cathedral Landscapes.
OverwriteGrassDistance = 6144    ;Optional. This overrides skyrimprefs.ini.
OverwriteGrassFadeRange = 14128    ;Optional. This overrides skyrim.ini.
OverwriteMinGrassSize = 67    ;Optional. This overrides skyrim.ini.
GlobalGrassScale = 1.15    ;Grass-size multiplier. A slight increase will make grass a bit slightly taller.
OnlyLoadFromCache = True
DynDOLODGrassMode = 1

Half of this stuff above is useless and doesn't matter. It's noise. The actual settings relevant to precaching are:

# REQUIRED, Duh!
UseGrassCache = True
# Disabled. Not recommended.
ExtendGrassCount = False
# Disabled. Strongly not recommended.
SuperDenseGrass = False
# Set to max count of grass types for the grass mod (E.g. 15 is for Cathedral Landscapes).
EnsureMaxGrassTypesPerTextureSetting = 15
# Grass density. Adjust as desired. 67 is recommended.
OverwriteMinGrassSize = 67
# Grass-size multiplier. Adjust as desired. 1.15 makes grass slightly (15%) taller.
GlobalGrassScale = 1.15

Sometimes, less is more.

[z929669]

The only mandatory settings for creating the grass cache are:

UseGrassCache = True
ExtendGrassDistance = True
OnlyLoadFromCache = True

Aside from that, only grass render distance settings have no impact on grass cache behavior. Some of the others may or may not, but it's not clear in any documentation, including NGIO.

OverwriteMinGrassSize = iMinGrassSize (skyrim.ini) ... this almost certainly controls grass density of the static cached grass, so it should be noted likewise.

Similarly, GlobalGrassScale almost certainly controls the size of the static cached grass, so it should be noted likewise.

It could also be noted that grass in the loaded cell will not honor these settings unless NGIO is active. The only exceptions are the Overwrite* settings, which are part of the game and potentially overridden by NGIO but not necessary.

DY did some testing and recommendeds ExtendGrassCount=false (default in NGIO is 'true') ... and provided a full explanation in that guide that I don't think can be easily accessed on-demand from any other source.

Aside from that, the simplest conveyance of this info is to simply install NGIO and create an "NGIO - Create Grass Cache" INI override file with:

UseGrassCache = True
ExtendGrassDistance = True
ExtendGrassCount=false
OnlyLoadFromCache = True

The relevant NGIO and DynDOLOD settings under Additional Information are accurate and superior to the NGIO doc, AFAIK. That could be linked from this section. Note that DY even found that DynDOLODGrassMode will conveniently override other relevant NGIO settings to ensure things work properly without having to change them (or game INI settings) manually.

What I noticed is missing after further scrutiny is advice to disable the "NGIO - Create Grass Cache" INI override, and for LOD use, create/enable a "NGIO - Grass LOD" INI override with:

ExtendGrassCount=false
DynDOLODGrassMode=1

I think we've acknowledged that the guide can be improved to be more organized with a better flow. Someday I will do it if neither of you guys does it first. For now, it serves it's purpose adequately and conveniently, IMO.

21 hours ago, Mousetick said:

I think the published information fails to explain anything actually. It's just a long series of steps to follow blindly as if it were geared towards mindless newbies. The extremely advanced modders are smart enough to understand, so they can be given more information than simply: do this, then do that, doesn't work at the end? tough, restart from the beginning. If things were really explained, extremely advanced modders would be better equipped to troubleshoot issues or tweak things on their own. Like DynDOLOD-style documentation, but without the dry inscrutable phrasing, and with lots of pictures to illustrate.

Moreover the published information is riddled with useless noise or incorrect details.

It's doing a disservice to the intended audience, who doesn't really learn anything, or learn falsehoods.

 

If you are attributing these statements to our grass LOD guide, I couldn't disagree more with all of them.

Removing access to this guide would be the disservice.

Of one thing I'm certain: In it's current and recent-past states, this guide is essential reading to understand NGIO grass caching and the best way to configure a custom grass cache for DynDOLOD use.

Are you really saying that you didn't learn a few things from it and didn't ultimately save time juggling with your own inference because of it?

 

_______________________________________

With respect to the following, see the original Topic:

19 hours ago, MarcDwonn said:

Sorry to interrupt, but may i ask why ExtendGrassCount is not recommended? Instead, is a smaller value of OverwriteMinGrassSize better if i have too many small patches with no grass in the landscape?

I think you are seeing a game limitation or an NGIO limitation. I'm fairly certain that the best way to get better blending is to decrease your density so that everything is a bit more patchy if it bothers you. EDIT: after looking more closely, those patches are all associated with rock meshes, so my guess is that grass isn't rendered in those, since they are part of the rock models NGIO is avioding.

Also, thank you for asking this question. Per our Grass LOD Guide (and DoubleYou's research):

[Mousetick]

6 hours ago, z929669 said:

The only mandatory settings for creating the grass cache are:

[...]

Your comments suggest you don't fully understand what precaching does, what the grass cache contains, and how the precaching process differs from in-game grass rendering. I don't blame you for that lack of understanding, on the contrary, I empathize, as there is no clear information available. Which has been my point since the beginning of this discussion. Most of the information available is based on outdated 1.5.97 setups utilizing NGIO for both precaching and in-game rendering, in which case a clear distinction between precaching and in-game rendering didn't matter.

Grass Cache Fixes creates a paradigm shift and some old habits/beliefs have to be thrown out:

1. On one hand, NGIO is only used for generating grass and caching it.
2. On the other hand, Skyrim.exe (1.5.97 or 1.6.x) with GCF uses the cache created by NGIO for in-game grass rendering.
3. These are two distinct components which don't talk to each other, they don't share their configuration, the configuration of one doesn't affect the other. NGIO settings for grass generation, or rather the products thereof, are "baked" into the cache, changing the equivalent settings in Skyrim INIs for in-game rendering has no effect.
4. DynDOLOD uses the cache created by NGIO for generating grass LODs as object LODs, that part hasn't changed.

In a nutshell:

• We require 2 environments/profiles:

1. CACHE (Skyrim.exe 1.5.97 + NetScriptFramework + NGIO + GCF);
2. PLAY (Skyrim.exe 1.5.97 or 1.6.x + GCF WITHOUT NGIO).

• NGIO settings related to grass size, density, diversity are essential for precaching. They are specific to each grass mod, to user preference, and affect quality/performance. This will determine how the grass is generated and how it's baked into the cache. They can't be changed later at runtime in Skyrim INIs. This will also influence the amount/complexity of grass LODs if DynDOLOD is used.
• These settings should be changed in NGIO's own configuration, rather than CACHE's Skyrim INIs, for ease of access and to emphasize the fact they apply ONLY to NGIO's precache.
• NGIO settings related to full grass (optionally extended) distance, full grass fade distance, and grass LOD Mode are completely irrelevant for CACHE. The equivalent Skyrim INIs are also completely irrelevant for CACHE. They only pertain to in-game grass rendering, which is done by PLAY, and doesn't use NGIO.
• NGIO setting OnlyLoadFromCache is irrelevant for CACHE. NGIO never needs to read the cache in that environment, it only writes to it.

 

• Grass precaching produces a grass "coverage map" of each grass model present in a given cell, its size and positions in the cell.
• The "coverage map" is derived from plugins in the load order:
  • The landscape (LAND) record of the exterior cell, which defines, among other things, the placement of patches of land grass or underwater kelp on the ground;
  • The landscape textures (LTEX) records referenced by the landscape;
  • The grass model (GRAS) records referenced by the landscape textures.
• NGIO ensures that "there is no grass in objects". A fundamental point that seems to be lost in all the confusion.
• One cell "coverage map" is stored in one .gid file. There is one .gid file per cell in a given worldspace. For example, Tamrielx0031y-029.gid contains the grass "coverage map" of cell 31,-29 in Tamriel.
• The grass cache contains the set of all .gid files for all worldspaces used in game.
• The cache is essentially a snapshot of the grass generated in the entire game world, as if all cells were simultaneously active (infinite uGridsToLoad).
• Consequently, any consideration pertaining to rendering/fading in active cells or DynDOLOD LOD Mode is pointless on CACHE, as it has no impact on the cache.

 

• The cache can be used not only for LOD generation by DYNDOLOD, but also by PLAY at runtime. The later provides a performance optimization for grass in active cells, but also and foremost, no grass in objects. This was not possible on Skyrim 1.6.x until GCF came along.
• The benefits of the cache are useful and desirable for PLAY, whether grass LODs are generated/used or not:

1. At runtime, PLAY loads the .gid files of the active cells from the cache.
2. Since the list of grass models, their size and position is already pre-calculated in the cache, in a manner such that grass doesn't clip through objects, all PLAY has to do is to render or fade the full models.

Hope this is clear enough and it helps a little.

[DoubleYou]

I can only agree with potential removal of :

OverwriteGrassDistance = 6144
OverwriteGrassFadeRange = 14128  

...since these settings are overridden by the DynDOLODGrassMode setting. I prefer redundancy, however, because if the user fails to set the DynDOLODGrassMode, then they might be confused why their grass isn't displaying all the way. It is merely redundant, not harmful.

The reason I can't recommend removing the other config settings is the guide is for usage of NGIO + DynDOLOD Grass LOD under 1.5.97.0 first, and only meant to use Grass Cache Fixes + DynDOLOD Grass LOD under 1.6.x.x second. Removing the NGIO-only config settings would make the guide only tailored to 1.6.x.x users. The guide should be shaped to work for both setups, and this was how I had intended it after my last edits. I see now that it includes some verbiage making it confusing for NGIO 1.5.97.0 users, so I have qualified the AE-specific steps.

[z929669]

4 hours ago, Mousetick said:

Your comments suggest you don't fully understand what precaching does, what the grass cache contains, and how the precaching process differs from in-game grass rendering. I don't blame you for that lack of understanding, on the contrary, I empathize, as there is no clear information available. Which has been my point since the beginning of this discussion. Most of the information available is based on outdated 1.5.97 setups utilizing NGIO for both precaching and in-game rendering, in which case a clear distinction between precaching and in-game rendering didn't matter.

Grass Cache Fixes creates a paradigm shift and some old habits/beliefs have to be thrown out:

1. On one hand, NGIO is only used for generating grass and caching it.
2. On the other hand, Skyrim.exe (1.5.97 or 1.6.x) with GCF uses the cache created by NGIO for in-game grass rendering.
3. These are two distinct components which don't talk to each other, they don't share their configuration, the configuration of one doesn't affect the other. NGIO settings for grass generation, or rather the products thereof, are "baked" into the cache, changing the equivalent settings in Skyrim INIs for in-game rendering has no effect.
4. DynDOLOD uses the cache created by NGIO for generating grass LODs as object LODs, that part hasn't changed.

In a nutshell:

• We require 2 environments/profiles:

1. CACHE (Skyrim.exe 1.5.97 + NetScriptFramework + NGIO + GCF);
2. PLAY (Skyrim.exe 1.5.97 or 1.6.x + GCF WITHOUT NGIO).

• NGIO settings related to grass size, density, diversity are essential for precaching. They are specific to each grass mod, to user preference, and affect quality/performance. This will determine how the grass is generated and how it's baked into the cache. They can't be changed later at runtime in Skyrim INIs. This will also influence the amount/complexity of grass LODs if DynDOLOD is used.
• These settings should be changed in NGIO's own configuration, rather than CACHE's Skyrim INIs, for ease of access and to emphasize the fact they apply ONLY to NGIO's precache.
• NGIO settings related to full grass (optionally extended) distance, full grass fade distance, and grass LOD Mode are completely irrelevant for CACHE. The equivalent Skyrim INIs are also completely irrelevant for CACHE. They only pertain to in-game grass rendering, which is done by PLAY, and doesn't use NGIO.
• NGIO setting OnlyLoadFromCache is irrelevant for CACHE. NGIO never needs to read the cache in that environment, it only writes to it.

 

• Grass precaching produces a grass "coverage map" of each grass model present in a given cell, its size and positions in the cell.
• The "coverage map" is derived from plugins in the load order:
  • The landscape (LAND) record of the exterior cell, which defines, among other things, the placement of patches of land grass or underwater kelp on the ground;
  • The landscape textures (LTEX) records referenced by the landscape;
  • The grass model (GRAS) records referenced by the landscape textures.
• NGIO ensures that "there is no grass in objects". A fundamental point that seems to be lost in all the confusion.
• One cell "coverage map" is stored in one .gid file. There is one .gid file per cell in a given worldspace. For example, Tamrielx0031y-029.gid contains the grass "coverage map" of cell 31,-29 in Tamriel.
• The grass cache contains the set of all .gid files for all worldspaces used in game.
• The cache is essentially a snapshot of the grass generated in the entire game world, as if all cells were simultaneously active (infinite uGridsToLoad).
• Consequently, any consideration pertaining to rendering/fading in active cells or DynDOLOD LOD Mode is pointless on CACHE, as it has no impact on the cache.

 

• The cache can be used not only for LOD generation by DYNDOLOD, but also by PLAY at runtime. The later provides a performance optimization for grass in active cells, but also and foremost, no grass in objects. This was not possible on Skyrim 1.6.x until GCF came along.
• The benefits of the cache are useful and desirable for PLAY, whether grass LODs are generated/used or not:

1. At runtime, PLAY loads the .gid files of the active cells from the cache.
2. Since the list of grass models, their size and position is already pre-calculated in the cache, in a manner such that grass doesn't clip through objects, all PLAY has to do is to render or fade the full models.

Hope this is clear enough and it helps a little.

No, I understand the conceptual differences quite well. I don't feel like you really read my last post where I tried to emphasize the nature of a static custom grass cache, generically speaking.

The grass cache, by definition, is static and governed by the grass mod (plugin) itself as well as its interaction with other plugins in the LO. I get what you are saying. I agree with it and also agree that the game/NGIO distance settings effectively dictate rendering of static grass from the cache without ability to dynamically impact grass not loaded in the active cell range. Only NGIO can do that.

I won't pretend to know all the details of the plugin-level intricacies ... not because I'm unable to comprehend them but because I will not retain those details in my mind, so I care not to implant them at any given time. I have too many other things to do, and my memory just doesn't work like yours and DY's. I think intuitively and conceptually, and I intuitively and conceptually grasp the paradigm differences between use of grass cache and LOD in the different game runtimes w/wo the presence of NGIO (which is the key difference here: NGIO installed and running during PLAY, or not). You could run 1.5.97 in the same way as 1.6.xxx, but why bother when you can run NGIO and gain it's benefits making loaded grass behave under the same constraints the cache was generated (a snapshot of each loaded cell governed by NGIO and cast as a static rendition in the distance). I'm a reductionist.

I've agreed with you multiple times that the guide could be improved.

I emphatically disagree with you that the guide, in it's current and original states, is doing a "disservice to the community" OR that it has "incorrect details" or "falsehoods". It has a bit of redundancy, fails to clearly delineate use for cache benefits alone vs LOD (although that has been resolved for the most part, IMO), lacks intuitive 'flow', and fails to explain things to the level you just did (although DY has added lots of technical stuff that conveys much of this, albeit it's a bit disjointed and difficult to digest). This detail is simply not needed to achieve the desired result in either runtime. The guide has always been beneficial and has always provided information in one place that is not available anywhere else. There's execution and understanding. We're focusing on execution (i.e., "Quick Start") rather than understanding (i.e., "Additional Information"). This contributes to it being a bit disjointed as you so clearly reiterate.

You never answered my question, BTW ... Are you really saying that you didn't learn a few things from it and didn't ultimately save time juggling with your own inference because of it? (i.e., if you can admit that, it was actually of benefit to you). I think your argument is going a bit too far in support of itself is all. In so doing, you are not allowing yourself the ability to grant some quarter here, since it would soften your point (I assume).

I'm in agreement with DY is all. Only those two distance settings are 100% redundant, but they align with our recommendations regardless of the game runtime, and I think they belong there for the sake of consistency of our recommendations for rendering grass with or without DynDOLOD (in either runtime env). I agree that we should support both runtimes. It has been improved from your and other previous criticisms but could still use improvement. Again, this takes careful thought and time, which are in limited supply with all the other priorities on this site and in RL. I would love it if you contributed. It is a wiki after all, and you have ability to edit. Copy/paste it to your user page if you want and change it as you see fit. I've no doubt it will be beneficial in the end.

If I've stated any falsehoods or misinformation here, do point them out (preferably with specificity rather than as fodder to make your point again).

Rather than continued debate to reiterate points clearly made, I think it would be more productive to act.

EDIT: I see DY has been spurred to address some of the issues pointed out ... progress

[Mousetick]

3 hours ago, DoubleYou said:

The reason I can't recommend removing the other config settings is the guide is for usage of NGIO + DynDOLOD Grass LOD under 1.5.97.0 first, and only meant to use Grass Cache Fixes + DynDOLOD Grass LOD under 1.6.x.x second. Removing the NGIO-only config settings would make the guide only tailored to 1.6.x.x users. The guide should be shaped to work for both setups, and this was how I had intended it after my last edits. I see now that it includes some verbiage making it confusing for NGIO 1.5.97.0 users, so I have qualified the AE-specific steps.

Is there a particularly strong reason you wish to continue supporting 1.5.97 users in such a way?

As I previously said in my lengthy expose, GCF creates a new paradigm. This is the opportunity to let go of all the legacy and think outside the box!

I'm suggesting to streamline the workflow and processes so that they are identical on both 1.5.97 and 1.6.x, all thanks to GCF. This was subtly implied in my prerequisite environments:

Quote

We require 2 environments/profiles:

1. CACHE (Skyrim.exe 1.5.97 + NetScriptFramework + NGIO + GCF);
2. PLAY (Skyrim.exe 1.5.97 or 1.6.x + GCF WITHOUT NGIO).

But the idea was not clearly conveyed. So please allow me to elaborate with this crude graph:

It's exactly the same whether PLAY is running 1.5.97 or 1.6.x.

Benefits:

• Streamlined and simplified Guide, one text version, same procedures, common to all PLAY users.
• No more special-cases for 1.5.97 users using NGIO at runtime. This configuration is no longer documented/supported.
• Ability for 1.5.97 or 1.6.x players equally to use 3rd-party pre-generated caches (skipping the trouble of setting up CACHE or skipping the NGIO learning curve altogether).
• More clarity for users.
• Easier to maintain for STEP.

Disadvantages

• 1.5.97 players can no longer use NGIO ExtendGrassDistance=True or DynDOLODGrassMode=2.

As it is the Guide is riddled with special cases, every few paragraphs: if you're using 1.5.97 then this, if you're using 1.6.x then that. It's an unwieldy mess. Sorry.

Does preventing the loss of ExtendGrassDistance warrant maintaining a special workflow and documentation for the very very small minority of users who might use it? To the detriment of the majority of users who don't need all the irrelevant "noise"? I don't think so, but it's your call.

Thanks for reading.

[Mousetick]

23 minutes ago, z929669 said:

You never answered my question, BTW ... Are you really saying that you didn't learn a few things from it and didn't ultimately save time juggling with your own inference because of it? (i.e., if you can admit that, it was actually of benefit to you). I think your argument is going a bit too far in support of itself is all. In so doing, you are not allowing yourself the ability to grant some quarter here, since it would soften your point (I assume).

Sorry for not answering. I did learn a lot from the guide back when it was 1.5.97 only and 1.5.97 all the way. It helped a lot and I'm grateful for that. Thank you.

I've looked at it on occasion, after 1.6.x broke everything, and after GCF became a thing. And I've commented on what I felt were deficiencies or shortcomings in other topics. But I've not used it or learned anything from it since I first used it with 1.5.97.

[DoubleYou]

10 minutes ago, Mousetick said:

Is there a particularly strong reason you wish to continue supporting 1.5.97 users in such a way?

As I previously said in my lengthy expose, GCF creates a new paradigm. This is the opportunity to let go of all the legacy and think outside the box!

I'm suggesting to streamline the workflow and processes so that they are identical on both 1.5.97 and 1.6.x, all thanks to GCF. This was subtly implied in my prerequisite environments:

But the idea was not clearly conveyed. So please allow me to elaborate with this crude graph:

It's exactly the same whether PLAY is running 1.5.97 or 1.6.x.

Benefits:

• Streamlined and simplified Guide, one text version, same procedures, common to all PLAY users.
• No more special-cases for 1.5.97 users using NGIO at runtime. This configuration is no longer documented/supported.
• More clarity for users.
• Easier to maintain for STEP.

Disadvantages

• 1.5.97 players can no longer use NGIO ExtendGrassDistance=True or DynDOLODGrassMode=2.

As it is the Guide is riddled with special cases, every few paragraphs: if you're using 1.5.97 then this, if you're using 1.6.x then that. It's an unwieldy mess. Sorry.

Does preventing the loss of ExtendGrassDistance warrant maintaining a special workflow and documentation for the very very small minority of users who might use it? To the detriment of the majority of users who don't need all the irrelevant "noise"? I don't think so, but it's your call.

Thanks for reading.

I see how you can do that, but I feel the disadvantage of not supporting usage of DynDOLODGrassMode=2 is a major one. Using NGIO with DynDOLODGrassMode=2 provides the best visuals for 1.5.97.0 users, because it is very difficult to get the grass LOD to match the full grass. It doesn't matter near as much if the grass LOD is a little off if it is going out to effective uGridsToLoad of 9 or 11. It is only for performance constraints that my testing indicated it is better to use mode 1 and grass LOD instead, but that may not be true for all grass mods.

I like the graphic though. Perhaps I should make a similar graphic to illustrate the workflow more simply as a basic gist to help people understand.

[Mousetick]

1 hour ago, z929669 said:

I would love it if you contributed. It is a wiki after all, and you have ability to edit. Copy/paste it to your user page if you want and change it as you see fit. I've no doubt it will be beneficial in the end.

If I've stated any falsehoods or misinformation here, do point them out (preferably with specificity rather than as fodder to make your point again).

I do not wish to contribute to or edit the Guide in its current form. I've stated the reasons why I dislike it, largely enough already.

1 hour ago, z929669 said:

Rather than continued debate to reiterate points clearly made, I think it would be more productive to act.

My contributions to explain, educate on the subject and attempts to simplify it are contained within my posts in this discussion. You can incorporate bits of them into the Guide if you like and you think they're worth anything.

Considering that DY does not agree that streamlining and merging the 1.5.97/1.6.x instructions into a single common workflow is a good idea, I see no point in pursuing the discussion.

No hard feelings, though. Cheers

[z929669]

Moved relevant posts to this topic

[Mousetick]

I'd like to add some clarification to my previous post as I feel it was too curt and not constructive.

I don't like the guide in its current form in the sense that it's hard to read and it makes my head spin. It has no structure to speak of, and contains too much nitty-gritty verbiage owing to its lack of focus and trying to cover different subject matters altogether, even though they have actually very little in common.

• Precaching is a task unto itself, not tied in any way to LODs, and has no place buried inside a Grass LOD guide. It needs its own, separate wiki.
• The Grass LOD guide can simply begin with "Requires a NGIO grass cache matching the load order", skip all the precaching and NGIO-specific stuff, referring to the other wiki(s) as needed, and focus exclusively on Grass LODs with DynDOLOD.
• NGIO in-game rendering features and setup for full grass have no bearing on NGIO Precaching, and they concern an increasingly "niche" user base. They have no place mixed in with everything else inside a Grass LOD guide, or an hypothetical Precaching guide if it existed. They too, need their own, separate wiki.

This bit here for example:

Quote

NGIO 1.5.97.0 users only - These settings control the distance that grass is rendered using NGIO. This does not apply to AE users. They do NOT affect the cache, and can be modified at any time before or after grass cache generation. Do note that if you change DynDOLODGrassMode, you should also change the corresponding DynDOLOD Grass Mode in DynDOLOD and regenerate DynDOLOD object LOD. The following are recommended for use with DynDOLOD grass LOD using Mode 1.

OverwriteGrassDistance = 6144    ;Optional. This overrides SkyrimPrefs.ini. This will be overridden when DynDOLODGrassMode is not 0.
OverwriteGrassFadeRange = 14128    ;Optional. This overrides Skyrim.ini. This will be overridden when DynDOLODGrassMode is not 0.
DynDOLODGrassMode = 1    ;Consider using 0 instead of mode 1 when combined with the grass fade distance and range settings above. This may provide better performance.

What does this have to do with Grass LODs or Precaching? What does it affect regarding the generation of the cache or Grass LODs? Nothing...

The recent edits attempting to clarify certain points actually make things less clear and too verbose, in my view. They wouldn't be needed if the guide focused on a single subject matter. Which is why I don't wish to add my own edits or contributions, as I feel it would make things even worse. This paragraph for example is particularly puzzling:

Quote

As noted previously, while grass LOD is the main goal for most people, the benefits of having a custom grass cache extend to everyone running either 1.5.97 or 1.6.xxx runtime versions of the game and not just DynDOLOD users. Failure to do so will cause the grass cache to fail to generate.

 

---

 

In the "Big picture" diagram I posted above, the components and workflow phases are entirely separate. The only dependency that exists between them is the little arrow that connects them, which is basically shared "data", as opposed to shared function. Strictly speaking, they're not inter-dependent: they function and accomplish their work separately and autonomously.

The documentation should naturally reflect this architecture. It's more intuitive, it makes sense, it helps to understand the concepts. It also helps the writer, who can focus on one topic without polluting it with irrelevant considerations and details. If the documentation is clouded with irrelevant verbiage and mixes together unrelated concepts/functions, it's confusing to both the writer and readers.

Lastly, the documentation should focus on the most common scenarios for the majority of users. Special cases can be relegated to appendices - instead of being front and center, interspersed with the main text, which interrupts the flow and causes mental overload. For example, the split between 1.5.97 and 1.6.x players is only necessary because of one NGIO feature (ExtendGrassDistance=True) which "might" be used by a few and is not even recommended by DY. The special corner case is dictating that the documentation be overly complicated. I think this is backwards.

All the separate wikis could be linked from a "Grass Portal" page giving an overview of the main components, processes, and scenarios. Users can pick and choose which topic to drill into based on their needs. An AE user who downloaded a 3rd-party grass cache can go to the Grass LOD wiki and not be inundated with irrelevant stuff. An AE user who wishes to generate their own cache can go to the Precaching wiki and not be inundated with irrelevant NGIO in-game rendering stuff. A 1.5.97 user who wishes to use NGIO for in-game rendering can go to the NGIO wiki without being inundated with irrelevant LOD stuff. And so on, and so forth...

--

By the way, the current Guide has this:

Quote

Step 4: Configure NGIO INI

Ensure the following settings are set in GrassControl.config.txt:

UseGrassCache = True
ExtendGrassDistance = True
OnlyLoadFromCache = True

ExtendGrassDistance = True Is this intended? This is inconsistent with the remainder of the guide and the other NGIO settings shown, which assume and/or recommend False, along with DynDOLOD Mode 1 when generating LODs.

--

In closing: the discussion of advanced topics does not preclude - or exempt from - structuration, focus, and clarity. It needs them even more if the goal is to teach and explain to others.

Hope this helps. Thanks for reading.

[Mousetick]

Updated flowchart to be more correct:

Attached is SVG version. Reuse and edit as you wish.

GCF Workflow.svg

[DoubleYou]

Does anyone know if the Seasonal Grass cache feature of Seasons of Skyrim only works with NGIO or not? I have a commenter asking this, and I honestly don't even know, as I disabled grass cache when I tested Seasons, due to it not being supported at all at the time.

[soupdragon]

Well I have a new problem with NGIO grass generation it generates just fine except all the .cgid files are empty just 1kb in size the entire cache about 9mb. Of course theres no grass ingame because theres no valid data. Its a new one for sure just leaving this here incase anyone has the same issue and figured out why its happening because I'm baffled.