[gsoc-2013] Physics Library Abstraction Layer
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. Many thanks, -Preston
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 expect something to provide a handful of colliders out of the box and support extension for supporting user defined colliders through proper Concept(s). 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.
On Thu, Apr 11, 2013 at 8:30 PM, Michael Marcin <mike.marcin@gmail.com>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/
Jeffrey Lee Hellrung, Jr. wrote:
What do you mean by "colliders"? You mean rigid bodies? Or something more general?
Sorry my physics is a bit rusty, I'm not sure. A rigid body in Unity at least (which uses PhysX under the hood) typically has a collider. http://docs.unity3d.com/Documentation/Manual/Physics.html I believe collision primitives is what most libraries call what I was talking about. See newton for instance: http://newtondynamics.com/wiki/index.php5?title=Collision_primitives
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 :)
Indeed. I've never heard of physbam before but looking over it I think it has a similar set of abstractions to most of the other physics libraries I've come across. Formalizing these shared aspects into concepts and creating an elegant interface with multiple backend bindings is what I would hope a boost physics library would accomplish.
On Thu, Apr 11, 2013 at 9:48 PM, Michael Marcin <mike.marcin@gmail.com>wrote:
Jeffrey Lee Hellrung, Jr. wrote:
What do you mean by "colliders"? You mean rigid bodies? Or something more general?
Sorry my physics is a bit rusty, I'm not sure.
A rigid body in Unity at least (which uses PhysX under the hood) typically has a collider. http://docs.unity3d.com/**Documentation/Manual/Physics.**html<http://docs.unity3d.com/Documentation/Manual/Physics.html>
I believe collision primitives is what most libraries call what I was talking about. See newton for instance: http://newtondynamics.com/**wiki/index.php5?title=**Collision_primitives<http://newtondynamics.com/wiki/index.php5?title=Collision_primitives>
Ah, okay.
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 :)
Indeed.
I've never heard of physbam before but looking over it I think it has a similar set of abstractions to most of the other physics libraries I've come across.
Formalizing these shared aspects into concepts and creating an elegant interface with multiple backend bindings is what I would hope a boost physics library would accomplish.
Hmmm...this sounds like you have something similar to Boost.Multiprecision in mind. Is that accurate? - Jeff
On 4/12/13 12:44 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Thu, Apr 11, 2013 at 9:48 PM, Michael Marcin <mike.marcin@gmail.com>wrote:
Formalizing these shared aspects into concepts and creating an elegant interface with multiple backend bindings is what I would hope a boost physics library would accomplish.
Hmmm...this sounds like you have something similar to Boost.Multiprecision in mind. Is that accurate?
I've not used Multiprecision but looking over the intro docs yes very much so. Also Boost.MPI is very similar to what I'm talking about. Specifically from the MPI docs. Boost.MPI is not a completely new parallel programming library. Rather, it is a C++-friendly interface to the standard Message Passing Interface (MPI), the most popular library interface for high-performance, distributed computing. MPI defines a library interface, available from C, Fortran, and C++, for which there are many MPI implementations. Although there exist C++ bindings for MPI, they offer little functionality over the C bindings. The Boost.MPI library provides an alternative C++ interface to MPI that better supports modern C++ development styles, including complete support for user-defined data types and C++ Standard Library types, arbitrary function objects for collective algorithms, and the use of modern C++ library techniques to maintain maximal efficiency. Obviously not exactly the same. MPI is standardized and there is no standard physics api that I'm aware of.
On Fri, Apr 12, 2013 at 12:53 AM, Michael Marcin <mike.marcin@gmail.com>wrote:
On 4/12/13 12:44 AM, Jeffrey Lee Hellrung, Jr. wrote:
On Thu, Apr 11, 2013 at 9:48 PM, Michael Marcin <mike.marcin@gmail.com
wrote:
Formalizing these shared aspects into concepts and creating an elegant interface with multiple backend bindings is what I would hope a boost physics library would accomplish.
Hmmm...this sounds like you have something similar to Boost.Multiprecision in mind. Is that accurate?
I've not used Multiprecision but looking over the intro docs yes very much so. Also Boost.MPI is very similar to what I'm talking about.
Specifically from the MPI docs.
Boost.MPI is not a completely new parallel programming library. Rather, it is a C++-friendly interface to the standard Message Passing Interface (MPI), the most popular library interface for high-performance, distributed computing. MPI defines a library interface, available from C, Fortran, and C++, for which there are many MPI implementations. Although there exist C++ bindings for MPI, they offer little functionality over the C bindings. The Boost.MPI library provides an alternative C++ interface to MPI that better supports modern C++ development styles, including complete support for user-defined data types and C++ Standard Library types, arbitrary function objects for collective algorithms, and the use of modern C++ library techniques to maintain maximal efficiency.
Obviously not exactly the same. MPI is standardized and there is no standard physics api that I'm aware of.
Hmmm...I guess 2 concerns I have are 1) What is lacking in present APIs that a Boost-style interface would provide? and 2) The design itself of such a system could easily be a summer's work, much less any start on the implementation, so I think it might be hard to sufficiently limit the scope of this project to within a summer while still defining a coherent result. - Jeff
Hmmm...this sounds like you have something similar to Boost.Multiprecision in mind. Is that accurate?
- Jeff
Hi Jeff, nice to hear from you. I believe the OP has more application-specific stuff in mind. But Preston, if you are interested in the raw beauty of generic big numbers and the special functions of pure and applied mathematics, you might want to look at our GSoC project with Multiprecision. It might be easier to get a start with that project than to try and roll your own proposal. Perhaps you could make your own proposal as a second step in Boost. Sincerely, Chris.
participants (4)
-
Christopher Kormanyos -
Jeffrey Lee Hellrung, Jr. -
Michael Marcin -
Preston Hamlin