Rebase on Parry rather than ncollide

[clbarnes]

ncollide is in maintenance mode and has been more or less superceded by Parry, from the same developers.

Pros:

• ncollide is in maintenance mode
• parry is a bit more ergonomic for some things
• is_inside may be built in?

Cons:

• parry is less generic (has precision hard-coded)

Questions

• Would this warrant a rebrand?
• Do parry's containment checks for meshes suffer from the same flaw as ncollides, i.e. border containment only?

[aschampion]

My opinions:

Are meshes with ~4.3bn vertices worth thinking about? It would take ~100GB to store such a vertex array.

For any almost other type of data I would say "yes", but for meshes, no, not worth basing decisions on.

f64

Even in cases where we care about f32 (GPU), I still want to do the types of geometric tests ncollpyde does in f64, and would be doing explicit casts anyway, so this is fine (other than perhaps for wasm).

Would this warrant a rebrand?

No, ncollpyde has enough dependencies it's likely not worth it, and part of the point is the people in the Python world not having to care too much what's behind the Rust curtain.

What about wasm?

[clbarnes]

What about wasm?

As in, "let's also do this library in wasm"? Sounds like fun. Probably not a lot of re-usable code/ infrastructure in this library for that as the wrapper is so thin that it's more or less all specific to the python side (~70 lines, plus tests, is the important bit). But it could certainly be an API-inspired-by situation. It looks like parry does support wasm.

[aschampion]

Right, I meant in terms of if one were to want to have a similar library for wasm for frontend (seems likely), it'd be convenient to be backed by the same Rust library to have all the benefits of transferable knowledge, known bugs/validation, etc. So one question is how wasm-ready ncollpyde vs parry are, and another is the suitability of something f64-only for wasm, where the browser memory cap is still a very real and annoying limitation.

Not a necessary criteria for this decision, but a desirable one.

e:

It looks like parry does support wasm.

Neat!

[clbarnes]

ncollide and parry have almost-identical APIs, made by the same people with the same application; parry is practically just ncollide v2 and the authors just didn't want to imply that either was a stable v1.0. Additionally, parry does support f32: it's split into 4 libraries with identical APIs, parry{2,3}d-f{32,64}. Because generics are... annoying, I guess? Or harder to optimise. So such a wasm library could also have that distinction.