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).<p>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?
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.
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: <a href="https://github.com/sebcrozet/ncollide/issues/112" rel="nofollow">https://github.com/sebcrozet/ncollide/issues/112</a>
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: <a href="https://github.com/sebcrozet/nalgebra" rel="nofollow">https://github.com/sebcrozet/nalgebra</a>
Nice. Now we have a 3D collision library in Rust. It may take a while to see how good it is.<p>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.)<p>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.<p>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.<p>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.<p>I used to do this stuff.[1]<p>[1] <a href="https://news.ycombinator.com/item?id=11359181https://news.ycombinator.com/item?id=11359181" rel="nofollow">https://news.ycombinator.com/item?id=11359181https://news.yc...</a>
The site is down and I can't get to Google's cache of it either, but the GitHub project is still up: <a href="https://github.com/sebcrozet/ncollide" rel="nofollow">https://github.com/sebcrozet/ncollide</a>
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.