Plugins + Scripts Anti-Stutter Patch

[Ashu27]

Ashu27 submitted a new resource:

NativeGCPatcher - NativeGCPatcher

Overview
Native GC Patcher is a high-performance memory management plugin for Virt-A-Mate (VaM). It interacts directly with the game's Mono runtime to control Garbage Collection (GC), eliminating micro-stutters caused by frequent GC spikes and preventing memory overflows during long sessions.

Unlike standard script-based cleaners, this plugin runs natively via BepInEx, allowing it to "Lock" the GC when memory is safe (ensuring smooth framerates) and "Force Clean"...

Read more about this resource...

 

[trnk]

sweet baby jesus, this is awesome!

 

[falbst]

This plugin has made a huge difference; I thought something was wrong with my setup. Thank you.

 

[Tomblack]

Can this prevent the two second stutters that occur every five minutes when the heap size resets to a lower value, thanks to memory leaking plugins: like Subsurface Scattering Skin, Height Measure, etc. ?

Nevermind gonna try this first before asking.

 

[MDKSBG]

The program's memory usage is inconsistent with the memory usage read by the plugin.

 

[Ashu27]

Ashu27 updated NativeGCPatcher with a new update entry:

New Version

Optimized the code logic.

Read the rest of this update entry...

 

[VamTimbo]

Not accusing you of anything really, but coincidentally I developed nearly this exact same solution and placed it on the discord the day before you released this. Is this a re-port of my application? It looks nearly the same - but with some minor differences. I was just about to post my app this week, when I saw this - just though it was a massive coincidence since this has been a problem I've been trying to solve since 2021, even seeking help from Meshed himself but was told no solution exists... and suddenly both of us come up with it.. the same week. Seems odd... Here's a screenshot of my app.. looks oddly familiar.

 

[Ashu27]

Not accusing you of anything really, but coincidentally I developed nearly this exact same solution and placed it on the discord the day before you released this. Is this a re-port of my application? It looks nearly the same - but with some minor differences. I was just about to post my app this week, when I saw this - just though it was a massive coincidence since this has been a problem I've been trying to solve since 2021, even seeking help from Meshed himself but was told no solution exists... and suddenly both of us come up with it.. the same week. Seems odd... Here's a screenshot of my app.. looks oddly familiar.

View attachment 546995

I am also curious that there hasn't been anyone else solving this problem for so many years. I obtained reference from the functionality of the MMDX plugin. The MMDX plugin was able to disable GC during MMD playback a long time ago.

 

[VamTimbo]

I am also curious that there hasn't been anyone else solving this problem for so many years. I obtained reference from the functionality of the MMDX plugin. The MMDX plugin was able to disable GC during MMD playback a long time ago.

Wow.. so I guess just a massive coincidence. I was literally talking to @AshAuryn the day before you posted this asking for the proper way to release since it contains some executable material. I had also posted my code on the discord (and then removed it for safety reasons). Pretty weird. But either way I'm glad the issue has a solution - it was driving me crazy for years, I'd ruined many mocaps due to that annoying pause.

 

[grontz]

Since I started using the plugin, most scenes no longer load in VR because I get an error message during loading: "GC fatal error too many heap sections". Am I doing something wrong, or is the plugin incompatible with VR?

 

[Ashu27]

Since I started using the plugin, most scenes no longer load in VR because I get an error message during loading: "GC fatal error too many heap sections". Am I doing something wrong, or is the plugin incompatible with VR?

check this.https://hub.virtamate.com/threads/too-many-heap-sections.38525/#post-108657

 

[Ashu27]

Since I started using the plugin, most scenes no longer load in VR because I get an error message during loading: "GC fatal error too many heap sections". Am I doing something wrong, or is the plugin incompatible with VR?

Since you haven't provided your specific configuration and settings, I can only guess. If you have too many morphs, it will cause the heap size to increase rapidly. If you have 10000 morph parameters, they will all be loaded when loading each character to ensure real-time response to morph changes. This means that the occupation of heap size in multiplayer scenarios is devastating. And because GC is locked, it cannot automatically trigger GC to recycle heap size frequently. So when loading scenes with more than one person, your heap size is likely to be punctured.

 

[grontz]

First of all, sorry if my message came across differently than intended; English isn't my native language, and I didn't mean to offend anyone. Regarding my specs: I have a Ryzen 7800X3D, 128 GB RAM, and an RTX 3090. The scene I tried to load has two people. If I load a scene with only one person, it loads fine. I understood that the plugin is supposed to generally fix micro-stuttering. Or have I misunderstood? Is the plugin only meant for specific situations, and in my case, it doesn't work?

 

[Ashu27]

First of all, sorry if my message came across differently than intended; English isn't my native language, and I didn't mean to offend anyone. Regarding my specs: I have a Ryzen 7800X3D, 128 GB RAM, and an RTX 3090. The scene I tried to load has two people. If I load a scene with only one person, it loads fine. I understood that the plugin is supposed to generally fix micro-stuttering. Or have I misunderstood? Is the plugin only meant for specific situations, and in my case, it doesn't work?

How many pages is your character's morph?

 

[grontz]

2 - 4

 

[Ashu27]

2 - 4

I mean this

 

[grontz]

So, in total I have over 1444, but in the scene I loaded, one person has 2 pages and the other has 4 pages, or does that not matter at all and it always depends on the total number?

 

[Ashu27]

So, in total I have over 1444, but in the scene I loaded, one person has 2 pages and the other has 4 pages, or does that not matter at all and it always depends on the total number?

No, hidden morphs are not displayed here. If the author did not select 'display morph' when packaging the scene, the files in the var file will only be displayed when loading the relevant scene. But every time you load a new character, 1444+morph will be loaded instead of only when morph takes effect. Simply put, for every additional character loaded, an additional 1444+morph will be loaded. You can now try switching the mode of the GC plugin to active before loading the multiplayer scene. See if it can load normally.

 

[grontz]

My problem only occurs when I start it in VR. In desktop mode, it works fine both when the plugin isn't active and when it is. However, as soon as I try to start it in VR, the scene doesn't load and I get an error message.

 

[Ashu27]

My problem only occurs when I start it in VR. In desktop mode, it works fine both when the plugin isn't active and when it is. However, as soon as I try to start it in VR, the scene doesn't load and I get an error message.

Let me give an example to illustrate the function of my plugin.
The default GC mechanism of VAM is like a dam that frequently releases water. When the water level rises by a certain amount, the gate will be opened to release water. This can even clear the water level and avoid dam collapse (game crash) when loading a large number of morphs and scripts in a short period of time. But the cost is that every time the water is released, it will cause the game to lag.
And my plugin's plugin is like manually controlling the water release switch of a dam. Only open the gate to release water when it exceeds a specific water level and under specific circumstances. But the possible problem is that if the heap size grows too fast in a short period of time and the plugin limit is set too high, it may lead to the dam being breached (game crash) due to the inability to clean it in time.

If possible, you can first move the vast majority of .VAR to other folders and try loading a two person simple scene in an environment with only a few .VAR to see if the problem still occurs.

 

[grontz]

Ah, okay, thanks again for the detailed explanation. I think I now understand better what the plugin does. And roughly speaking, the reason it works in desktop mode is because it uses less RAM than VR mode, right?

 

[Ashu27]

Ah, okay, thanks again for the detailed explanation. I think I now understand better what the plugin does. And roughly speaking, the reason it works in desktop mode is because it uses less RAM than VR mode, right?

As a reference, my PC configuration is:
CPU：AMD R7 9700X
RAM： DDR5 6800 24G*2
GC：4070TIS

Heap Size limit:20G

I can load Produce_69 normally in VR.

The heap size limit is not necessarily the higher the better, I suggest it be between 15~20G. Even the default occupancy of Produce_69 is only around 12G.

 

[grontz]

I'll try everything again later and then try loading the same scene. Thanks for your help.

 

[octobiped]

I tested this patch for around four hours in VR and I'm amazed. A complex scene that would lag multiple times per minute (with the GC triggering at random even at small heap sizes) is now running smoothly for ten minutes at a time. I only had a single "too many heap sections" crash in those four hours, otherwise it was stable. I think this is seriously the biggest performance improvement VAM has ever received from a plugin, surpassing even turtlebackgoofy's CPU patch (I use the v12evo version of it since it's more stable than v13).

I have two recommendations on how the patch is being presented:

1 - "NativeGCPatcher" is too technical and doesn't communicate anything to the average user. A better name for it might be "Anti-Stutter Patch" or "Anti-Lag Patch", something that conveys what the improvement is more clearly.

2 - Calling it "micro-stutters" in the description is a bit generous; a micro-stutter is supposed to be barely noticeable, whereas GC spikes in VAM freeze the game for almost a whole second. As stutters go, that's massive, so I recommend just referring to them as "stutters" or "lag spikes" to accurately communicate the severity of the problem being fixed.

That's it. Thank you for this patch, it's a huge improvement, and I'm surprised to see that it's possible at all after so many years dealing with VAM's horribly unstable GC implementation.

 

[Ashu27]

I tested this patch for around four hours in VR and I'm amazed. A complex scene that would lag multiple times per minute (with the GC triggering at random even at small heap sizes) is now running smoothly for ten minutes at a time. I only had a single "too many heap sections" crash in those four hours, otherwise it was stable. I think this is seriously the biggest performance improvement VAM has ever received from a plugin, surpassing even turtlebackgoofy's CPU patch (I use the v12evo version of it since it's more stable than v13).

I have two recommendations on how the patch is being presented:

1 - "NativeGCPatcher" is too technical and doesn't communicate anything to the average user. A better name for it might be "Anti-Stutter Patch" or "Anti-Lag Patch", something that conveys what the improvement is more clearly.

2 - Calling it "micro-stutters" in the description is a bit generous; a micro-stutter is supposed to be barely noticeable, whereas GC spikes in VAM freeze the game for almost a whole second. As stutters go, that's massive, so I recommend just referring to them as "stutters" or "lag spikes" to accurately communicate the severity of the problem being fixed.

That's it. Thank you for this patch, it's a huge improvement, and I'm surprised to see that it's possible at all after so many years dealing with VAM's horribly unstable GC implementation.

Thank you for your suggestion.