• Happy Holidays Guest!

    We want to announce that we will be working at reduced staffing for the holidays. Specifically Monday the 23rd until Jan 2nd.

    This will affect approval queue times and responses to support tickets. Please adjust your plans accordingly and enjoy yourselves this holiday season!

  • Hi Guest!

    Please be aware that we have released a critical security patch for VaM. We strongly recommend updating to version 1.22.0.7 using the VaM_Updater found in your installation folder.

    Details about the security patch can be found here.
CPU Performance Patch (Up to 30% faster physics, up to 60% more FPS)

Other CPU Performance Patch (Up to 30% faster physics, up to 60% more FPS)

Anyone else's softbody physics and certain morphs get broken? The patch works well but soft physics now makes female breasts jiggle like water balloons. I'm guessing morph issue could be from another plugin or modding, but soft physics issue only happened for me after the performance patch.
 
Anyone else's softbody physics and certain morphs get broken? The patch works well but soft physics now makes female breasts jiggle like water balloons. I'm guessing morph issue could be from another plugin or modding, but soft physics issue only happened for me after the performance patch.
the jiggle happens in all versions of vam if your FPS is lower than your physics rate. It happens because deacceleration wasnt applied often enough and the breast position flew too fast and out of bounds.
 
Users who have heap related crashes: Do you have a fairly low fps in this scene? Like 0-60
Users who dont have heap related crashes: Do you have a fairly high fps in this scene? Like 150-300
I know of one user who's experiencing them in the same spots during asset loading every time, they say. They also have reduced their morphs quite a bit, as this error (prior to this patch) used to happen primarily when someone had 10,000+ morphs, and this is a known limitation of VAM, but the error persists for them, although I don't know what their total morph count is, but I could find out. Maybe this patch is touching on that and could improve it there. The scene they were using was "Nicho's 2+1 templated".

As for me, I'm not getting the error. I don't aggressively seek out morph packs, though, and I have a 14900K + RTX 3090 + 32GB.
 
I am reporting the benchmark results for my rig:

17-14700K - undervolted, not OC
64GB DDR5 (2x32GB PC5 48000) - no mod
Gigabyte 4080 - no mod
SteamVR with HTC Vive (the OG Vive, not the Pro etc)

I used the following .ini parameters for BOTH threads AND threadsVR:

computeColliders=16
skinmeshPart=16
skinmeshPartMaxPerChar=16
applyMorphs=16
applyMorphMaxPerChar=16
affinity=1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16
engineAffinity=9,11

Note that the engineAffinity is specific to my CPU whose fastest cores are 4 and 5. Your 14700K CPU "may or may not" be different. (I did NOT disable hyperthreading).
Please share your boot.cfg. "job-worker-count" should equal # of threads, so 16. Also, and turtle may correct me here, but I believe you need to reduce your parameters by the amount of threads reserved for the Unity engine, so set to 14 in your case. When you have it set to 16, that means processes are falling into the hyperthreads, which will cap efficiency at 50/50, because they are one core split into 2 and share the power equally. If you're not using something like ProcessLasso, you might really benefit from disabling HT. It's not that great when you have 8 p-cores, especially when you have twice as many e-cores. It was really great when Pentiums had 1-2 cores. If it wasn't set that way, and you change it, run your benchmark and share again, and let's see what impact that has.
 
Last edited:
Please share your boot.cfg. "job-worker-count" should equal # of threads, so 16. Also, and turtle may correct me here, but I believe you need to reduce your parameters by the amount of threads reserved for the Unity engine, so set to 14 in your case. When you have it set to 16, that means processes are falling into the hyperthreads, which will cap efficiency at 50/50, because they are one core split into 2 and share the power equally. If you're not using something like ProcessLasso, you might really benefit from disabling HT. It's not that great when you have 8 p-cores, especially when you have twice as many e-cores. It was really great when Pentiums had 1-2 cores. If it wasn't set that way, and you change it, run your benchmark and share again, and let's see what impact that has.
was it not already mandative to disable hyper-threading to get better profit from the "patch (and as I naively discovered not only from the "patch")?
 
Last edited:
As is? No editing required? Weird, I had bad fps when following this guide even when I turned ray tracing off.
when you rename the VaM_Data folder you just need to the patched Assembly-CSharp.dll into the renamed folder, so its at the same location as before you renamed the folder (ergo doing nothing)
 
Is it possible to use this patch and raytracing using this guide? https://hub.virtamate.com/resources...-only-for-nvidia-gpus-and-desktop-mode.14288/
It involves renaming the executable so I suspect it might not hook correctly like that.
Yep, I use this patch with the SOTTR.exe/SOTTR Data SSRTGI GeForce Experience overlay and it works great in desktop, so it might be something else bottlenecking your fps.

On a related matter, don't use the last two GeForce Experience driver updates as they screw with the SSRTGI overlay settings being saved. Last stable version is 546.65
 
Yep, I use this patch with the SOTTR.exe/SOTTR Data SSRTGI GeForce Experience overlay and it works great in desktop, so it might be something else bottlenecking your fps.

On a related matter, don't use the last two GeForce Experience driver updates as they screw with the SSRTGI overlay settings being saved. Last stable version is 546.65
What happens when you run it in VR?
 
any performance benefits from using sotr.exe instead of vam.exe?
Only benefit is being able to use the GeForce Experience overlays in SOTTR. I've run both vam.exe and sottr.exe with this patch in desktop and the fps etc are the same.
 
Also having the heap issue with larger scenes. I tried loading it without the patch and it loads fine. It seems that for some reason the heap is not clearing when it gets large while loading the scene using the patch.

Without Patch:
- Heap size grows to ~27 GB, automatically triggers memory optimization, falls back to ~12 GB, repeats until scene is loaded

With Patch
- Heap size grows over ~27 GB and get Fatal gc error: Too many heap sections

As a workaround using patch, you can manually trigger memory optimization in Performance 2 tab to clean up the heap when it grows big while loading the scene but pretty annoying, as you have to manually clean up the heap > 10 times during the load. Not sure if this helps diagnose the issue at all, but just what I'm seeing.

P.S. Amazing patch, thank you for your work on this!
 
any performance benefits from using sotr.exe instead of vam.exe?
Im not sure about performance. i use it only to get nvidia screenshot with alt+f1 :D it do not even work with nvidia overlay like Fake Ray tracing, i do not know why it do not work, if i run clean instal of vam it work but with 10K vars and plugins and reshade it give info that application is not supported though screenshots and recordmovie works
 
I've noticed that after few scene loads menu is not opening (ie. for person). Changing gfx-enable-native-gfx-jobs to 0 in boot.config seems to solve the problem. Anyone can confirm?
 
I've noticed that after few scene loads menu is not opening (ie. for person). Changing gfx-enable-native-gfx-jobs to 0 in boot.config seems to solve the problem. Anyone can confirm?
Mine didn't completely stop opening but it did slow down after 3 or 4 scene loads. I am going to try your suggestion.
 
I've noticed that after few scene loads menu is not opening (ie. for person). Changing gfx-enable-native-gfx-jobs to 0 in boot.config seems to solve the problem. Anyone can confirm?
Hmmm, I do get this sometimes, not too often though.
 
nah, just wondered if my beta release blocked the stable one
awww, beta is stable for me!

Is your Performance mod btw compatible with FSR mod? I.e. this

Or this fork of Vrperfkit (original is from fholger too):

So the question obviously is, that can you use these (or either of these) together with your awesome CPU Performance Patch and get maximum FPS in VaM VR mode?
 
Actually i never had it happen before. But now if i turn have soft physics on without titty magic, on certain models, the breast do act really weird, like super loose jiggle water balloons. But never seen it on any scenes past few years before the patch, no matter what fps or physics rate i applied.. Guess ill take a vid later incase its different than what you are refering to.
View attachment 344018
I'm having the exact same issue, but with the lips on some of my models.
 
Back
Top Bottom