And what about Entity Query System results? Should it win already?
1 Like
What was the result for Entity Query System?) Iâve read a long topic, and in the final moment, when the question should have been answered, the EQS was checked off⌠Thatâs like not getting to know who is a killer in a detective book man
8 Likes
He left us all hanging, I was reading this thread, and then this ending⌠what a guyâŚ
1 Like
Sorry guys. The post I was replying to was specifically about the physics queries (the discussion had shifted towards which type of physics query was faster), which is why I had the entity query system disabled.
The screenshots in my other posts show a clear trend that the Entity Query System is the fastest:
And there is still my testing package which you can download to try yourself, but likely doesnât work out-of-the-box anymore with the newest Entities package:
1 Like
Reviving old topic;
A single sphere overlap against a single 3D point is pretty fast (3 subs, 3 adds, 3 muls, 1 compare) but still slower than an AABB overlap (3 subs and 3 compares) with a single point.
âŚ
Thatâs the issue with lack of transparency unless you agree to join Unityâs secret club and promise you will be a good boy to never share their code.
What you stated is true in theory (Math operations wise) (If i were to write a C stand-alone unit test); but who knows what shit unity does underneath the hood; no literature provided by them; no computation complexity references; nothing.
and ofcourse the excuse will be that âIt varies per versionâ and âJust profile it manâ.
I donât get you; unity staff / documentation guys, You think if you will provide technical details; someone will steal unity and fork it? (Instead, the user need to run amuck in the dark with the profiler trying to get some information).
*You guys should see the other questions i posted in which i asked for some technical details on the underlying foundation; Unity devs are acting like they are guarding coca-cola recipe.
Yeah itâs hard to tell for sure if the operation counts are exactly what Thygrrr stated, but I think part of his point is that the operation count difference is a drop in the bucket compared to the ability of AABB to discard huge sections of the tree. He wrote âFurthermore, AABB benefits from the BVHâs space partitioning, if something is outside a parent nodeâs X, Y, or Z range (any one is enough), the entire subtree can be discarded. With spherical tests, this is not the case.â
Thatâs a big algorithmic difference that doesnât require a profiler to prove.
You can use spatial partitioning with a sphere. Normally you would use spatial partitioning in the Broad-Phase which would be separate from intersection testing. You can even store your sphere in a AABB if this would be beneficial for your particular implementation of spatial partitioning.
Chapter 32. Broad-Phase Collision Detection with CUDA | NVIDIA Developer.
The code in question is literally shipped to you in plain text in the packages folder.
You didnât need to bump this old thread.
2 Likes
The comparison in this thread was with OverlapSphere() and OverlapAABB(). Are you saying that OverlapSphere() uses spatial partitioning? If so, I was not aware of that. Either way, itâs 4.92x slower according to Cramonkyâs benchmarks, so there is a pretty big difference that likely results from more than just a couple of simple math operations.
Actually, the first post was about comparing an EntityQuery with an OverlapSphere.
@Thygrrr made a number of claims
1: Unity internally wraps a sphere into an AABB. Which makes sence.
2: An AABB test is inherently faster than a Sphere test. Which does not make sence. If you are using spatial partitioning results directly this could be true.
Looking at the code it does not seem like either OverlapSphere or OverlapBox uses spatial partitioning. The code for OverlapAABB just uses Broadphase.OverlapAabb.
Obviously if you are using a spatial partitioning AABB directly depending on the shape and rotation of your collider you can get incorrect results.
An AABB test can be done as part of a hierarchical sweep broadphase algorithm, using a Bounding Volume Hierarchy (BVH)
99.99% of your objects arenât even close enough to one another to matter for an intersect test.
Spheres and other shapes cannot (with this algorithm), as it sweeps along the axes and requires axis aligned bounds.
(Yes, in terms of pure memory bandwidth and calculation speed for one intersection test, a single sphere test is as easy, or even easier, than an AABB comparison. But you never do a single one. You donât even know which ones to do before youâve swept through your space to find anything you would care about.)
AABBs generalize well to all sorts of contained volumes, not just spheres.
You cannot use an AABB test in the general case. Consider an AABB test vs a sphere or anything else. So, a BVH test is not comparable to an intersection test.
Also a single AABB intersection test is not faster then a sphere test. In your earlier post you claim that SIMD makes a AABB test faster.
But⌠I said exactly that? That a single sphere intestect is possibly faster or equally fast as an AABB test (because memory transfer is the real constraint, and an AABB is more data (6 floats) than a sphere (4 floats).
But AABBs can be SIMDâed in a meaningful way for Broadphase sweeps, which pure Sphere tests wouldnât (especially not in a way to do the general Broadphase tests, that drastically cut down on the number of Narrophase - specific intersection - tests the system needs to run.
Also, AABB vs AABB allows some simplifications that allows rejecting many potential candidates early on for cheap, for each dimension.
You still need to do a Narrow Phase with a AABB or you will get lots of wrong results. Of couse you would use spatial partitioning but it is not compareable to an intersetion test. In the narrow phase you will need to do sphere vs AABB. Which is slower then sphere vs sphere.
For checking for explosion damage for example.
Has anyone noticed OverlapSphere returning an absurd number of hits when testing against MeshColliders? My suspicion is that each triangle within the overlap is being returned as a hit. For instance, in a small scene with a few meshes, the output hit array returns the same entity 1800 times.
Edit: Yeah, this seems to be the nature of the casting and overlap testing. Each triangle in a mesh collider is considered a separate object to test against (this makes sense) but it doesnât have any filter to remove duplicate hits when returning them.
One point I wanted to raise is that if youâre doing the same amount of checks per frame (1000) with a overlap check that is big enough to include 20% of the width and 20% of the height of the space, then your test case is biased towards the more brute-force methods, and less towards pruning.
Basically, if your overlap areas are on a big scale compared to your entire world, then you wonât benefit from the âearly outsâ advantage that for example the AABB provides. Or if we consider the extreme case where you literally check the entire world to find the closest entity, you have to do all the shape tests anyway. You canât early out, and an AABB is potentially useless.
However, if youâre looking at closer range, say NPCs looking for targets to melee attack, then the EQS approach is wasting checks on hundreds of entities that might be kilometers away. This is were spatial partitioning is relevant. You just wanna check the 10 enemies in the area, not the 20 000 units spread over the map.
Perhaps better examples are Local Avoidance mechanisms in group movement, like Boids or RVO.