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)

Windows Task manager has the same findings when using 1,3,5,7,9,11,13,15. Spikes on 1, 7 and to a lesser extent the other odd numbers.

View attachment 342447

1, 7 incidentally is what I use for Engine Affinity. RyzenMaster says C 01 and C 04 are my fastest, and that correlates with Turtle's numbers below. C01 = 1, C04 = 7

View attachment 342452
View attachment 342453

I'm using a AMD Ryzen 9 5950X
1 person scene I get 245 FPS
2 person scene 135 FPS
So I'm not complaining, happy with the results.

Curious, where did you get that second screenshot from?
The one where you underline Index 1 and Index 7.
 
Curious, where did you get that second screenshot from?
The one where you underline Index 1 and Index 7.
Posted by Turtle on page 21

ScreenHunter 523.jpg


It seems that some processors the numbering starts with Index 1 [C0] and others (like mine) start with Index 1 [C1]
 
Posted by Turtle on page 21

View attachment 342454

It seems that some processors the numbering starts with Index 1 [C0] and others (like mine) start Index 1 [C1]
Yeah see the problem is you and I are talking about completely different values / terminology because of exactly what I pointed out in my previous posts.

On top of that, what you claim here is simply incorrect too, look at your previous post, where you have a task manager screenshot, it CLEARLY says CPU 0 at the top.


I was referencing how WINDOWS and PROCESS LASSO calls the cores, namely:
Cpu 0, Cpu 1, Cpu 2, Cpu 3 etc.

Where
Cpu 0 = Physical core 1
Cpu 1 = Hyperthreaded/SMT core 1
cpu 2 = Physical core 2

You are simply mixing up different references to cores.

Adopt the task manager / process lasso standard as it should be.

I can make the exact same Index list for my 5600 but simple remove Index 13-16, it is effectivly pointless to look at the index, because 1 it ads another useless terminilogy into the mix that you'll never use again, and
if you have the knowledge that CPU 0 = Physical core 1 = Turtle's Affinity 1

All of this would never have existed as an "issue" if the Affinity 1 was simply called Affinity 0

It is on par with people thinking that x32 = 32bit where as it should be x86.....
 
Last edited:
Maybe so, but it still doesn't explain why using 1,3,5...etc for me lights up CPU 1,3,5...in Process Lasso and not 0,2,4...
 
Maybe so, but it still doesn't explain why using 1,3,5...etc for me lights up CPU 1,3,5...in Process Lasso and not 0,2,4...
Just for the hell of it, I figured to give you some data from my cpu:

If I use the following settings in the SkinMesh.ini
affinity=0,2,4,6,8,10
engineAffinity=0,4

Lasso reports this:
1709824652834.png


If I change it back to my default settings:
affinity=1,3,5,7,9,11
engineAffinity=1,5

Lasso reports back this:

1709824737361.png


Im unsure why in the first picture it completely ignored CPU 11 (Since affinity 10 was included, which = CPU 11), but whatever.

Point is that, the affinity values correlate correctly to how I referenced to the CPU names earlier.

I don't know what else to tell you bud.

Edit*
I see the mistake from my first picture where I use affinity 0,2,4,6,8,10
As affinity 0 simply does not exist, as it would be CPU -1

It should have been:
Affinity: 2,4,6,8,10,12 to get the desired effect I wanted to showcase.
 
Last edited:
Yep, not gonna overthink it. Vam is performing well for me with my settings whether we understand why or not. This convo was educational though, so thanks!
 
You can edit the Assembly-CSharp.dll using https://github.com/dnSpyEx/dnSpy and add the following line in DAZMorphBank.ApplyMorphsThreadedFast at the very beginning:
Code:
Debug.LogWarning((object)string.Format("[ApplyMorphsThreadedFast] _morphs.Count {0} | _touchedMorphs.Count {1}", this._morphs.Count, this._touchedMorphs.Count));
Then you see output in C:\Users\Admin\AppData\LocalLow\MeshedVR\VaM\output_log.txt (This writes a lot to file and lowers FPS ofc)
_morphs.Count is the amount of morphs that are available and were checked in vanilla vam, _touchedMorphs.Count is the amount of morphs that will be checked in the current patch. I am aware of the bug with the built-in morphs not loading at scene start.


Yes, I think so, my _morphs.Count was in the 30,000-ish. This will be fixed in VAM2.

Yeah, no I can't.

I can find DAZMorphBank.cs alright, and I can see DAZMorphBank.ApplyMorphsThreadedFast is a method, and so I tinker a bit with the options and choose "edit method C#", and then, when I compile again ... it throws three warnings that have fuck all to do with the line I just edited. Yes, I've checked the dnSpy-wiki on debugging Unity ... and now I have a much better idea of just how far out of my depth I am.

Mate, I'm more than gratefull for everything you've done for us, and I haven't made it easy for myself, believe me - but this is like trying to graduate from gliders to the bridge of the Starship Enterprise ...

Could you maybe wrap this line into a Bepin-mod or smth? Doesn't have to be pretty or accurate - I just need some crude measure more precise than "likely too many morphs"
 
Yep, not gonna overthink it. Vam is performing well for me with my settings whether we understand why or not. This convo was educational though, so thanks!
I agree, kinda crazy how many loops we need to go through just to improve performance in VAM... hope VAM 2 performs a lot better or has built in DLSS or equivalent
 
Yeah, no I can't.

I can find DAZMorphBank.cs alright, and I can see DAZMorphBank.ApplyMorphsThreadedFast is a method, and so I tinker a bit with the options and choose "edit method C#", and then, when I compile again ... it throws three warnings that have fuck all to do with the line I just edited. Yes, I've checked the dnSpy-wiki on debugging Unity ... and now I have a much better idea of just how far out of my depth I am.

Mate, I'm more than gratefull for everything you've done for us, and I haven't made it easy for myself, believe me - but this is like trying to graduate from gliders to the bridge of the Starship Enterprise ...

Could you maybe wrap this line into a Bepin-mod or smth? Doesn't have to be pretty or accurate - I just need some crude measure more precise than "likely too many morphs"
the changes arent possible in a bepinex mod, I tried
 
I really need some help figuring this out, I have a i7 4790 non k, its i believe quadcore eight threads, if someone could help me that would be great
 
the changes arent possible in a bepinex mod, I tried

HolyShit! It worked!

I had totally forgotten that I had an old dnSpy-net-win64 version on my PC. Tried again with the netframework version and ... whelp, somehow, it compiled a working Assembly-CSharp.dll

Output is a bit weird:

Code:
[ApplyMorphsThreadedFast] _morphs.Count 10275 | _touchedMorphs.Count 32

[ApplyMorphsThreadedFast] _morphs.Count 1065 | _touchedMorphs.Count 17

[ApplyMorphsThreadedFast] _morphs.Count 10275 | _touchedMorphs.Count 32

[ApplyMorphsThreadedFast] _morphs.Count 1065 | _touchedMorphs.Count 17

...

I'd expected the total size of the morphbank to be smth in the 30.000-50.000 range? (5.000 vars, plus local morphs - very "dirty" installation).
And why do both values oscillate?
 
HolyShit! It worked!

I had totally forgotten that I had an old dnSpy-net-win64 version on my PC. Tried again with the netframework version and ... whelp, somehow, it compiled a working Assembly-CSharp.dll

Output is a bit weird:

Code:
[ApplyMorphsThreadedFast] _morphs.Count 10275 | _touchedMorphs.Count 32

[ApplyMorphsThreadedFast] _morphs.Count 1065 | _touchedMorphs.Count 17

[ApplyMorphsThreadedFast] _morphs.Count 10275 | _touchedMorphs.Count 32

[ApplyMorphsThreadedFast] _morphs.Count 1065 | _touchedMorphs.Count 17

...

I'd expected the total size of the morphbank to be smth in the 30.000-50.000 range? (5.000 vars, plus local morphs - very "dirty" installation).
And why do both values oscillate?
female morphbank and male/neutral morphbank
 
I'm having a problem where I get pretty decent FPS (~40, which is some of the best I've gotten) but then as I move around the scene, it will drop to around 6 FPS then go back up. It seems to keep doing this. Not sure if I set it up wrong or what. I have an i7 10750 Intel with RTX 3060. Using it in VR on Quest 2 via Virtual Desktop. I've done tests using the Default scene, so nothing too intense.
 
I really need some help figuring this out, I have a i7 4790 non k, its i believe quadcore eight threads, if someone could help me that would be great
I have an i7 7700K, which is similar to your CPU, I don't know what the "right" settings are. I did read through this thread as best I could and then experiment with some different settings. I settled on these, and I can run scenes with 4 characters and a lot of other assets in the scene. This includes animations and other actions, hair, clothing, etc. and maintain about 28fps in VR. This is fast enough with physics rate at 60mhz and the physics update cap at 2 (located on the performance tab in VAM) that I am content. With these settings the CPU was no longer the roadblock in VR and I upgraded the GPU. Here are those settings and I hope at some point someone will point us in the right direction for the correct settings for these older CPUs.

[threads]
computeColliders=4
skinmeshPart=4
skinmeshPartMaxPerChar=2
applyMorphs=2
applyMorphMaxPerChar=4
#affinity=1,3,5,7
affinity=1,3,5,7
engineAffinity=1,2,3,4

[threadsVR]
computeColliders=4
skinmeshPart=4
skinmeshPartMaxPerChar=2
applyMorphs=2
applyMorphMaxPerChar=4
#affinity=1,3,5,7
affinity=1,3,5,7
engineAffinity=1,2,3,4
[profiler]
enabled=0
 
Ok, I have a i7-13700K, what values should I use in the *.ini?

Nvm, found something.
 
Last edited:
I'm having a problem where I get pretty decent FPS (~40, which is some of the best I've gotten) but then as I move around the scene, it will drop to around 6 FPS then go back up. It seems to keep doing this. Not sure if I set it up wrong or what. I have an i7 10750 Intel with RTX 3060. Using it in VR on Quest 2 via Virtual Desktop. I've done tests using the Default scene, so nothing too intense.
this is normal, its especially bad if you have the UI open while you move. Rendering a UI in unity is horrible.
 
computeColliders=4
skinmeshPart=4
skinmeshPartMaxPerChar=2
applyMorphs=2
applyMorphMaxPerChar=4
#affinity=1,3,5,7
affinity=1,3,5,7
engineAffinity=1,2,3,4

[threadsVR]
computeColliders=4
skinmeshPart=4
skinmeshPartMaxPerChar=2
applyMorphs=2
applyMorphMaxPerChar=4
#affinity=1,3,5,7
affinity=1,3,5,7
engineAffinity=1,2,3,4
Your applymorphs and applymorphsmaxperchar numbers are switched. first should be more or equal to the second. And your engineaffinity should be set to 2 fastest cores (not including secondary hyperthreaded "cores", ie: 2 and 4).
 
Your applymorphs and applymorphsmaxperchar numbers are switched. first should be more or equal to the second. And your engineaffinity should be set to 2 fastest cores (not including secondary hyperthreaded "cores", ie: 2 and 4).
Also Engine Affinity cores should be subtracted from the total core count used. So it would be 2, not 4.

[threads]
computeColliders=2
skinmeshPart=2
skinmeshPartMaxPerChar=2
applyMorphs=2
applyMorphMaxPerChar=2
#affinity=1,3,5,7
affinity=1,3,5,7
engineAffinity=1,3

Saying that, with only 4 cores it might be more beneficial to not use Engine Affinity at all
i.e.
[threads]
computeColliders=4
skinmeshPart=4
skinmeshPartMaxPerChar=4
applyMorphs=4
applyMorphMaxPerChar=4
#affinity=1,3,5,7
affinity=1,3,5,7
 
Your applymorphs and applymorphsmaxperchar numbers are switched. first should be more or equal to the second. And your engineaffinity should be set to 2 fastest cores (not including secondary hyperthreaded "cores", ie: 2 and 4).
Thank you for the input! I modified the file, the way I think you recommended. I did some testing and changed the Applymorphs and Applymorphsmaxperchar to 4 and 4. Please check this to see if I am on the right track. This setting does give me a few more frames per second than I had with the previous setting. Again, thank you!

[threads]
computeColliders=4
skinmeshPart=4
skinmeshPartMaxPerChar=2
applyMorphs=4
applyMorphMaxPerChar=4
#affinity=1,3,5,7
affinity=1,3,5,7
engineAffinity=2,4

[threadsVR]
computeColliders=4
skinmeshPart=4
skinmeshPartMaxPerChar=2
applyMorphs=4
applyMorphMaxPerChar=4
#affinity=1,3,5,7
affinity=1,3,5,7
engineAffinity=2,4
[profiler]
enabled=0
 
Based on turtlebackgoofy's comments (I literally read all 23 pages, as this back and forth between high-level programmers is AMAZING), I would imagine they are working on ways to detect CPU/cores and do all this automagically, but maybe that's just me being hopeful. I would seriously sub $100/mo on Patreon in support of this, even if it remains free, which it most assuredly will, based on what I've read.
 
Also Engine Affinity cores should be subtracted from the total core count used. So it would be 2, not 4.

[threads]
computeColliders=2
skinmeshPart=2
skinmeshPartMaxPerChar=2
applyMorphs=2
applyMorphMaxPerChar=2
#affinity=1,3,5,7
affinity=1,3,5,7
engineAffinity=1,3

Saying that, with only 4 cores it might be more beneficial to not use Engine Affinity at all
i.e.
[threads]
computeColliders=4
skinmeshPart=4
skinmeshPartMaxPerChar=4
applyMorphs=4
applyMorphMaxPerChar=4
#affinity=1,3,5,7
affinity=1,3,5,7
Thank you Tracer! I tested these and the setup without using the Engine Affinity seems to be best. I am not seeing a large difference. But, it makes sense, so I am sticking with it for now.
 
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).

Here are the two Base results

for desktop:
View attachment 341636

and VR:
View attachment 341637


The following are the results after applying the Performance Patch:

desktop:
View attachment 341638

VR:
View attachment 341639

Interesting that in DT mode, the gain in peak performance is huge, but the average FPS gained was moderate. In VR, there was little difference.

I am still re-reading Sir Turtle's various treatises on how FPS in VR works. Since as you can see, my results dips below 90FPS a lot, the result is that I am constantly seeing 45FPS in VR. I want to better understand what to do next if anything.

In conclusion, mucho mucho gracias to Sir TurtleBackGoofy, a true scholar and a gentleman. My rest of the day is occupied, so I'll come back to this very interesting thread later.
I think for us 24core Intel users we won't be getting any performance increases in VR
 
I think for us 24core Intel users we won't be getting any performance increases in VR
same result for me, with intel less cores:
improvement not definitively so much needed in desktop mode (instead I use always with temps and electricity profit a Gruber fps limiter: matter of fact, I stay on desktop mode just for editing)
... and with quest 3 (through VD streaming) I can see optimal performance with my standard not idiotically overdosed scenes. That's why I reverted to original vam .dll.
Disabling hyper threading was, anyway, a very good useful option inspired by this forum thread. Thanks to the turtle.

my actual rig: i713700k overclocked with intel XTU, "vanilla" gigabyte 4080s v2 "windforce" (fantastic upgrade I did last week from my hotty "old" 3080)... and as I said: no hyper-threading. No more patch experiments until we get an official mesheded universal vam update, always welcome.
 
Back
Top Bottom