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

Subject: [boost] [gsoc-2013] Physics Library Abstraction Layer
From: Preston Hamlin (prestonwhamlin_at_[hidden])
Date: 2013-05-03 11:10:16

On Sun, Apr 21, 2013 at 9:37 PM, Michael Marcin <mike.marcin_at_[hidden]>wrote:

> On 4/19/2013 8:59 PM, Preston Hamlin wrote:
>
>>
>> I have completed a draft proposal and would appreciate some feedback:
>>
>> https://www.dropbox.com/s/**7xhha0a3ahk5p6r/preston_**
>> hamlin_gsoc_proposal_draft.pdf<https://www.dropbox.com/s/7xhha0a3ahk5p6r/preston_hamlin_gsoc_proposal_draft.pdf>
>>
>>
>>
> Seems like a fine proposal.
>
> Do take note of boost coding guidelines.
>
> --
> Use the naming conventions of the C++ Standard Library (See Naming
> conventions rationale):
>
> * Names (except as noted below) should be all lowercase, with words
> separated by underscores.
> * Acronyms should be treated as ordinary names (e.g. xml_parser instead of
> XML_parser).
> * Template parameter names begin with an uppercase letter.
> * Macro (gasp!) names all uppercase and begin with BOOST_.
> --
>
> http://www.boost.org/**development/requirements.html#**Guidelines
>

>
> Prefer object interfaces to pointers.
>
> For example instead of:
> bxPhysics* physics(___);
>
> prefer:
> boost::physics::physics physics_(____);
>
> Although on second thought naming might need some more thought here.
>
> What exactly is it that PxCreatePhysics creates? Is it a physics context
> like an OpenGL context? Is it more like a physics service like a
> boost::asio::io_service? Is it a physics simulation? Is it physics object
> factory?
>
> I'm not sure but I think it's almost certainly not just a physics.
>
>
> In any event it looks good to me.
>
>
My apologies for the belated response. With ACM duties and finals week I
have had no more than a few minutes to sit down.

I typically try to follow the Google style guide for coursework and the
like, so changing naming conventions is but a minor change.

The PxPhysics object is used to create and maintain a "realm" of physics.
It keeps track of collision methodologies and is essentially the backbone
of how edges and vertices interact with one-another. It is build on top of
a PxFoundation object which provides the "foundation" of the program,
including callback management and some behind-the-scenes memory allocation.
The PxScene object manages the elements of a particular "scene" or "world"
including pointers to the various objects and gravity.

I am not sure how (other than routing messages between
objects) boost::asio::io_ would provide much of anything in terms of
physics. It is similar to a context like a Device Context or OpenGL
Rendering Context but is not used directly and instead used in the creation
of more modular objects which are linked to it upon creation.

There are no built-in emitters (something that could be provided in this
project) and the documentation states that the non-fluid particle system
uses rigid bodies that interact with the world but not eachother, which
makes sense.

I was unsure how prefixes should/would be used in a project like this,
which is why I used the "bx" prefix.

One thing to note is that PhysX uses a 3-vector class to hold vector data.
It is pretty basic but also moderately fleshed out in the source. Would
compatibility with the uBLAS matrices (as vectors are to be consolidated)
be desirable? The PhysX design uses pointers for just about everything, so
that could mean some interesting design considerations.

I will be spending the Summer assisting one of my professors with his
research project (half-time) and will update my proposal accordingly. Also,
if I have some free time this weekend, I can crank out some *rough* proof
of concept code if it is desired.

Many thanks,
-Preston