Fallout 4 Optimization and Performance Systems Explained

[NeinGaming]

On 8/13/2024 at 5:14 PM, kkkenny1577 said:

Got pointed to this forum when I googled

Fallout4!flexMakeShapeFlags

Which is the final command before  ntdll crashes with a heap error using windbg to decode the DMP file-

 

My first thought is, are you using an NVIDIA card and have weapon debris (which uses something called NVIDIA FleX) turned on?

https://www.pcgamesn.com/fallout-4/broken-nvidia-rtx-gpus

If yes, you can try if this fixes it:

https://www.nexusmods.com/fallout4/mods/48078

[kkkenny1577]

Wish it was that simple but no I use AMD originally a RX580 and now a 7800XT.

A similar post to Buffout4 noted from others that this has becoming more frequent with no obvious solution or reason. It basically means regular saves every 5 minutes and my own saves before doing anything. Massive pain in the ass

[kkkenny1577]

Potential fix found scrolling through Nexus' collections for Fallout 4 - the collection A StoryWealth organized by Exoclyps.

Figured these must run without errors and went through his setup - the main point was he increased his pagefile sys to 20gb (i have 64gb ram) as he states:

"Why Increase Pagefile Size?

Stability: Large mod collections consume a lot of RAM. Increasing the pagefile size provides additional virtual memory, helping to prevent crashes.

Performance: A larger pagefile can help with smoother transitions between loading different game assets, especially in memory-intensive scenarios."

Seems to work plus I later loaded x-cell to see if it helps and had no issues. Still get odd freeze loading to new area but game is infinitely more playable

[NeinGaming]

Does the pagefile actually ever get used, when you have 64GB RAM? I have 24 GB and the answer is no, unless I do something really pathological or have a memory leak (but then having a big pagefile just extends the pain and makes it so much slower, so in that case I would prefer a speedy crash ^^)

As a tangent, I added this to my [Papyrus] section, it's NOT recommended but I got too script happy and didn't WANT to restrict myself to keep papyrus from dumping the stack, so I increased it to ~15GB and didn't have a single stack dump since:

iMaxAllocatedMemoryBytes=15000000

Don't do this if you just use normal mods! But if you experiment with scripting and get stack dumps and generally are reckless, it does have an effect, FWIW.

Edited September 25 by NeinGaming

[kkkenny1577]

I agree probably shouldn't work but my significant number of random crashes with no report dropped to zero and I'm back to occasional ctd's that Buffout4 will report on. I just file it under "cause it works" 

[Qrsr]

Hi,

today i noticed that playing around with Room Bounds and Portals can make a cell less performance affective than expected compared to having it be forced to render based on PreCombines and PreVis.

1. My hardware was forced to use only the iGPU to really see even the slightest differences.
2. Then i used AndrewStation01 a larger Subway interior cell and disabled most of the lighting (LIGH)
3. I then tested my setup and besides finding some broken Portals and Room Bounds in the vanilla game (which i fixed) the setup worked pretty solid already.
4. Later i optimized some other lighting and didnt realise i made a mistake, i broke or changed one of the [Placed Object] (which lead to the research below)
5. The Strange thing however, the interior ran more solid, FPS were more stable and higher compared to the PreVis, Precombined setup, i started to track down if it was caused by the latest changes in FO4Edit and it was ...
6. I was very confused ....

I know that the Portal and Room Bound story goes back to FO3 which "totally" rely on it. In FO4 and else the game relies more on Precombines and PreVis (please correct me if im wrong) although an interior cell almost all the time uses both (while there are alot of broken Portals in FO4, hihi). I know how Portals work but always thought why would one use Portals if one already uses a Precombined mesh of many statics. Thats a paradoxon in itself.

Soooo... i dont see anything bad in deleting the Precombined and Previs references via FO4Edit and let most of the interiors render in real time (faster). I mean its by 30 up to 50% faster/better.

But could having the interior or else cells render in real time cause more save bloat? Or even get rid of it since the game runs textures, meshes, and else on/in real time???

Since im doing my tests on an iGPU i instantly see a differene in FPS. Im very curious what you guys think.

• EDIT1: I found that having only the objects of interest removed/deleted from the PreVis Reference Index and Combined Reference Index also has very good results BUT fear, that even objects Fallout4Edit is unable to track or mark as [Placed Object] affect the Precombined and PreVis reference mesh and textures in a bad way. This can be avoided by removing those objects from both indexes by hand. It caused instantly higher and more stable FPS during testing but i wasnt pleased still since purging both indexes is much more stable still. I didnt study the PJMail scripts as of now so my research might be obsolete or not new already.
• EDIT2: To better show the current progress see the image below which is true for the PreVis Reference Index:
  Spoiler

  

• Almost none of them are Combined, yet these references influence heavily the performance in a cell, removing the reference will increase the performance if any mod is overriding or touching these. Deleting the PreVis increases performance and decreases micro-stuttering already.
• Interesting in this regard, any mod, be it a variable override (scripted) solution or a fixed, ESP/ESL/ESM solution will affect the performance eventhough none of these objects are officially [Bracketed], tracked as "Combined" in f.ex. FO4Edit.

Kind regards

[PJMail]

Combined objects are ONLY those in the XCRI - not necessarily just those bracketed. Only refs in the same mod will be bracketed, but XCRI can contain combined refs from other mods.

Does your image only show XCRI or is it XPRI? Both are involved in the optimisation, so it is important to be clear. Also in your tests you should always do TPC to verify you have not accidentally disabled previs, which would invalidate your results.

Very interested in your results. What makes you think roombounds and portals operate even if previs is working? Dogma is that it's one or the other...

[Qrsr]

Quote

Does your image only show XCRI or is it XPRI? Both are involved in the optimisation, so it is important to be clear. Also in your tests you should always do TPC to verify you have not accidentally disabled previs, which would invalidate your results.

Like i said.

• Experiment 1, (ultimative) removed everything XPRI and XCRI = better performance (best performance, although not in all cells, which makes it even more confusing ...)
• Experiment 2, (selective) removed only the references in XPRI and XCRI which are tied to objects i want removed (better but not best performance)
• Experiment 3, (selective 2) removed only XPRI reference tree (better but not best performance)

All in all either FO4Edit is not showing all objects which should not be altered - and by that im speaking of more objects must or should be marked [Placed Object] also activators, moveable statics and else, not just statics, or the game does more in the background than expected.

I have also the impression by the time the game was packed, it was packed in numerous version states. There is alot of weird compression and formatting standards visible. Like they changed the base code and reference structure on developer level in the code itself (CreationKit.exe) multiple times. Besides, and again, i seriously have no idea why objects not marked "static" should be in the Previs or Combined eg XPRI and or XCRI reference list at all ...

 

You should know the answer if XPRI or XCRI or not already. The image shows only XPRI which you can see by the reference tree already since there is no Combined NIF reference available at all. Btw. the image references to Experiment 2.

I can verify im doing this with a no mod at all and or only the mod of interest and nothing else by the time im testing. I would not do this with a 300+ mod setup for obvious reasons

[PJMail]

XPRI references can be anything that won't move (either position, animated, or by being scraped via workshop) as it has pre-calculated occlusion information in the uvd file. Removing these from XPRI means there is no occlusion culling of them (so they are always rendered). I am surprised doing this increases FPS - but I can imagine there is very little occlusion in the confined space of an internal cell so I would have been less surprised if you said "no change".

XCRI must be static objects as they are duplicated into the precombined nif (which is like an SCOL) and then only that nif is displayed (or the part/node that is not occluded). Removing a ref from the XCRI has the same effect as with XPRI - now that reference is always rendered directly, so probably not a serious optimisation as limited occlusion in a confined space of an interior.

Still surprised FPS is improved though - you would expect 'some' performance improvement even if only a few objects are culled via occlusion. Perhaps running the test on a large interior may give a different result.

Very interesting tests you have done though!

 

[Qrsr]

I can add even more to the research now, ...but first and remember im doing it with a suppressed system in terms of GPU, im using and iGPU. Single Core with a lot of L3 cache (while RAM is very unimportant up from DDR4) ... so it perfectly comes down to the GPU which must do the rest of the s#*! ...

So to sum it up, XPRI and XCRI ... CAN but dont MUST lead to performance increase, which is very important to note first. But most of the time having it removed and or not applied at all will first increase gaming experience and lower mod size since those Combined NIFs are just easily hit the 100 MB plus mark. So no need to PreCombine or PreVis the cell USE Room Bounds and Portals !!!

Doing overrides on the same Cell Header for lighting and else and adding new references of new FormIDs (like new Lighting Templates) not part of the vanilla game lead to performance decrease (!). This is the most weird experience in the last 24 h to me ...

EnableParent especially tied to Quests CAN but dont MUST lead to performacne increase when removed ... some cells have ultra stuttering probably doomed to inproper setup of scripts, good and horrible example is CollegeSquare01. Its the worst optimized cell in the entire game btw. if you follow the hardware setup (iGPU).

All of this is very important, since eventhough it is not directly part of the PreVis and Combination procedure it will affect performance, and causes micro stuttering.