Performance Patch (up to 30% more physics speed)

Seraphim said:

Is this the updated fixed one you posted in benchmark thread, or the original one?

Click to expand...

hijku said:

Maybe even simply changing the condition could help a lot (without going into two lists straight away)?
from
if(!morph.disable)
to
if(morph.active)

Click to expand...

trety said:

Just a question, since i haven't tested v9 yet [last version i tested was v7 back from benchmark thread]... I see you started messing with morphs, and it makes me wonder... If the plugins still will be able to use the morphs which weren't loaded on scene launch? Like Naturalis, Shake it etc?
I just noticed it also makes my local morphs disseapearing. I worked a bit past few days on a model, creating a few versions of hers morph, and once i start VaM it shows only the active morph with hers name. I need to rescan morphs to see the other versions, and no, they're named differently, like 'character name moph', and next one is 'character_m_v2, next 'character_final' etc, it's not VaM 'versioning'.

Spoiler: after scene launch

View attachment 331520

Spoiler: Rescanning

View attachment 331521

All of the morphs were installed since the begining ofc.
Maybe it is on purpose...?

Click to expand...

turtlebackgoofy said:

what version did you use? My patch doesnt remove the morphs, it just prevents the engine from rendering the ones that have a value of 0.0. Does it only happen to local morphs? Can you still see morphs from vars?

Naturalis works as it should. Once a morph has been changed from 0.0 once in the scene, it gets rendered until scene reload. All installed morphs are available in the UI, they are just not applied to the model until they are changed from 0.0 once.
Try it with the newest patched9_morph_clutter_fix2.zip on the first post.

Click to expand...

trety said:

Okay i actually installed yesterday V8 according to files dates. Sorry, thought i'm still at v7.
It hides pretty much all of my local morphs, and as for vars i have no idea what criteria it takes.
My install is very custom, i manually editted and created two versions of 'morphs' packages and i'm switching them between 'play' and 'work' sessions, one with preload turned off and 2nd, with preload on.
Still in my 'play session' i have 950 pages of female morphs [mostly cuz of expressions which are lighter than fully rigged morphs], but with patch i see only 237 pages of totally random morphs.

Well, as long as plugins can 'hot-load' the missing morphs durring a scene play it doesn't bother me much.

/ Edit /
Installed v9_fixed

Spoiler

View attachment 331540

and it's the same. I can see only the part of my morphs from vars and nothing from local files. Reload button in morphs tab is loading the local ones, but still can't see the rest of morphs from vars - guess that the purpose to disable them when no need them. It might be problematic for scenes content creators - if they won't be able to see expression morphs etc.
Like i said it's not a problem for me, if it's stay that way. It seems like i have already 100+ pages of my local morphs [mostly models i made\ported lol] so it might be better if theirs morphs are disabled until i actually need them. And since i can quickly load them up via in game reload button, for example when starting new model with brand new morphs, it's all fine.

Click to expand...

turtlebackgoofy said:

how do I create local morphs so I can test the bug?

Click to expand...

giallone said:

You can just take a morph from a .var and copy it into the appropriate folder in \Custom\Atom\Person\Morphs\Female (or the others if is a genital or male morph)...
It will appear in your morphs list with blue background after a "reload custom morphs" or restarting VaM

Click to expand...

trety said:

So... uhm, i'm sorry but seems like i was blind lol
Like i said my install is pretty well tuned 'for play' without morphs bloat effect and... i have only 350 pages, not 950 as i said before.
I'm using 4K TV, and started Vam at windowed 1080p for testing and seems like i can't even read properly lol. Sorry.
So the 'issue' was only with local morphs, which is now fixed with v9_fix3.

And it's now makes me wonder... if it's possible to make it toggleable in ini? I know you just reverted it, but it might actually benefit havin local morphs 'on demand' for people like me, with many of them. I thought it affects them in vars too, and thats why i even started this, if i knew it was really just for local ones i wouldn't even say anything in regard of this QQ

Click to expand...

turtlebackgoofy said:

However what DOES benefit is not RENDERING morphs while they are loaded, but werent changed yet. This behaviour is now included in the newest version you just ran.

Click to expand...

beme said:

what are you guys setting in the INI file for an i9-13900k?

based on raw thread count I set mine like this

[threads]
computeColliders=24
skinmeshPart=1
CCD=0
IterateCCD=0

Not seeing any gains on my system...

Click to expand...

FapperGOD said:

Can I set CCD to 0 in skinmeshpartdll.ini if I have an AMD 5600X with two CCDs?
One is disabled and only CCD2 is functional.
Also what skinmeshpart value should I use?

Click to expand...

meshedvr said:

Thanks for doing this!

I mentioned on the other thread as well before I realized you had a dedicated one. We reached out to you to see ask to move this to resources where we can flag it for providing a replacement dll.

I considered rewriting the morph iteration code you mention but unfortunately there were some complexities in doing so that I couldn't easily address with the time I had. VaM2 has already fixed this by morphs registering changes to their values on-demand. Event driven. That way the iteration is only done on morphs that changed that frame. Also VaM2 is using Unity's new Burst and Jobs system with better memory structs for the code that is most demanding. VaM2 also doesn't support morph-controlled-morphs or formula morphs which is the cause of some of the extra possible iterations in the morph code.

I appreciate your effort to make the original VaM more performant. In the other thread I also mentioned you are sometimes fixing things that are running on a side thread and would typically complete before the main thread needed the data. But I suppose on some CPUs it is not able to so the main thread waits on that side thread to complete and lowers overall FPS. I spent most of my time trying to optimize main thread code as that is generally where the bottleneck is.

Click to expand...

1) (side threads) doing float point math like in SkinMeshPart is a lot faster if you compile the same operations with native SSE2/AVX2 instead of doing them in C# IL

Click to expand...

2) disabling your threaded skinmeshing and instead letting the .dll do the thread management natively is faster.

Click to expand...

3) if skinmeshing is already very fast you can skip the threading altogether, it also fixes the bug where skinmeshes flop around for a few frames, because you processed the vertexes in the wrong operation order, you already tried to mitigate it by splitting the threads not by bones but by vertexIDs, but some vertexes are shared between bones and those can spazz out

Click to expand...

4) (main thread 0) if you call a lot of unity engine methods like getPosition or getTransform, its faster to call them directly from native->native using their native names internalcall_XXXX instead of C#->native, because every C#->native transition costs a lot of CPU. ComputeColliders did those 100k times per frame, this was the biggest performance gain.

Click to expand...

5) (all threads) setting core affinity for the process, making sure the code stays on one CCD so all threads share a highspeed CPU cache. This is basicaly free performance on top and should be configurable for advanced users

Click to expand...

I know it will be fixed in VAM2, but it only took half an hour patching it using dnspy

Click to expand...

Another performance patch was to mark dazmorphs as "touched" once appliedValue or morphValue was set via the setters and to add them to a seperate list in their corresponding morphbank, so that on every frame in ApplyMorphsThreadedFast() only those in the "touched list" get iterated. Otherwise you iterate all installed morphs, eventhough they are at 0.0 and while it looks harmless in terms of operations wasted, it pollutes the CPU cache heavily.

Click to expand...

meshedvr said:

Thanks for doing this!

I mentioned on the other thread as well before I realized you had a dedicated one. We reached out to you to see ask to move this to resources where we can flag it for providing a replacement dll.

I considered rewriting the morph iteration code you mention but unfortunately there were some complexities in doing so that I couldn't easily address with the time I had. VaM2 has already fixed this by morphs registering changes to their values on-demand. Event driven. That way the iteration is only done on morphs that changed that frame. Also VaM2 is using Unity's new Burst and Jobs system with better memory structs for the code that is most demanding. VaM2 also doesn't support morph-controlled-morphs or formula morphs which is the cause of some of the extra possible iterations in the morph code.

I appreciate your effort to make the original VaM more performant. In the other thread I also mentioned you are sometimes fixing things that are running on a side thread and would typically complete before the main thread needed the data. But I suppose on some CPUs it is not able to so the main thread waits on that side thread to complete and lowers overall FPS. I spent most of my time trying to optimize main thread code as that is generally where the bottleneck is.

Click to expand...

public void LoadDeltasFromBinaryFile(string path)
    {
        try
        {
            using (FileEntryStream fileEntryStream = FileManager.OpenStream(path, true))
            {
                using (BinaryReader binaryReader = new BinaryReader(fileEntryStream.Stream))
                {
                    this.numDeltas = binaryReader.ReadInt32();
                    this.deltas = new DAZMorphVertex[this.numDeltas];
                    int num = 16;
                    using (MemoryStream memoryStream = new MemoryStream(binaryReader.ReadBytes(this.numDeltas * num)))
                    {
                        using (BinaryReader binaryReader2 = new BinaryReader(memoryStream))
                        {
                            for (int i = 0; i < this.numDeltas; i++)
                            {
                                DAZMorphVertex dazmorphVertex = new DAZMorphVertex();
                                dazmorphVertex.vertex = binaryReader2.ReadInt32();
                                Vector3 vector;
                                vector.x = binaryReader2.ReadSingle();
                                vector.y = binaryReader2.ReadSingle();
                                vector.z = binaryReader2.ReadSingle();
                                dazmorphVertex.delta = vector;
                                this.deltas[i] = dazmorphVertex;
                            }
                        }
                    }
                }
            }
        }
        catch (Exception ex)
        {
            Debug.LogError(string.Concat(new object[] { "Error while loading binary delta file ", path, " ", ex }));
        }
    }

turtlebackgoofy said:

Otherwise you call the zip library 4 times per delta per numDeltas, which results in 100k calls and 100k small reads from the disk. This removes lag in scenes with prerecorded animations.

Click to expand...

        public void LoadDeltasFromBinaryFile(string path) {
                //Debug.Log("Loading deltas for morph " + morphName + " from "+path);
                try {
                        using (FileEntryStream fes = FileManager.OpenStream(path, true)) {
                                using (BinaryReader binReader = new BinaryReader(fes.Stream)) {
                                        numDeltas = binReader.ReadInt32();
                                        deltas = new DAZMorphVertex[numDeltas];
                                        for (int ind = 0; ind < numDeltas; ind++) {
                                                DAZMorphVertex dmv = new DAZMorphVertex();
                                                dmv.vertex = binReader.ReadInt32();
                                                Vector3 v;
                                                v.x = binReader.ReadSingle();
                                                v.y = binReader.ReadSingle();
                                                v.z = binReader.ReadSingle();
                                                dmv.delta = v;
                                                deltas[ind] = dmv;
                                        }
                                }
                        }
                }
                catch (System.Exception e) {
                        Debug.LogError("Error while loading binary delta file " + path + " " + e);
                }
        }

Yeah I can imagine. This is essentially what VaM2 does with new skinning and morph engine (using Unity Jobs system). I would have loved to do that for VaM but I had to move on to VaM2.

Click to expand...

I'm not quite sure what you mean there. The subthreads of the skinning all write to consistent vertex array and then that array is not used until all subthreads are complete. Something doesn't sound right here.

Click to expand...

I'm curious what you used for profiling. VaM was only optimized using Unity's profiler on several different testcases, and without moving to native calls there was limited amount of things that could be done. Unity doesn't allow accessing native methods without making a C-based plugin. It is a bit of a pain. I guess you did that though.

Click to expand...

BepInEx.Debug/src/SimpleProfiler at master · BepInEx/BepInEx.Debug

Tools for debugging and developing BepInEx plugins - BepInEx/BepInEx.Debug

github.com

That is how VaM2 works, but on VaM we have morphs that can modify other morphs values and I believe it doesn't work correctly with what you describe.

Click to expand...