Benchmark Result Discussion

[mostvanvege]

I just tried disabling E cores... Results are ... weird.
'normal state'
View attachment 186101
With E cores disabled.
View attachment 186102

It's actually went worse without E cores. Dunno, maybe i'm missing some step, like OC for P cores when i disable E, but thought disabling them alone would boost single core performance a bit.

Funny thing i noticed... There is pretty much no difference at all for 4090 if it's 1440p or 1080p lol

Hi,
I know its a pretty long shot, but I just noticed that you got consistently higher 1% lows with E cores off even tough the worst averages. May I ask if you did try process lasso? Its a free app that helps you manually assign cores to tasks. With it you could force vam run only on your P cores and everything else on the Es. I would be really interested to see how it might change the results. It probably could dismiss the only advantage of the 7800x3d.

 

[turtlebackgoofy]

Can you please release your patch for fixing? Thank you.

[link removed wait for official https://hub.virtamate.com/resources...to-30-faster-physics-up-to-60-more-fps.43427/ ]

The mod reimplements costly methods in native C and makes the VAM code call them instead of their C# version. Also multithreads a few of them.
The replaced methods are SkinMeshPart, FillGpuSphereColliderData, FillCapsuleLineSphereColliderData, SkinMeshCPUandGPUApplyPostSkinMorphs and RecalculateNormals.
Place the SkinMeshPartDLL.dll into /vamroot/ and Assembly-CSharp.dll into /vamroot/VaM_Data/Managed/ . Make a backup of your original /vamroot/VaM_Data/Managed/Assembly-CSharp.dll
If you have slow RAM speeds and little CPU cache it should speed up skinmeshing considerably, especially useful in scenes with multiple persons. I get about 20% better physics time in the benchmark, which should be about 10% more fps. If you have a X3D ryzen it should make 0 difference.
Requires a CPU with AVX2

 

[AshArm]

patched5.7z

This file has been shared with you on pixeldrain

pixeldrain.com

The mod reimplements costly methods in native C and makes the VAM code call them instead of their C# version. Also multithreads a few of them.
The replaced methods are SkinMeshPart, FillGpuSphereColliderData, FillCapsuleLineSphereColliderData, SkinMeshCPUandGPUApplyPostSkinMorphs and RecalculateNormals.
Place the SkinMeshPartDLL.dll into /vamroot/ and Assembly-CSharp.dll into /vamroot/VaM_Data/Managed/ . Make a backup of your original /vamroot/VaM_Data/Managed/Assembly-CSharp.dll
If you have slow RAM speeds and little CPU cache it should speed up skinmeshing considerably, especially useful in scenes with multiple persons. I get about 20% better physics time in the benchmark, which should be about 10% more fps. If you have a X3D ryzen it should make 0 difference.
Requires a CPU with AVX2

Thanks for making the optimization patch. But it seems to conflict with BodyLanguage. May I ask how to solve it? It generates the following error:

!> Compile of CheesyFX.BodyLanguage.49:/Custom/Scripts/CheesyFX/BodyLanguage/BodyLanguage.cslist failed. Errors:
!> [CS19]: Operator `==' cannot be applied to operands of type `DAZMorphVertex' and `null' in <Unknown> at [1491, 40]

 

[mostvanvege]

patched5.7z

This file has been shared with you on pixeldrain

pixeldrain.com

The mod reimplements costly methods in native C and makes the VAM code call them instead of their C# version. Also multithreads a few of them.
The replaced methods are SkinMeshPart, FillGpuSphereColliderData, FillCapsuleLineSphereColliderData, SkinMeshCPUandGPUApplyPostSkinMorphs and RecalculateNormals.
Place the SkinMeshPartDLL.dll into /vamroot/ and Assembly-CSharp.dll into /vamroot/VaM_Data/Managed/ . Make a backup of your original /vamroot/VaM_Data/Managed/Assembly-CSharp.dll
If you have slow RAM speeds and little CPU cache it should speed up skinmeshing considerably, especially useful in scenes with multiple persons. I get about 20% better physics time in the benchmark, which should be about 10% more fps. If you have a X3D ryzen it should make 0 difference.
Requires a CPU with AVX2

Hi!

Thanks for the contribution! I was curious and actually it does help with an X3D cpu aswell. The difference is like 10-15%.
I tested in 720p and 8x tesselation (so it's not gpu limited, normal VAm ran twice - before and after - to make sure it is not statistical error either ).
Results:
Vanilla VAM 720p 8X tesselation:

Patched - Vanilla VAM 720p 8X tesselation:

 

[kashh135]

Hey folks - seeking some advice on buying a new rig. This seemed like the best thread - apologies if I should post elsewhere.

I'm trying to decide between an Intel i9-14900K with 64GB DDR5-6400, vs. a Ryzen 9 7950X3D with 64GB DDR5-5600. Both would be with an RTX 4090. I want the best possible rig I can get for playing VAM in VR, especially with multi-person dance scenes. Any recommendations?

Also - I've seen people mention having to assign specific cores to VAM in order to get the best performance - would I have to do that with either option?

 

[turtlebackgoofy]

Thanks for making the optimization patch. But it seems to conflict with BodyLanguage. May I ask how to solve it? It generates the following error:

Damn, I changed DAZMorphVertex from an Object to a Struct to speed up. Changed it back, but loading morphs might be slower again. Plugin works again.
I also added the possiblity to use an .ini file to configure the threadcount.

Hi!

Thanks for the contribution! I was curious and actually it does help with an X3D cpu aswell. The difference is like 10-15%.
I tested in 720p and 8x tesselation (so it's not gpu limited, normal VAm ran twice - before and after - to make sure it is not statistical error either ).
Results:
Vanilla VAM 720p 8X tesselation:
View attachment 329509
Patched - Vanilla VAM 720p 8X tesselation:
View attachment 329508

Try adjusting the .ini file next to the SkinMeshPartDLL.dll to better fit your processor. Usually you should use as many threads as your CPU has hyperthreads, but sometimes if the CPU is fast enough it's faster to work with less threads instead of waiting for more threads. SkinmeshPart is computation intensive, so try using as many skinmeshpart threads as you have hyperthreads. ComputeColliders is memory read/write intensive, so it would make sense to use less of them so the CPU can predict more instructions. But everything depends on the cache size/core count/memory speed, so experiment with it.

[link removed wait for official https://hub.virtamate.com/resources...to-30-faster-physics-up-to-60-more-fps.43427/ ]

Hey folks - seeking some advice on buying a new rig. This seemed like the best thread - apologies if I should post elsewhere.

I'm trying to decide between an Intel i9-14900K with 64GB DDR5-6400, vs. a Ryzen 9 7950X3D with 64GB DDR5-5600. Both would be with an RTX 4090. I want the best possible rig I can get for playing VAM in VR, especially with multi-person dance scenes. Any recommendations?

Also - I've seen people mention having to assign specific cores to VAM in order to get the best performance - would I have to do that with either option?

Buy the ryzen with X3D, its not even a competition, the lightning fast and huge 3d cache triples the skinmesh (physics time) calculations. With a proper code refactoring of vam every CPU could get the 160+ fps times in the baseline 3 benchmark, but with the unoptimized code the 3d cache of ryzen cpus just bruteforces better fps.

 

[HolySchmidt]

14900K is faster if I remember correctly. Faster single core speed. Results are in here somewhere. If you buy AMD get the 7800X3D. If you dont need the multicore power for workstation programs.

 

[veijokyy]

patched5.7z

This file has been shared with you on pixeldrain

pixeldrain.com

The mod reimplements costly methods in native C and makes the VAM code call them instead of their C# version. Also multithreads a few of them.
The replaced methods are SkinMeshPart, FillGpuSphereColliderData, FillCapsuleLineSphereColliderData, SkinMeshCPUandGPUApplyPostSkinMorphs and RecalculateNormals.
Place the SkinMeshPartDLL.dll into /vamroot/ and Assembly-CSharp.dll into /vamroot/VaM_Data/Managed/ . Make a backup of your original /vamroot/VaM_Data/Managed/Assembly-CSharp.dll
If you have slow RAM speeds and little CPU cache it should speed up skinmeshing considerably, especially useful in scenes with multiple persons. I get about 20% better physics time in the benchmark, which should be about 10% more fps. If you have a X3D ryzen it should make 0 difference.
Requires a CPU with AVX2

I tested out your patch with a bloated version of Vam and it seems to work nicely even with a X3D processor. I have a 7950X3D and 3080ti on my setup.

But as @Ashram pointed out there seems to be a conflict with a Bodylanguage plugin.

Here are my results:

Bloated version without the patch:

Bloated version with the patch:

Thank you very much for your patch!

 

[turtlebackgoofy]

I tested out your patch with a bloated version of Vam and it seems to work nicely even with a X3D processor. I have a 7950X3D and 3080ti on my setup.

But as @Ashram pointed out there seems to be a conflict with a Bodylanguage plugin.

Here are my results:

Bloated version without the patch:
View attachment 329776

Bloated version with the patch:
View attachment 329777

Thank you very much for your patch!

Nice.
The bloat btw is because EVERY SINGLE addonpackage has it's morphs loaded into the morphbank at start and the morphbank gets iterated through in EVERY SINGLE FRAME. I tried to make all morphs to load ondemand by default, but that broke things.
The morphbank iteration happens when morphs are applied to a character and are counted into "PhysicsTime". So its a burden on the rendering of every character in the scene.

 

[trety]

Damn, I changed DAZMorphVertex from an Object to a Struct to speed up. Changed it back, but loading morphs might be slower again. Plugin works again.
I also added the possiblity to use an .ini file to configure the threadcount.


Try adjusting the .ini file next to the SkinMeshPartDLL.dll to better fit your processor. Usually you should use as many threads as your CPU has hyperthreads, but sometimes if the CPU is fast enough it's faster to work with less threads instead of waiting for more threads. SkinmeshPart is computation intensive, so try using as many skinmeshpart threads as you have hyperthreads. ComputeColliders is memory read/write intensive, so it would make sense to use less of them so the CPU can predict more instructions. But everything depends on the cache size/core count/memory speed, so experiment with it.

patched6.7z

This file has been shared with you on pixeldrain

pixeldrain.com

Buy the ryzen with X3D, its not even a competition, the lightning fast and huge 3d cache triples the skinmesh (physics time) calculations. With a proper code refactoring of vam every CPU could get the 160+ fps times in the baseline 3 benchmark, but with the unoptimized code the 3d cache of ryzen cpus just bruteforces better fps.

I was a bit sceptical to it... But just gave it a go.
A few notes, i haven't even restarted my PC. It was running for about 10hours already, i played entire campaign of T8 [lol], and watched bunch of stuff on the net.
HT disabled - tho if i understand it correctly i should enable it for the patch? RAM at 6000Mhz. No other OC.
Vanilla install:

Old, no patch:

Spoiler

So yeah, the patch does work pretty damn nicely. 1\6 of physics time reduction is a lot.

// Edit //
Just runed benchmark again, this time with HT on. I haven't touched provided ini file, it could give me better results after tuning it up, but i don't think it could beat the no HT one. It still slightly better than original VAM [with HT off]:

Spoiler

/ Edit 2 /
Also i just found out that patched dll is not compatibile with ZHFX's MMD plugin, with patched Monocecil.dll, damn
It freezes all the physics in VAM if you would try to keep them both installed, without even loading MMD plugin itself

After further investigation, i found out it's caused by ZHFX Bepinex plugins, which blocks any 'loose' dll in Vam_root aside of reshade, changing theirs extension to 'dII'. I guess the only way to make them working together is to ask ZHFX to whitelist 'SkinMeshPartDLL.dll', unless it can be moved and called from other location via modified Assembly dll?

 

[AshArm]

Nice.
The bloat btw is because EVERY SINGLE addonpackage has it's morphs loaded into the morphbank at start and the morphbank gets iterated through in EVERY SINGLE FRAME. I tried to make all morphs to load ondemand by default, but that broke things.
The morphbank iteration happens when morphs are applied to a character and are counted into "PhysicsTime". So its a burden on the rendering of every character in the scene.

After using the patch, there are some issues with the male model.
The image below comes from THE CUM BLASTER

Spoiler: THE CUM BLASTER

Spoiler: Some other scenes

 

[turtlebackgoofy]

fter using the patch, there are some issues with the male model.
The image below comes from THE CUM BLASTER

Spoiler: THE CUM BLASTER

View attachment 330007

Spoiler: Some other scenes

View attachment 330008

gonna check it, havent used a male model ever, looks like exactly 1 vertex was skipped during skinmeshing

 

[turtlebackgoofy]

After using the patch, there are some issues with the male model.
The image below comes from THE CUM BLASTER

Spoiler: THE CUM BLASTER

View attachment 330007

Spoiler: Some other scenes

View attachment 330008

I was a bit sceptical to it... But just gave it a go.
A few notes, i haven't even restarted my PC. It was running for about 10hours already, i played entire campaign of T8 [lol], and watched bunch of stuff on the net.
HT disabled - tho if i understand it correctly i should enable it for the patch? RAM at 6000Mhz. No other OC.
Vanilla install:
View attachment 329878
Old, no patch:

Spoiler

View attachment 329879

So yeah, the patch does work pretty damn nicely. 1\6 of physics time reduction is a lot.

// Edit //
Just runed benchmark again, this time with HT on. I haven't touched provided ini file, it could give me better results after tuning it up, but i don't think it could beat the no HT one. It still slightly better than original VAM [with HT off]:

Spoiler

View attachment 329880

/ Edit 2 /
Also i just found out that patched dll is not compatibile with ZHFX's MMD plugin, with patched Monocecil.dll, damn
It freezes all the physics in VAM if you would try to keep them both installed, without even loading MMD plugin itself

After further investigation, i found out it's caused by ZHFX Bepinex plugins, which blocks any 'loose' dll in Vam_root aside of reshade, changing theirs extension to 'dII'. I guess the only way to make them working together is to ask ZHFX to whitelist 'SkinMeshPartDLL.dll', unless it can be moved and called from other location via modified Assembly dll?

Fixed both: [link removed, wait for https://hub.virtamate.com/resources...to-30-faster-physics-up-to-60-more-fps.43427/ ]
Should look like this unpacked, delete the previous files:
root\PerformancePatches\SkinMeshPartDLL.dll
root\PerformancePatches\SkinMeshPartDLL.ini
root\VaM_Data\Managed\Assembly-CSharp.dll

 

[AshArm]

Fixed both: https://pixeldrain.com/u/UM437dWE
Should look like this unpacked, delete the previous files:
root\PerformancePatches\SkinMeshPartDLL.dll
root\PerformancePatches\SkinMeshPartDLL.ini
root\VaM_Data\Managed\Assembly-CSharp.dll

After testing, patch7 fixes the model spikes, but it seems to cause the position and pose of the character model to be locked.
The image below comes from THE CUM BLASTER

Spoiler: CumBlaster

View attachment 330393

Spoiler: Some other scenes

View attachment 330396

 

[trety]

After testing, patch7 fixes the model spikes, but it seems to cause the position and pose of the character model to be locked.
The image below comes from THE CUM BLASTER

Spoiler: CumBlaster

View attachment 330393

Spoiler: Some other scenes

View attachment 330396

It works on my end. Tested it on both vanilla install, and main, with MMD plugin installed.
Make sure to delete old version, and keep SkinnedMeshDLL.dll in it's original folder [**vam_root*\PerformancePatches], and replace Assembly in managed.

I had these issues with MMD plugin at version 6. Bassically, Assembly dll can't find SkinedMeshDLL [cuz MMD plugin was renaming it in my case, in yours SkinnedMeshDLL is probably in root, from v6, or you not updated Assembly file - with new location patch]

 

[HolySchmidt]

Why not open a new thread cause this is for benchmark results? I think whatever you guys are doing is interesting enough for others and we could talk about it seperately.

 

[turtlebackgoofy]

Seperate thread: https://hub.virtamate.com/threads/performance-patch-up-to-15-more-physics-speed.49679/

 

[w21403]

4070ti super

 

[Seraphim]

Results of the new performance patch on a bloated install with active session plugins on X3D chip:

Vanilla:

With patch:

Maybe just scales better with more intensive physics (ie: more physics plugins/morphs). When i tested with a fresh install of VAM, it seemed to make negligible difference.:

Fresh VAM:


With fresh patch lol:

 

[turtlebackgoofy]

Results of the new performance patch on a bloated install with active session plugins on X3D chip:

Vanilla:
View attachment 331511

With patch:
View attachment 331512

Maybe just scales better with more intensive physics (ie: more physics plugins/morphs). When i tested with a fresh install of VAM, it seemed to make negligible difference.:

Fresh VAM:
View attachment 331513

lol, your physics time improved across the board up to 20%, but since they are already good they dont matter much. Also something else is eating your FPS, for example in Baseline 3 the total time is 5.14ms. 1000ms/5.14ms=194fps, however it shows as 152.70 fps. So either its nvidia overlay or the scene makes calculation errors at high fps. My FPS numbers are pretty much equal to 1000ms/totaltime. I also added an updated version which fixes the morph clutter of having many vars installed in this thread: https://hub.virtamate.com/threads/performance-patch-up-to-30-more-physics-speed.49679/

 

[Seraphim]

lol, your physics time improved across the board up to 20%, but since they are already good they dont matter much. Also something else is eating your FPS, for example in Baseline 3 the total time is 5.14ms. 1000ms/5.14ms=194fps, however it shows as 152.70 fps. So either its nvidia overlay or the scene makes calculation errors at high fps. My FPS numbers are pretty much equal to 1000ms/totaltime. I also added an updated version which fixes the morph clutter of having many vars installed in this thread: https://hub.virtamate.com/threads/performance-patch-up-to-30-more-physics-speed.49679/

Yeah I dont have nvidia overlay and it does that on a fresh vam install too. I guess its just errors because of high fps. Ill test this on vr soon too. I still get cpu bottlenecked in some scenes, because of my physics/morph based plugins i use lol.
Edit: Yeah im using version 9 from your thread.

-Self comparison of normal and the new cpu performance fix in VR with my normal unoptimized but beautiful settings and session plugins enabled .

"Vanilla" lol:

Patched:

 

[meshedvr]

Nice.
The bloat btw is because EVERY SINGLE addonpackage has it's morphs loaded into the morphbank at start and the morphbank gets iterated through in EVERY SINGLE FRAME. I tried to make all morphs to load ondemand by default, but that broke things.
The morphbank iteration happens when morphs are applied to a character and are counted into "PhysicsTime". So its a burden on the rendering of every character in the scene.

I appreciate the effort here. It is very cool what you are doing! A couple of things though.

Some of things you are optimizing are running on an asynchronous side thread away from the main thread, and in most scenes the side threads complete before the next physics update and ultimately don't affect PhysicsTime. The physics update has a section where it has to wait on the async thread to complete some of the operations. So while you may improve FPS in some cases, it won't help in others where this is no wait time on the side threads. Other stuff you are optimizing probably is on the main thread, so that is always great if you can pull that off. I decided to stick to pure Unity and C# for VaM, so there are indeed optimizations that can be done if moving to C code and better memory structs. I also missed some optimizations even within C# itself. I did optimize for the general case of 2 Person atoms with full physics on. For that case, the bulk of the CPU time is in Unity's Physx system which is really inefficient when syncing Physx back to managed game objects.

Also - we don't allow publishing replacement dlls here without some kind of warning to users as this could easily bypass the security restrictions. I know you don't have malicious intent, but we have to put a label on all of these consistently. So we are reaching out to you to see if you can move your enhancement to a resource where we can properly flag it with the warning we apply to other resources of this nature.

Thank you!

 

[veijokyy]

7950X3D + 4080 Super + 64GB DDR5 6000 and the patch:

 

[tuxxxedo_mask]

I tried CPU Performance Patch 10.

CPU: Intel Core i7 12700KF
GPU: GeForce RTX 3080

Before

After

Roughly increased by 6.7%.

 

[turtlebackgoofy]

I tried CPU Performance Patch 10.

CPU: Intel Core i7 12700KF
GPU: GeForce RTX 3080

Before
View attachment 332718
After
View attachment 332719
Roughly increased by 6.7%.

Interesting, you get MORE FPS in Baseline3 benchmark now than in Simpler Physics. Both are the exactly same scene, but simpler physics has soft body turned off. You are getting MORE FPS with soft body turned ON lmao. Would you mind sharing a performance profile like discribed in the resource description?