[gsoc-2013] Physics Library Abstraction Layer
I am working on putting together a draft proposal for the project. Is there a preferred format desired? I was going to use a PDF since they are quite portable. I am somewhat confused as to the scope of the project, due to the previous posts in this thread. Is the library to be built upon a specific physics library (PhysX for instance) by utilizing existing code in the respective SDK to abstract away much of the object management? Or is it meant to be built from the ground up to create generic objects, which can then be translated into an arbitrary format for an existing library? Thank-you, -Preston
On 4/18/2013 9:04 PM, Preston Hamlin wrote:
I am somewhat confused as to the scope of the project, due to the previous posts in this thread.
I think the scope of it is what you design it to be in your proposal.
Is the library to be built upon a specific physics library (PhysX for instance) by utilizing existing code in the respective SDK to abstract away much of the object management?
That seems like one workable option.
Or is it meant to be built from the ground up to create generic objects, which can then be translated into an arbitrary format for an existing library?
I'm not sure what this means.
On Apr 19, 2013 4:10 AM, "Michael Marcin"
Is the library to be built upon a specific physics library (PhysX for instance) by utilizing existing code in the respective SDK to abstract away much of the object management?
That seems like one workable option.
Or is it meant to be built from the ground up to create generic objects, which can then be translated into an arbitrary format for an existing library?
I'm not sure what this means.
Thank-you. I was primary confused as to whether or not a specific library would be targeted, since doing so would mean a separate project for each physics platform (if more than one were desired). I suppose I was overthinking things. For the second option, I meant a group of objects and methods generic enough to be replicated in any popular physics library. In this case, there would be a system to take this code (almost like pseudocode) and translate it to an existing physics library format. I have completed a draft proposal and would appreciate some feedback: https://www.dropbox.com/s/7xhha0a3ahk5p6r/preston_hamlin_gsoc_proposal_draft... Many thanks, -Preston
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...
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.
participants (2)
-
Michael Marcin -
Preston Hamlin