Can you please release your patch for fixing? Thank you.
-
-
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.
Benchmark Result Discussion
- Thread starter MacGruber
- Start date
- Messages
- 57
- Reactions
- Points
- 8
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.
Last edited:
- Messages
- 263
- Reactions
- Points
- 93
[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
Last edited:
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:
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
- Messages
- 57
- Reactions
- Points
- 8
Hi!
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 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:
Last edited:
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?
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?
- Messages
- 263
- Reactions
- Points
- 93
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/ ]
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.
Last edited:
- Messages
- 701
- Reactions
- Points
- 63
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.
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.
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
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!
- Messages
- 263
- Reactions
- Points
- 93
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.
- Messages
- 141
- Reactions
- Points
- 93
I was a bit sceptical to it... But just gave it a go.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.
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.
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:
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]:
/ Edit 2 /
Also i just found out that patched dll is not compatibile with ZHFX's MMD plugin,
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?
Last edited:
After using the patch, there are some issues with the male model.
The image below comes from THE CUM BLASTER
Last edited:
- Messages
- 263
- Reactions
- Points
- 93
gonna check it, havent used a male model ever, looks like exactly 1 vertex was skipped during skinmeshing
- Messages
- 263
- Reactions
- Points
- 93
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
Last edited:
The image below comes from
Last edited:
- Messages
- 141
- Reactions
- Points
- 93
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]
- Messages
- 701
- Reactions
- Points
- 63
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.
- Messages
- 263
- Reactions
- Points
- 93
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:
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:
Attachments
Last edited:
- Messages
- 263
- Reactions
- Points
- 93
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:
Last edited:
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!
I tried CPU Performance Patch 10.
CPU: Intel Core i7 12700KF
GPU: GeForce RTX 3080
Before
After
Roughly increased by 6.7%.
CPU: Intel Core i7 12700KF
GPU: GeForce RTX 3080
Before
After
Roughly increased by 6.7%.
Last edited:
