←back to thread

269 points OlympicMarmoto | 1 comments | | HN request time: 0s | source

I discovered this collision detection algorithm during COVID and finally got around to writing about it.

github repo: https://github.com/cairnc/sat_blog

Show context
reactordev ◴[] No.44511689[source]
This is novel indeed! What about non-spherical shapes? Do we assume a spherical bounds and just eat the cost? Either way, narrow phase gets extremely unwieldy when down to the triangle level. Easy for simple shapes but if you throw 1M vertices at it vs 1M vertices you’re going to have a bad time.

Any optimization to cut down on ray tests or clip is going to be a win.

replies(5): >>44511963 #>>44512034 #>>44512617 #>>44512959 #>>44513664 #
andrewmcwatters ◴[] No.44512959[source]
Usually you have a render model and a physical model which is a degenerate version of the viewed object, with some objects tailored for picking up, or allowing objects to pass through a curved handle, etc.

I would assume using this algorithm wouldn't necessarily change that creation pipeline.

replies(1): >>44514423 #
reactordev ◴[] No.44514423[source]
I’m trying to find a way to NOT have hull models included in my games. Saving players potentially GBs of disk space.

Constructing Bvh’s on the fly from the high fidelity models we use. Without incurring a performance penalty like we are. So we can improve collision detection instead of clipping due to low res hull models.

The OP’s source code builds a Bvh but it still does so in a way that we’re able to clog it with 34M vertices. Sadly, we’re still going to have to explode geometry and rebuild a hierarchy in order to iterate over collisions fast. I do like the approach OP took but we both suffer from the same issues.

replies(1): >>44514713 #
1. ◴[] No.44514713[source]