Jump to content

Trouble understanding grass and LOD generation with additional mods to STEP


Recommended Posts

It depends what you meant by "Everything crashed". If the whole system went down, including Linux, requiring a reboot to recover, that's not expected :)

What is expected is that SkyrimSE.exe may crash several times during the cache generation process. But only SkyrimSE.exe. Everything else should stay up and running normally, including MO.

In any case, NGIO writes a file PrecacheGrass.txt in the game directory (alongside SkyrimSE.exe) where it keeps track of its progress. If this file exists, and you restart Skyrim, NGIO will resume the cache generation from where it left off at the time of the crash. This can be repeated until all exterior cells of all applicable worldspaces have been processed, at which point NGIO removes that file, indicating that grass precaching has been successfully completed.

Link to comment
Share on other sites

Linux stayed up. I rarely get crashes, even when trying to break something. The Windows VM I eventually setup as Mod Organizer, through Proton, really didn't like rerunning a vfs every time Skyrim crashed. I got better results in the VM, Skyrim restarted without issues as expected, so I thought it was good to go. After I took a quick nap, I checked on it, things still seemed to be moving along, then Skyrim crashed, MO closed. I didn't reallyf eel like starting all over after tying my computer up for 10 hours. I gave the VM all of my cores when it came time to start pre-caching. 4 cores may not be enough, especially 8 year old ones XD

I'll start it up again and see what happens.

Link to comment
Share on other sites

Also, typically it doesn't take too very long to generate grass cache. Two things that can cause issues are if you are using the AE Skyrim - Interface.bsa instead of the SSE one, and if you have ExtendGrassCount = True in NGIO config. Ensure that ExtendGrassCount = False and use the Skyrim - Interface.bsa from SSE

Link to comment
Share on other sites

3 hours ago, James_Richards said:

It will remember where it left off? Even reopening MO? When I said everything crashed, Mod Organizer also shut down.

MO shouldn't crash. DY means that the pregen operation often crashes and gracefully recovers, but if MO also crashes, then it's a wash.

My guess is that your long generation times and pregen crash are related to graphics driver issues or related software on your system. It may be related to the post the other Linux user mentioned on the other topic where he/she used a utility to configure DLLs.

Link to comment
Share on other sites

Well, it is currently running again. I need to get to sleep anyway for phone interview in the morning. I setup QEMU a little differently this time, and some of the optimizations I found will hopefully help, along with proper BSA.

The only driver issues at this point will be virtio graphics for virtual machine through QEMU. I decided to give that a shot as I can almost run QEMU as a close to a type 1 hypervisor. CPU gets passed right on through, but like VMWare and VirtualBox, QEMU still hasn't gotten to GPU passthrough.

If I could run Windows 10 as a live OS, I would do that. But Microsoft sucks. If I reeeeeally want this over some of the graphical loss with not using the grass cache for STEP 2.2.0, I found an M.2 drive with Windows 10 on it. I can swap it out, but that means taking apart a mini-ITX computer, the SSD slot is on the underside of the board and my case doesn't have a removable backplane, it is one of those Silverstone HTPC cases.

Link to comment
Share on other sites

I managed to get the cache done. I turned off every mod except Elysium Estate and any of the locations changed by mods form STEP.

I noticed the grass files are *.cgid.
The STEP grass patch has in the BSA *.gid files.

I take it the cache i have now supersedes this patch and it should be disabled compete;y? I should also adjust the DynDOLOD_SSE.ini line "GrassGID=gid" back to cgid since that is the extension/format of the files I now have?

 

Edited by James_Richards
Link to comment
Share on other sites

6 hours ago, James_Richards said:

I managed to get the cache done. I turned off every mod except Elysium Estate and any of the locations changed by mods form STEP.

I noticed the grass files are *.cgid.
The STEP grass patch has in the BSA *.gid files.

I take it the cache i have now supersedes this patch and it should be disabled compete;y? I should also adjust the DynDOLOD_SSE.ini line "GrassGID=gid" back to cgid since that is the extension/format of the files I now have?

 

As explained in the Grass LOD guide, you should rename your *.cgid to *.gid, and use Grass Cache Fixes (should be installed under AE already). If running Step, you can also package into BSA if you want the Step Patch - Conflict Resolution.bsa to load per the guide.

Link to comment
Share on other sites

Unless it is assumed that I should be renaming something, the guide states:

================================================================

Naming convention

Grass cache files are named like this: <worldspace>x<x cell coordinates padded to 4 characters with 0>y<y cell coordinates padded to 4 characters with 0>.gid. So if a grass cache file is named tamrielx-047y0038.gid, that means it applies to Tamriel <-47, 38>. No Grass In Objects renames the file extension to .cgid in order to bypass the erroneous grass cache files in Skyrim - Misc.bsa.
================================================================

This is the only mention of an extension and originally had me thinking it should stay as cgid to "in order to bypass the erroneous grass cache files in Skyrim - Misc.bsa.", which I thought was what we wanted to do. Since I was unsure, I asked.

Thank you for the heads up! Integrating it all now.

Link to comment
Share on other sites

1 hour ago, James_Richards said:

Unless it is assumed that I should be renaming something, the guide states:

================================================================

Naming convention

Grass cache files are named like this: <worldspace>x<x cell coordinates padded to 4 characters with 0>y<y cell coordinates padded to 4 characters with 0>.gid. So if a grass cache file is named tamrielx-047y0038.gid, that means it applies to Tamriel <-47, 38>. No Grass In Objects renames the file extension to .cgid in order to bypass the erroneous grass cache files in Skyrim - Misc.bsa.
================================================================

This is the only mention of an extension and originally had me thinking it should stay as cgid to "in order to bypass the erroneous grass cache files in Skyrim - Misc.bsa.", which I thought was what we wanted to do. Since I was unsure, I asked.

Thank you for the heads up! Integrating it all now.

Yeah. That's really confusing, and I recall scratching my head over it. @DoubleYou wrote it with high tek language maybe per meh321. See Step 2 of Grass Cache Fixes mod for simpler instructions. That mod is included in our LOD guide, so the instructions for GID are a bit indirect.

Link to comment
Share on other sites

Since STEP  for Skyrim (Oldrim), I realized I have been skimming too much of the mod instructions and the guide. I know it is bad practice. After a couple versions of the guide, I just started assuming too many things. I have been going back and re-reading every sentence. So. I think the actual modding aspect will get better. The technical aspect going through Proton might still be a problem, but so far, I have found resolutions for all the tools. I am generating DynDOLOD now and will be able to test if there is still floating grasses around Elysium Estate or not. If I did everything right, there shouldn't be.

I thank you all for the patience.

Link to comment
Share on other sites

1 minute ago, James_Richards said:

Since STEP  for Skyrim (Oldrim), I realized I have been skimming too much of the mod instructions and the guide. I know it is bad practice. After a couple versions of the guide, I just started assuming too many things. I have been going back and re-reading every sentence. So. I think the actual modding aspect will get better. The technical aspect going through Proton might still be a problem, but so far, I have found resolutions for all the tools. I am generating DynDOLOD now and will be able to test if there is still floating grasses around Elysium Estate or not. If I did everything right, there shouldn't be.

I thank you all for the patience.

You don't want the LE guide. You want the 2.0.0 SE guide (pre AE SSE). Unless you DO want to run LE. In that case, you talking about lots of differences with everything, including DynDOLOD.

I would use the 2.2.0 SE guide and simply reference the Extender mods from 2.0.0 + NGIO. There's only about 20-ish mods that need to be downgraded, I think. you can use this to assist.

Link to comment
Share on other sites

Explanation 1:

  • NGIO with 1.5.97:

NGIO completely bypasses the engine grass generation and caching. It has its own configuration in a separate configuration file. It uses its own cache files if precaching is used, with a different .cgid extension than vanilla's .gid. This complete separation ensures NGIO works as intended without conflict or interference with vanilla grass generation or precache, which is borked in several ways, or with users' incorrect Skyrim INI grass configuration.

  • 1.6.x without NGIO:

NGIO is not possible with 1.6.x. However its grass precache files can be used by the vanilla 1.6.x engine, as they use the same data format and naming convention as vanilla, albeit with some restrictions on NGIO features which must not be used when precaching. The trick is simply to change the NGIO-specific .cgid file extension to vanilla .gid, and overwrite vanilla .gid files.

DynDOLOD assumes precache files have .cgid extension by default for generating grass LODs, but it can be changed in its configuration.

Renaming the precache file extension from .cgid to .gid is only necessary if the grass precache is to be used for rendering grass in near/active cells. If it's to be used only for Grass LODs, renaming is not necessary since DynDOLOD handles .cgid by default.

Explanation 2:

  • The current STEP Grass LOD Guide stops short of explaining how to use the NGIO grass precache with 1.6.x for rendering grass in near/active cells. It's only focused on using the NGIO grass precache for the purpose of generating grass LODs with DynDOLOD.

I'd suggest at least mentioning the existence of Grass Cache Fixes and pointing to its instructions would be helpful.

Tangential Note:

I don't understand why the STEP SSE Guide instructs users to install the STEP Grass patch only "when grass LOD will be used". The NGIO precache would benefit all users in all scenarios, whether they use grass LOD or not. When installed along with the appropriate INI configuration, the grass precache is used by the vanilla 1.6.x engine for rendering grass in near/active cells. It doesn't make sense that this feature/optimization is used only when Grass LOD is also used, as the latter depends on the former, but not the other way around.

It seems both the SSE Guide and Grass LOD guides completely ignore the technical basis given by Grass Cache Fixes, which are made by no other than DY.

Puzzling. What is the rationale for this?

Link to comment
Share on other sites

  

Mmmmm Tasty knowledges.

There are some moments where I prefer things to be explained to me on a basic level. I have been modding Skyrim for a while, got my feet wet with modding Oblivion once upon a time ago. Or have someone tell me how they did it over reading a guide. Often, a bit more info not present in the guide helps.

2 hours ago, Mousetick said:

I don't understand why the STEP SSE Guide instructs users to install the STEP Grass patch only "when grass LOD will be used". The NGIO precache would benefit all users in all scenarios, whether they use grass LOD or not. When installed along with the appropriate INI configuration, the grass precache is used by the vanilla 1.6.x engine for rendering grass in near/active cells. It doesn't make sense that this feature/optimization is used only when Grass LOD is also used, as the latter depends on the former, but not the other way around.

It seems both the SSE Guide and Grass LOD guides completely ignore the technical basis given by Grass Cache Fixes, which are made by no other than DY.

Puzzling. What is the rationale for this?

I am guessing to keep the guides separated, in case STEP goes in a different direction, or through broader testing find something not working as intended. Someone might work out a way to do things differently with LOD, grass and textures and such. STEP has, in the past, done things differently than a mod author suggested to appeal to a broader user group. Case in point, I am willing to bet the majority of users who are installing and using step have more up to date CPUs and/or beefier GPUs than what I have. My whole plan was to follow an update cycle, but since I put this system together, Intel and board manufacturers raised prices, life in general started costing more and I couldn't justify buying a new socket platform all of a sudden. If I had stuck with AMD, I would have had a more fighting chance as they keep their sockets longer. I shouldn't have switched. I also wasn't planning on a lot of other things.

Or try to make the guide as easy as possible to implemented through "cookie cutter" explanations so as to allow the newer modders or less adept to follow the guide and have a pleasant experience. I remember the first time I used STEP years ago. It felt daunting at first, but following it to a "T" I managed to have great modded experience, read some more and started understanding enough to make tweaks to make it my own and even more enjoyable.

Edited by James_Richards
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.