Page 1 of 1

v2 documentation suggestion

Posted: Fri Jan 25, 2019 10:52 am
by KakCAT
Hi,

The main page of bepu2 github describes the features of the beta, what contains and what doesn't.
I think it'd be really useful if you included a small section about what is already implemented in the master branch (or not even a section, just an asterisk and saying that features marked as asterisks are already implemented in the master branch)

In example, I'm waiting for convex hulls, mesh-mesh detection and some samples of a character controller (I just noticed there's one already) to move to V2. This way users could know if all the features they need are available, and start/move to v2 instead of v1 without having to browse through the commits and code.

Thanks!

Re: v2 documentation suggestion

Posted: Fri Jan 25, 2019 8:02 pm
by Norbo
I've been intending to update it, just haven't got around to it. I suppose I can update it more than once every 5 months :P
I'm waiting for convex hulls, mesh-mesh detection and some samples of a character controller (I just noticed there's one already) to move to V2.
Incidentally... convex hulls aren't in yet, but mesh-mesh exists now. Mesh-mesh sweep-based CCD technically doesn't, though. But as per the tips, I always strongly recommend alternatives (like an approximate convex decomposition of the mesh).

Re: v2 documentation suggestion

Posted: Wed Jan 30, 2019 9:52 am
by KakCAT
thanks for the answer :) The idea of the feature request is knowing when convex hulls area ready without pinging you and making you lose time :)

Yes, I try to use spheres, boxes and simple shapes but very often I find it impossible to decompose an object and I resort to using convex hulls a lot.

One question though, what is the difference between a mesh and a convex hull in bepu/physics? I've been using them as synonyms, but reading your answer makes me think I have the wrong concept in my head.

Thanks!

Re: v2 documentation suggestion

Posted: Thu Jan 31, 2019 12:38 am
by Norbo
One question though, what is the difference between a mesh and a convex hull in bepu/physics? I've been using them as synonyms, but reading your answer makes me think I have the wrong concept in my head.
Meshes are an arbitrary collection of triangles. They can represent any surface, including concave shapes, but do not have any volume. The triangles are infinitely thin. They use a tree to accelerate identifying which triangles are involved in a collision, so they're suitable for things like level geometry with many thousands of triangles.

(v1 supported solid meshes, but they were slow and I always recommended against their use. v1 triangles were also not quite infinitely thin- all shapes had margins. v2's choice to be more 'accurate' here actually makes mesh-mesh collisions work less well; two infinitely thin surfaces will have a hard time staying in contact.)

Convex hulls, in technical terms, are solid volumetric regions formed by the intersection of several halfspaces. Any point contained in the convex hull's volume is on the same side of every (hyper)plane that defines the surface of the hull. A more intuitive way to think of this is to take a set of points and shrink wrap it: https://en.wikipedia.org/wiki/Convex_hu ... exHull.svg

A single convex hull, by virtue of being convex, cannot represent a hollow object or any other form of concavity. In most cases, the performance of convex hull collision detection is sensitive to the complexity of the hull; having a many-faceted surface will tend to be more expensive. Most engines recommend that the complexity be kept pretty low for performance (or they explicitly constrain the number of points/facet detail). In other words, using a convex hull to represent a near-perfect sphere would be rather wasteful. (It's possible to make convex hulls reasonably quick, though- often, engines will not bother supporting implicit cylinders in favor of just using detailed convex hulls.)

Convex hulls will massively outperform meshes for low surface complexity. Because of that and the fact that convex hulls actually have volume, complex dynamic objects are best represented by compound shapes of multiple simplified convex hulls (or even simpler implicit shapes like spheres and boxes) rather than a mesh.

Re: v2 documentation suggestion

Posted: Mon Feb 18, 2019 7:09 pm
by KakCAT
thanks for the answer, it's pretty clear now. I've been using the mesh term incorrectly.

Is there a planned specialized terrain in v2 (like BEPUphysics.BroadPhaseEntries.Terrain) or should I be using Meshes for terrain? (I haven't read anything about terrains in the roadmap)

Re: v2 documentation suggestion

Posted: Tue Feb 19, 2019 12:38 am
by Norbo
I cut heightmap based terrains from the first release since they're a pretty minor optimization over a Mesh. They will probably show up eventually, but I'm not sure when. Until then, Mesh is the way to go.