turtlebackgoofy
Well-known member
- Messages
- 222
- Reactions
- Points
- 63
he has his hands full with vam2 and you can always just literally install this patch, there wont be any big vam1 updates anymore. There is no reason to merge my changes into vam1.
- Thread starter turtlebackgoofy
- Start date
turtlebackgoofy
Well-known member
- Messages
- 222
- Reactions
- Points
- 63
I see no case where a 4080 might be limitting, except if you have a 14900k overclocked with 8000mhz RAM. From what I have seen, its always the damn single unity thread holding you back.
turtlebackgoofy
Well-known member
- Messages
- 222
- Reactions
- Points
- 63
Bros, I think I found the VR issue:
Exactly same scene, same settings, just different resolution in VR and obviously 2 eyes.
2D:
As you can see, the render time increased from 0.83ms to 1.37ms, a 0.54ms increase, pretty much what you would expect when rendering two eyes. Literally everything else increased by pretty much exactly double, although it has nothing to do with rendering. Physics doesnt need to run twice if you render two cameras (eyes). My FPS in VR should've been 164fps...
I will investigate.
Exactly same scene, same settings, just different resolution in VR and obviously 2 eyes.
2D:
VR:
As you can see, the render time increased from 0.83ms to 1.37ms, a 0.54ms increase, pretty much what you would expect when rendering two eyes. Literally everything else increased by pretty much exactly double, although it has nothing to do with rendering. Physics doesnt need to run twice if you render two cameras (eyes). My FPS in VR should've been 164fps...
I will investigate.
Lots of weird stuff happens with framerate in VR - on my 13900K/4090 rig, getting very close to thick, simmed hair has little effect on framerate as long as I am on desktop, but try to do the same thing in VR and all of a sudden even my mighty rig drops to single digit FPS.
virtualharem34
Well-known member
yep, I figured out the descrpancy in fps. I was getting with the same scene 50fps in desktop, 30 in VR.
weird. same settings.
weird. same settings.
turtlebackgoofy
Well-known member
- Messages
- 222
- Reactions
- Points
- 63
you ofc have to take in mind that VR FPS != Non-VR FPS. VR runtimes always enforce a Vsync to reduce stuttering. Your FPS average is no longer the average between all frames, but the frames were prolonged to 1000/90. This means the "max 1%" is now 90fps (the HMD refreshrate) and your slowest frames now weight more in the average.
HOWEVER we see an increase of all timings even when we have constant 90fps and in my profiling I see that literally every function running in C# somehow took longer, but the code in my native patch still processed the same data in the same time. So unity is doing something to CoRoutines, like preemptying the threads, but only when they are in C#.
When running in VR, everything allocates about 3x as much memory while running in C#. I believe something (steamvr?) is constantly filling the garbage collector in a background thread and it shows up everywhere.
NonVR
SteamVR
Not only did the garbage grew fast while executing the first method, the second method should never allocate anything and yet in VR the garbage grows.
Methods which do not need the C# heap while they run did not slow down. Methods which do use the C# heap are slowed down across the whole application, because they wait for the mysterious trash thread to unlock the heap.
Folks, I might actually solve this.
This is 100% the performance issue in VR
Last edited:
same on my 13700k/4080
Regarding hair in VR. I usually reduce the hair multiplier and curve density (each at least <16) in the hair options. Sometimes I make the hair thicker (don't recall the option name) to compensate for fewer hair. Also it seems hair + light with shadow enabled is a real fps eater, so I in addition often disable shadows on lights.
I just ran a long vr session in a clean cam install, with patch 13, and the latest patreon version of everlasters naturalis, in a modified version of simpleride 3 by c&g. It's a riding cowgirl scene with a lot of movement. While performance was stellar, it seems there is some very weird stuff going on with physics. With or without naturalis breast's seem substantially softer, especially when small. The larger they get the more normal the physics seems. Also after Bout 30 minutes of the scene running, suddenly the girl is bouncing slightly on her own, without any animations running. I run this scene often, and these issues only showed up with your patch. I didn't try 10 or 11 in vr, so I'll try those builds.
Last edited:
Does it not support V1.21.1.0？I cannot enter the game after using it
turtlebackgoofy
Well-known member
- Messages
- 222
- Reactions
- Points
- 63
did you increase physics rate? breasts become very soft for some reason if physics runs often, even in vanilla.
There is a setting called Physics Update Cap. This setting specifies the maximum number of Physics Updates that can run per rendered frame. If your FPS is low enough that this cap gets hit, you could experience time slowing down, which will make everything look slo-mo. This is just an unfortunate side effect of physics running at a fixed frame rate and being independent of the rendered frames. Try setting to 3 to minimize that possibility, but note that it could lower your FPS because each physics update takes a lot of time and up to 3 could happen per rendered frame. This could happen if you have physics rate set very high and/or your rendered FPS is very low.
I appreciate everything you are doing here, and I'm glad to see you discovered the Physx single thread bottleneck (which is a bit better in newer Unity versions but it still sucks - I'll be doing custom skin physics in VaM2 for this reason). I also glad you posted those charts of how the character threads timing works. The goal for VaM1 was to hit 90FPS for VR usage. I realize with heavy physics it often does not hit that unless you have a very good CPU/GPU and are not running a scene with lots of models all with soft-body physics on. It was a challenge. The character threads code was optimized just enough to try to hit this 90FPS so as not to be the bottleneck. The skinning system is very inefficient as is the morph code. It is great you addressed both of those. When I developed this I didn't see much of a point trying to hit a max FPS above 90 since I was targeting VR and that was the sweet spot. The ultimate bottleneck is Physx on physics heavy scenes and there isn't any way around that. That all said, I am still very glad you looked into this and found some amazing fixes just sitting there for many/most users. I would love to roll this back into official release at some point if you are willing and I can find some time in between VaM2 work. That might be tough. I would definitely compensate you if we manage go this route. If you are interested in making some $$$, I could even give you access to the VaM github repos so we can add this in an easier-to-review manner. I would want to review everything just to make sure nothing is getting broken. DM me if you want to go this route.
Thank you!
We'll I have phys rate set to auto, which is 90hz, and update cap set to 3. Same settings I usually run. I'll make a couple recordings to show the difference I'm seeing with patched vs non-patched. Read through meshed's response, and while the scene did eventually start to bog down, I was pretty steady at 90 fps, with a matching phys rate and update cap at 3, but even small chested model had breast movement like they were soft and heavy. I'll continue to to investigate, don't want to give up these additional frames.
Running a quest 3 via virtual desktop, bypassing steam and oculus runtimes, with passthrough which limits the max refresh rate to 90.
@turtlebackgoofy
I know you mentioned: "Also loading cloths/hair from every var no longer loads cloths/hair from every var for each cloth/hair loaded, which speeds up scene loading when you have a lot of vars installed."
but dude, yesterday I run VaM (with 7k+ vars) in VR and my scenes were loading like 70% FASTER (didn't measure it, just my feeling).
This is amazing. I could load scenes in like 10-15s where previously it would take almost one minute, sooo noticeable difference.
Again, great work!
I know you mentioned: "Also loading cloths/hair from every var no longer loads cloths/hair from every var for each cloth/hair loaded, which speeds up scene loading when you have a lot of vars installed."
but dude, yesterday I run VaM (with 7k+ vars) in VR and my scenes were loading like 70% FASTER (didn't measure it, just my feeling).
This is amazing. I could load scenes in like 10-15s where previously it would take almost one minute, sooo noticeable difference.
Again, great work!
Well for small chest you might wanna lower the mass and crank up the spring, otherwise they will play you the song of their people.
This issue isn't coming from this cpu mod.
Edit: I also think that JointCorrect and ShakeIt does not like whats going on here with those 9999999 automated morphs being applied.
I've been running this heavily modified scene for months, at least once a week, in vr, with literally hundreds of different models of various shapes and sizes, without this issue. Saying it's not coming from this mod seems a bit premature, as he has stated he made changes in the last patch that directly affects how morphs in things like naturalis load, and there have already been morph bugs in his previous patches, so it's not some wild idea that something is messed up.
turtlebackgoofy
Well-known member
- Messages
- 222
- Reactions
- Points
- 63
correct, it is very much possible that under some loading circumstances a morph that makes breasts less shaky went missing
My bad then, I was only speaking out of my own experience. I had those floppy small breasts way before this was introduced, always happened with default settings.
wileyc2k23
New member
- Messages
- 3
- Reactions
- Points
- 1
I have a AMD 5800X chip. Do I modify the [threadsVR] to match [threads} or leave them as is? [threads] matches the 5800X settings shown on the overview page. Below is the settings in the config file. Thanks for doing this.
[threads]
computeColliders=8
skinmeshPart=8
applyMorphs=8
skinmeshPartMaxPerChar=8
applyMorphMaxPerChar=8
affinity=1,3,5,7,9,11,13,15
[threadsVR]
computeColliders=4
skinmeshPart=1
applyMorphs=2
skinmeshPartMaxPerChar=4
applyMorphMaxPerChar=2
affinity=1,3,5,7,9,11,13,15
[profiler]
enabled=0
[threads]
computeColliders=8
skinmeshPart=8
applyMorphs=8
skinmeshPartMaxPerChar=8
applyMorphMaxPerChar=8
affinity=1,3,5,7,9,11,13,15
[threadsVR]
computeColliders=4
skinmeshPart=1
applyMorphs=2
skinmeshPartMaxPerChar=4
applyMorphMaxPerChar=2
affinity=1,3,5,7,9,11,13,15
[profiler]
enabled=0
turtlebackgoofy
Well-known member
- Messages
- 222
- Reactions
- Points
- 63
I think I found some workaround for VR for now:
Same settings as for Non-VR and doing no workaround:
Same, but banishing all processes except vam into a different CCD, so VaM runs exclusively on a CCD, while ignoring SMT cores:
Also reserving the two fastest cores for the unity engine (another tweak I will release soon)
The script (needs to be run in powershell and as admin after vam and steamvr and everything has finished loading)
It appears for AMD atleast, that giving VaM exclusive access to a set of cores running on a CCD and banishing all other processes to other cores AND giving the unity main thread the fastest two cores for itself, has the best outcome in VR.
Now I am passing almost all benchmarks for smooth VR:
Same settings as for Non-VR and doing no workaround:
Same, but banishing all processes except vam into a different CCD, so VaM runs exclusively on a CCD, while ignoring SMT cores:
Also reserving the two fastest cores for the unity engine (another tweak I will release soon)
The script (needs to be run in powershell and as admin after vam and steamvr and everything has finished loading)
Code:
# elevate privileges if we are not running as Administrator, so we can set affinity of Windows owned processes
# source: http://superuser.com/questions/108207/how-to-run-a-powershell-script-as-administrator
param([switch]$Elevated)
function Test-Admin {
$currentUser = New-Object Security.Principal.WindowsPrincipal $([Security.Principal.WindowsIdentity]::GetCurrent())
$currentUser.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
}
if ((Test-Admin) -eq $false) {
if ($elevated) {
'tried to elevate to full privileges, did not work, aborting'
} else {
'running my self again with full privileges'
Start-Process powershell.exe -Verb RunAs -ArgumentList ('-executionpolicy bypass -noprofile -file "{0}" -elevated' -f ($myinvocation.MyCommand.Definition))
}
exit
}
'running with full privileges'
# binary: 11111111111111110000000000000000
# means set all processes to core 17-32
$affinity = 4294901760
'setting all processes to affinity: '+$affinity
'processes unable to set affinity of: '
$allProcesses = Get-Process | Where {$_.ProcessName -NotLike "vam"}
foreach ($process in $allProcesses) {
try {
'process: ' + $process
$process.ProcessorAffinity = $affinity
}
catch {
$process
}
}It appears for AMD atleast, that giving VaM exclusive access to a set of cores running on a CCD and banishing all other processes to other cores AND giving the unity main thread the fastest two cores for itself, has the best outcome in VR.
Now I am passing almost all benchmarks for smooth VR:
Last edited:
Hey so I've spent the last couple hours testing different versions, and now I can't get the problem to repeat after going back to the same install and scene and patch version 12. So it seems to have resolved itself. I did restart the PC and clear VAM cache. Oddly enough, I'm not seeing quite the same fps gains now. Its a 2 person (male and female) scene, in VR, man is laying down, POV, female in cowgirl position, and frequent dips into the 60 fps range when shes riding hard. Minimal hair sim too. checked powershell and the dll is loaded. 4090, and 5800X3D, no issues keeping temps down, GPU never above 60, CPU never above 70. Same scene in desktop mode was averaging over 200fps
running the recommended ini settings for my 5800X3D,
[threads]
computeColliders=8
skinmeshPart=8
applyMorphs=8
skinmeshPartMaxPerChar=8
applyMorphMaxPerChar=8
affinity=1,3,5,7,9,11,13,15
[threadsVR]
computeColliders=4
skinmeshPart=1
applyMorphs=2
skinmeshPartMaxPerChar=4
applyMorphMaxPerChar=2
affinity=1,3,5,7,9,11,13,15
[profiler]
enabled=0
I'm about to test your VR workaround. I'll let you know how that goes.
does the script need modifying for my 5800X3D?
