blazing karma
is there an update to this? Ive also been experiencing what the forum thread poster had been(https://forum.unity.com/threads/in-43792-parallelcreatecontactsjob-bad-performance.1447642/#post-9075916) namely the job seems bottlenecked to one thread. I havent really taken a deep look but was wondering for more information on either a potential fix or ways to mitigate it
@sick gust
sick gust
Hi @blazing karma .
We are looking at this issue at the moment.
Note that generally it is expected that there is only one processing worker thread in a case where only one pair of colliders exists. The parallelization currently distributes the pairs across worker threads.
In the forum post, the issue is that the time consumption for processing this one pair is very high.
In your case, do you also experience high processing time for a single pair of colliders with overlapping axis aligned bounding boxes?
sick gust
Update: the issue in the forum post was on the authoring side.
The problem was that a way too high resolution mesh collider was created leading to an excessive time consumption in the middle phase of the mesh collider (a bounding volume hierarchy) during which candidate triangles for collision are identified which are then actually tested for intersection with the other collider (the convex mesh in this case). Due to the excessive number of triangles to process in this case, the time spent on this process was way too high.
The issue can be worked around as explained in my post in the forum here: https://forum.unity.com/threads/in-43792-parallelcreatecontactsjob-bad-performance.1447642/#post-9208959
blazing karma
so I assume it was something similar, prototyping some level design with probuilder results in everything being meshcolliders, and the perf of the resulting meshcolliders(a large quantity, but in general not really complex compared to the model in that thread). switching over to convex hulls fixed the perf issue but Im still seeing one thread on the parallel job that is double the rest of the workers, though performance overall is vastly improved.
i think though this should still be an area of concern - blocking out some low res shapes quickly with probuilder and leaving meshcolliders will always result in a gradually more and more bottlenecked worker thread situation so I can see a lot of other people running into this as dots gets greater adoption
sick gust
I see. Mesh Colliders are generally the slowest among the Unity Physics colliders. Since ProBuilder is commonly used for prototyping and blocking out only, I assume it is clear that some optimization work will still be required afterwards. But I can understand that this is a nuisance.
In regards to work balancing, if the number of collider pairs is large enough, the work balancing should be ok unless there is a pair that requires a significantly longer time to process (e.g., a very complex mesh in the pair).
So I am wondering in what situation you were in when observing this issue. Was it a small number of pairs of colliders overlapping in the broadphase (see broadphase option in the debug display component) or a large number?
blazing karma
was a larger number of not very complex (mesh) colliders, I think this weekend Ill try to remake the scenario
blazing karma
im also genuinely curious how havok performs with caching, i assume maybe due to the stateless nature of unity physics and physx meshcolliders typically being static might have some bearing on things?
sick gust
The contact generation function for mesh/mesh is simply quite costly. If you use convex meshes it will be faster, however, we currently don't do any kind of warmstarting internally for the GJK algorithm for simple stateless-ness in Unity Physics, giving an edge to Havok in terms of performance for many convex meshes colliding. We might look into remedying this in the future though.