All praise the genius of turtlebackgoofy, can't wait to see the new update!! Any ETA to throw to us worshippers?it already boots up with mono 6.12.0.206 and loads a scene, but there are still some minor issues with paths and so on. The great thing about unity is they didnt write anything themselfs and basicaly just lifted regular mono runtime with minor modifications they were legaly obliged to open source. Since C# is very portable you can just run the old unity engine on newest mono. Once I got everything working I can just turn on llvm bytecode optimization and let it rip. That way even custom unityscripts from all addons on this site should become blazing fast.
a unity game is built like this:
[vam.exe] <- process layer
[mono.dll] [unityplayer.dll] [mscorlib.dll] <- runtime and unity engine
[assembly-csharp.dll] <- the game itself
[all other scripts] <- dynamicaly loaded code
just had to built the correct mono.dll and add a few unity patches. I might also release an option with mono debugging enabled so you can just attach dnspyex to vam and step through your scripts.
man, you are truely a biological compiler... respect! and looking forward to your next patch version, sounds amazing what you have stated in your progress update. keep up the good work & many thanks!Current progress: custom unityscripts (cs files in vars) are working and I get a HIGHER fps in the default scene (350 fps) WITHOUT any other patches except setting CPU affinity in task manager. It appears the newest mono and the newest bdwgc already makes the c# skinmesh code of vam as fast as my native code plugin. This is BEFORE LLVM optimizations, those are yet to come and will be a huge deal. Afaik LLVM optimizations arent even in the newest unity engine.
If you dont see a fps difference, then you are probably gpu bottlenecked. Your strongest 2 cores might be different than what you copied over in engineaffinity, but if they were those cores:is anyone using ryzen 7 5800x3d ? and if so what settings pls?
i added the patch but sadly i cant see the improvement and its also a little worse with frame hangups... :?
what am i doing wrong...pls
I believe this is for me: I copied it into Adjust SkinMeshPartDLL.ini:
[threadsVR]
computeColliders=8
skinmeshPart=8
applyMorphs=8
skinmeshPartMaxPerChar=8
applyMorphMaxPerChar=8
affinity=1,3,5,7,9,11,13,15
engineAffinity=1,3
[profiler]
enabled=0
ill see if it helps...
works with any multicore cpu...so all cpu.Would this work with Ryzen 5 3600?
hmm your VR benchmarks look strange, do you by any chance use "image reprojection" because you have a wide fov headset? This more than halves FPS in VR.Results are in!
Quest 3 + Virtual Desktop + SteamVR, Windows 11, RAM @ 3600 MHz
These tests were complete with ReShade enabled. I don't think it had a big impact. I also increased memory from 32 GB to 64 GB during testing. This surprisingly resulted in a 15 FPS increase in Baseline 3. 75% FPS increase on average.
Tips for anyone getting this set up:
- Make sure you have the correct config for your CPU.
- Make sure to edit the boot.config file and the `job-worker-count=` matches the number of physical + logical cores in your CPU. I mistakenly used 12 instead of 16 after I OCRd the example image. Setting it to 16 resulted in a 33% FPS increase.
- Virtual Desktop users disable ASW in the Virtual Desktop Streaming settings.
- Virtual Desktop graphics quality setting will affect the result.
If anyone has any ideas to get more FPS while in VR, I'm all ears.
Update: I did some more VR testing with Baseline 3 comparing different graphics quality settings in Virtual Desktop:
Ultra - 31.68 FPS 6582x3408 (seen above)
High - 34 FPS 6112x3172
Medium - 42 FPS 4936x2584
Don't want to go any lower I think I can tell it doesn't look as good.
Thanks @turtlebackgoofy for making this possible!
hmm your VR benchmarks look strange, do you by any chance use "image reprojection" because you have a wide fov headset? This more than halves FPS in VR.
The Meta Quest 3 has a field of view (FOV) of 110 degrees horizontally and 96 degrees vertically.
I have almost the same CPU and GPU (5950x and 4090) as you and I get constant 90fps min/max everywhere in the vr benchmark. Image reprojection is not ASW, it is used if your HMD is not natively supported and the picture gets first rendered to a screen and the screen is rendered again for your HMD. It happens if you have canted optics and maybe if your HMD is using some software in between like virtual desktop?Hey, thanks for taking a look! I'm not sure if the Quest 3 is considered having a wide FOV?
Do you mean "strange" as in the FPS is too low or that it's too close to 30 and 45 FPS? Is image reprojection another term for Asynchronous Spacewarp? I had ASW set to Disabled in Virtual Desktop. I think the Motion Smoothing option is not present in SteamVR because of Virtual Desktop so I can't disable it there, and Oculus Tray Tool, which I used to use for my Rift CV1, made my computer very sad. I noticed the FPS stray farther from 30 and 45 FPS after it was disabled, but I agree it still seems close, though it might be a coincidence. In the VR After image (sorry I never did a before VR test), I got 37 FPS in HairSim which I think confirms it was disabled. Let me know your thoughts!
I tried to figure this out. The best info I found was from the Virtual Desktop XR repo and wiki, which appears to be an OpenXR implementation for Virtual Desktop maintained by the lead OpenXR dev. When I switch to 'prefer VDXR' in Virtual Desktop, in VAM, the runtime appears to be using Oculus in the benchmark and Virtual Desktop performance overlay and I get about the same result as with OpenVR in the benchmark. I think this should say VDXR instead as per the image in the wiki. Which makes it seem that VAM isn't programmed to use OpenXR. So, I must be missing something because I haven't seen a way to test OpenXR directly.I have almost the same CPU and GPU (5950x and 4090) as you and I get constant 90fps min/max everywhere in the vr benchmark. Image reprojection is not ASW, it is used if your HMD is not natively supported and the picture gets first rendered to a screen and the screen is rendered again for your HMD. It happens if you have canted optics and maybe if your HMD is using some software in between like virtual desktop?
You should try running the game in OpenXR directly.
OVRPlugin.dll
in /VAM/VAM_Data/Plugins/
with one from the repo but it just caused the game to launch in desktop. I also tested via Steam Link and Quest Link. The first thing I noticed is that the image looks terrible compared to Virtual Desktop, and they used OpenVR and Oculus in the benchmark. SteamVR and Oculus should both support OpenXR as per the wiki as well. Would launching a bat file like this work (without having SteamVR open)?I tried to figure this out. The best info I found was from the Virtual Desktop XR repo and wiki, which appears to be an OpenXR implementation for Virtual Desktop maintained by the lead OpenXR dev. When I switch to 'prefer VDXR' in Virtual Desktop, in VAM, the runtime appears to be using Oculus in the benchmark and Virtual Desktop performance overlay and I get about the same result as with OpenVR in the benchmark. I think this should say VDXR instead as per the image in the wiki. Which makes it seem that VAM isn't programmed to use OpenXR. So, I must be missing something because I haven't seen a way to test OpenXR directly.
I tried forcing it to use OpenXR by replacing theOVRPlugin.dll
in/VAM/VAM_Data/Plugins/
with one from the repo but it just caused the game to launch in desktop. I also tested via Steam Link and Quest Link. The first thing I noticed is that the image looks terrible compared to Virtual Desktop, and they used OpenVR and Oculus in the benchmark. SteamVR and Oculus should both support OpenXR as per the wiki as well.
On a side note, I came across Lossless Scaling on Youtube and it works great for VAM in desktop. It's a perceived improvement of 2-3x FPS depending on the chosen setting. For example, a game running at 50 FPS looks like 150 FPS.