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
>> 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
>> 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
>> 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
>> produce Blender/Unity/3dsMax usable code as well as standalone utilities.
> 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  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
What do you mean by "colliders"? You mean rigid bodies? Or something more
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
> - 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 :)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk