On Sun, Apr 21, 2013 at 9:37 PM, Michael Marcin
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.pdfhttps://www.dropbox.com/s/7xhha0a3ahk5p6r/preston_hamlin_gsoc_proposal_draft...
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#**Guidelineshttp://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