Re: [boost] [gsoc-2013] Physics Library Abstraction Layer

Subject: Re: [boost] [gsoc-2013] Physics Library Abstraction Layer
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-04-12 00:28:26

On Thu, Apr 11, 2013 at 8:30 PM, Michael Marcin <mike.marcin_at_[hidden]>wrote:

> Preston Hamlin wrote:
>
>> Hello, my name is Preston Hamlin and I am a current CS undergraduate at
>> the
>> Florida State University.
>>
>> I was reading over the list of ideas provided and then referenced the
>> source code libraries to get a feel for what was being asked for.
>>
>> I found the prospect of writing an abstraction layer for PhysX or related
>> libraries to be interesting. I am somewhat familiar with THREE.js which is
>> an abstraction of WebGL. In THREE.js there is a heavy amount of
>> abstraction
>> to the degree of providing geometric primitives, particles effect presets,
>> simple materials and basic data structures (matrices, vectors, etc...).
>> Given the platform that THREE.js operates on, such a degree is
>> understandable. How much of the physics library is to be abstracted away
>> in
>> generic structures and functions?
>>
>> I would think that having a few simple primitives (cube, low-poly sphere,
>> etc...) would be required since they are commonly used. However more
>> advanced meshes like a torus might be better produced through using
>> modifiers on said primitives rather than a built-in preset. I think the
>> degree of abstraction is most important for modifiers, and I desire to get
>> a feel for what is being looked for. I assume the end goal is to be able
>> to
>> produce Blender/Unity/3dsMax usable code as well as standalone utilities.
>>
>>
> Hello,
>
> Cheers to you for choosing an interesting and, IMO, challenging topic.
>
> PhysX, Havok, Bullet, ODE, Newton are some good libraries to take a look
> at and perhaps see if you can lift shared Concepts from.
>

I would throw PhysBAM [1] in there as well; it probably has a more academic
/ research flavor (and as such it should only be viewed as a reference or
alternative, and not necessarily a model design or implementation).

I would expect something to provide a handful of colliders out of the box
> and support extension for supporting user defined colliders through proper
> Concept(s).
>

What do you mean by "colliders"? You mean rigid bodies? Or something more
general?

Unity for example provides:
>  - BoxCollider
>  - SphereCollider
>  - CapsuleCollider
>  - MeshCollider
>  - TerrainCollider
>  - WheelCollider
>
> PhysX provides:
>  - sphere
>  - box
>  - capsule
>  - plane
>  - heightfield
>  - convex
>  - triangle mesh
>
> Bullet supports slightly more:
>  - btSphereShape
>  - btBoxShape
>  - btCylinderShape
>  - btCapsuleShape
>  - btConeShape
>  - btMultiSphereShape
>  - btConvexHull
>  - btConvexTriangleMeshShape
>  - btBvhTriangleMeshShape
>  - btHeightfieldTerrainShape
>  - btStaticPlaneShape
>  - btCompoundShape
>
> To answer your question directly I think a good usable starting set would
> be:
>  - Box
>  - Sphere
>  - Capsule
>  - Plane
>  - Convex Polyhedron
>
> You could probably easily represent all of those in any physics backend.
>

This sounds like you're focusing the scope of this on rigid body
simulations, which is fine, just that, ya know, there's quite a bit more to
physics simulation engines :)

[1] http://physbam.stanford.edu/