Is there any way to use physics colliders without game objects for pure math testing?

Hello

I want to do some collision tests based on geometry defined by math rather than physical game objects, I would like to use colliders by querying them as if they were throw away structs that are not in the game world, is this possible at all?

I don't like that physics colliders have to be tied to actual monobehaviours and classes when i need quick physics checking....

 

Would be nice if we could have one though because writing libraries for things that could be plucked out of physics systems as a stand alone library feels bit unproductive when trying to make games, so far making my game has actually been 90% writing libraries before i can even write the game code which is annoying.

It would also be nice to have access the octree/quadtree map that the physics system uses for sparse distribution of objects for general use of things rather than it being purely locked to colliders only.

For example having an Octree available to coincide with the Bounds struct would be very helpful. But i have to write my own even though the physics system already uses one seems a bit reinventing the wheel.

 

Closest thing Unity has if you're not using asset store or open source are DOTS physics. This comes with source and is mostly query based, co developed by the people at havok.

 

Will that work with regular unity setup or will everything have to use ECS and the DOTS tech? I've tried to understand whats going on between ECS, Burst/Job and Unity.Physics and its very confusing to follow at the moment and kind've hard to adopt any of them into a project and know what i am doing lol.

 

Yeah it'll work but you'd need to bridge mono land with the physics land yourself.

Thing is I use built in Physx all the time for queries. It's very fast and efficient, and I don't know of any queries I'm missing. I've been using it for a decade so maybe you can tell me what you're actually missing?

Well there's an octree on Unity's github they fork and use. Physx has it's own internal octree that any form of sweep or raycast will use, and this is updated by you manually (you can have a physx "scene" that's independent just for queries) and so on, and you can update that independently or even just query in the main scene.

I think you should dig deeper or clarify the needs.

 

Shapes defined by splines as their perimeter which is hard to do using the basic primitives given so I wrote my own mathematical descriptions of more primitives.
Now writing my own Ray tests, intersecting and overlapping tests.

They don't represent actual meshes in scene they are custom shaped volumes for me to do effects in. Plus side is I don't need to make game objects and collider components as added overhead. It's all written in structs for simd optimisation..

Have to write my own octree though since unity won't expose theirs used for their colliders. Hate reinventing the wheel when unity already uses one but won't expose the api to use it.

 

I see, I have used similar for my splines and AI edge lists. Unity uses this as it's well integrated with Unity with bounds etc:

https://github.com/Nition/UnityOctree (original)
https://github.com/Unity-Technologies/UnityOctree (Unity's fork)

(I actually do wish Unity would have a highly performant Unity-centric gc-free octree built in as it's essential to all games at some point, those that are of any scope at least).

 

I can probably edit these to make mine be more performant for my library but yeah theres a lot of basic things that needs to be abstracted and exposed for us to use unless you pay for assets which I don't like because support for assets could get cut at any moment.