
Ncollide – 2D and 3D collision detection library - brson
http://ncollide.org/
======
codehero
Sell me: I am a crusty old C++ programmer who started numerical and geometric
programming on an SGI machine at the turn of the century. I have seen many
academic and commercial 3D libraries come, go or perform poorly (vcollide,
RAPID, CGAL and many proprietary ones).

It looks interesting but what makes this library any better than what's come
before? Why should I learn Rust to use it or really for any computational
geometry problem?

~~~
webkike
I'm not sure. I certainly would never use a third party collision library
because I think collisions are simple enough, but on the larger subject of
whether Rust is suitable for game programming; I think so, but cannot confirm.
There are a lot of abstractions that require pointer dereference, which is
somewhat likely to give you a performance drain, and those abstractions are I
guess somewhat harder to avoid than in C++, but not terribly so. Both
languages give you the ability to do "data directed design" if you really
really want to. My preference for Rust stems from my preference for
interfaces, or traits as they are called in Rust. If you want to use features
like these then Rust is a no brainer. I have yet to see the true impact on
performance these abstractions have however.

~~~
santaclaus
> I certainly would never use a third party collision library because I think
> collisions are simple enough

Ehhh, I haven't seen a really good, super robust solution for mesh vs. mesh.
Deciding whether two meshes collide is simple enough, but robustly pulling out
associated information like overlap volumes, penetration depths, etc gets
pretty hairy pretty quickly - you start running into similar problems to mesh
booleans.

~~~
webkike
The reason why is that mesh vs mesh essentially should never be used in video
games. The accuracy in hitbox bounds and ease of use (making a model mesh your
collision mesh) you get from mesh collisions are completely and utterly
overshadowed by the performance and lack of accuracy in determining the time
of impact. At 60 fps it's really hard to tell the difference in collision
between a typical dodecahedron and a sphere. Just use a sphere! (Or, more
likely, some aggregate of AABBs, spheres and capsules)

~~~
santaclaus
Oh yea, for a game I would almost certainly decompose into some sort of union
of easily handled convex shapes. There are definitely applications --
robotics, engineering, hell, even film -- where more accurate mesh-mesh is
needed, however, and most solutions are super domain specific and ad hoc.

~~~
webkike
Haha, I keep forgetting that there are other applications for collision
detection than just video games :)

------
webkike
It's a neat project, but ultimately I don't think I'll be replacing my own
collision library any time soon. I should write a blog post about this, but
basically it boils down to not having enough support for accurate toa
collisions for capsules. You can have exact toa collisions for essentially any
exact toa collision you can have with spheres, one of the reasons capsules are
such a great tool for making hitboxes. As far as I can tell this library does
not support that.

~~~
willvarfar
Please do write that blog post and, if possible, release your code :)

I struggled so long and basically put my hobby game on ice after failing to
sort out capsule plane collisions! :(

What language is your own library in?

~~~
webkike
My collision code is in Rust, actually. Pretty funny.

Capsule-plane collisions are pretty simple, simple enough that I can outline
here. The first thing you want to do is find the sphere on the capsule to
perform the test on, call this time t_X. Create a line from the segment
(starts at t_0, ends at t_1) bounding the capsule and determine its
intersection point with the plane. If there is no intersection, just set t_x
to mean(t_0, t_1), or halfway on the capsule's segment. If there is an
intersection, and the time is between t_0 and t_1, set t_x to that time.
Otherwise clamp it between t_0 and t_1. Now you have a sphere and a position
(the time t_x on the capsule segment), and you can perform a moving sphere -
plane collision. This algorithm works because the premise - the point on a
capsule closest to a plane will always get closer to the plane, unless the
capsule is moving away - is sound, as far as I can tell.

~~~
tricolon
> the point on a capsule closest to a plane will always get closer to the
> plane, unless the capsule is moving away

What if the capsule is spinning like a boomerang while moving toward the
plane?

~~~
webkike
For real time collision detection it is sufficient to rotate an object after
you have applied linear motion and collision. If you want the rotation to be
more accurate you have to divide the timestep.

------
viperscape
This library is sort of rough as you delve deeper, for instance mesh data gets
put into an Arc, which in Rust terms is read only and thread safe but doesn't
seem to belong in the library in my opinion because something simple like
scaling a mesh is complicated now:
[https://github.com/sebcrozet/ncollide/issues/112](https://github.com/sebcrozet/ncollide/issues/112)
There are some other quirks I found like trying to store sphere colliders in a
hashmap but found I instead need to store the Point type explicitly which
wasn't obvious at first. Overall I think the library is good but needs more
work, and an abstraction to work with space partitioning would be nice, even
if it was in a different library or module. I wish I could offer help, this is
definitely a good project. The sister library nalgebra is fantastic in my
opinion, great linear algebra library:
[https://github.com/sebcrozet/nalgebra](https://github.com/sebcrozet/nalgebra)

------
Animats
Nice. Now we have a 3D collision library in Rust. It may take a while to see
how good it is.

I notice that they have decomposition of non-convex objects into a union of
convex objects. That's very useful. Convex polyhedron vs convex polyhedron is
very fast, only slightly worse that constant time for repeated tests on moving
objects. (GJK is the preferred convex vs convex test.)

Mesh vs mesh is generally slow, although there are "polygon soup" systems that
just compare triangles and understand no higher structure. Meshes are not
necessarily solids; collision detection is better for things which are
definitely solids. Other objects vs. height field is very useful in games;
that's what you use for terrain.

Collision detection which drives a non-trivial physics system has to have
certain properties. It helps a lot if the forces are differentiable against
object movement. If there are infinitesimal movements which result in
discontinuous changes in forces, physics models won't work right. This causes
such artifacts as objects lying on the ground which vibrate. The closest point
vector is shifting from corner to corner as two planes come into parallelism.
It's static indeterminism in action. The solution is a multi-point contact
model, where you have several closest point vectors with distances, and
compute forces for each point of support. If you have at least three,
stability is possible. If you're working on legged locomotion, and care about
foot/ground contact and friction, you need that.

Ncollide's videos look good. Although check the first one where the balls fall
into a cone. At the top, there's one ball perched stably on top of another
ball.

I used to do this stuff.[1]

[1]
[https://news.ycombinator.com/item?id=11359181https://news.yc...](https://news.ycombinator.com/item?id=11359181https://news.ycombinator.com/item?id=11359181)

~~~
santaclaus
> It helps a lot if the forces are differentiable against object movement. If
> there are infinitesimal movements which result in discontinuous changes in
> forces, physics models won't work right.

There are models of non-smooth interactions that get used in mechanics,
graphics, and robotics - I'm thinking Baraff and Moreau and Stewart and
Trinkle type stuff. You end up with dynamics formulated as differential
inclusions, but it all still works out.

~~~
Animats
Baraff-type impulse-based collisions occur in zero time, which is why objects
banging around in games look too light.

~~~
santaclaus
Impulse based collisions look great, I've seen some amazing cloth and hair
simulations using impulse based methods. Impulse based methods are used all
over the place in geomechanics, where they can pretty accurately reproduce
stress fields in avalanches, etc. I think there is something else going on
making game objects look too light.

------
mrec
The site is down and I can't get to Google's cache of it either, but the
GitHub project is still up:
[https://github.com/sebcrozet/ncollide](https://github.com/sebcrozet/ncollide)

~~~
steveklabnik
Seems to be up for me. If it's still down for you, that's really unfortunate:
one of the reasons this link was submitted (I'm assuming) is that they just
got a brand new site, and it's pretty great!

~~~
mrec
Hmm, interesting. It was still down (everything just timing out) an hour ago
from work, but it's fine and snappy now from home. Maybe the corp firewall is
blocking it for some reason.

------
joeld42
Rust is C-linkable, right? How hard would it be to use this from C?

~~~
codehero
Why use this library when similar libraries implemented in C have been in
production for decades?

~~~
warmwaffles
What C library is there that I can use? I don't want a C interface to Bullet.

------
Hondor
If only somebody would do collision (contact) for elastic bodies with the
range of scales and accuracy needed for finite element analysis. As far as I
know, this is something that nobody's achieved yet. Users have to manually
tweak parameters to prevent parts from intersecting each other too much,
bouncing off unphysically or the solver just failing to converge.

