User:Abhijit

From BRL-CAD
Revision as of 18:27, 24 July 2011 by Abhi2011 (talk | contribs) (Background work done and why I will be a good choice for the project :))

ESA Summer of Code Project Proposal

Non-vacuum gravity simulator for the BRL-CAD Solid Modeling tool


About Myself

  • Name: Abhijit Nandy
  • Mailing List ID: abhijit.nandy@gmail.com
  • IRC ID: abhi2011

I am an international student (nationality Indian) in the second year of the Computer Engineering programme at TU Delft, The Netherlands. I have a computer science background and was working in the software industry for three years from 2006 to 2009. After that I decided to pursue a course in Computer Engineering to get acquainted with hardware development. More details are present in my CV. Currently I have finished my courses and thesis work and so I have free time on my hand to devote 40 hours a week to the development of BRL-CAD.

Brief project summary

Currently BRL-CAD provides facilities for representing geometry, but has limited capability for simulating physics effects on that geometry. The facilities currently present were designed with animations in mind. The proposal is to integrate rigid body dynamics using the Bullet Physics Engine or the Open Dynamics Engine (ODE). Bullet is provided under the zlib license while ODE is provided under both the BSD license and the LGPL. Both engines provide a collision detection engine and a Newtonian physics model. The exact physics engine to be used will be researched in the first week (see Development timeline). The chosen engine’s collision detection mechanism will be used to check for overlap of axis aligned bounding boxes or the bounding sphere. If an overlap is detected more accurate collision detection will be delegated to a custom collision handler that may use the BRL-CAD gqa and rtcheck tools for precise detection. Other collision handlers can be added if required in case they are absent for any of the BRL-CAD primitives. After the collision handling is tested to work correctly with the rest of the system, support will be added for user specified forces apart from ambient gravity. If time permits I intend to work on integrating and improving the system for joining objects together as well(see Detailed project description).

Detailed project description

The physics will be implemented as a command in the BRL-CAD Archer GUI. This will be of the form:

Archer> runphysics N

The parameter N is the number of simulation steps to run the physics. After the user invokes this command, the Tcl code for the command will call a C++ function containing the logic for doing the physics simulation. The function can be of the form:

int ged_runphysics(struct ged *gedp, int argc, const char *argv[])

The following occurs in the C++ function which will be central to the implementation:

  • The struct ged object that is typically passed to plugins will be used to build up the physics world in a btDiscreteDynamicsWorld provided by Bullet.
  • A Bullet collision shape will be inserted into the physics world corresponding to each object present in the struct ged. These are based on convex primitives such as btBoxShape, btSphereShape, btCylinderShape and they can approximate the BRL-CAD objects. The collision shapes will be constructed from BRL-CAD geometry information.
  • After this the force vectors requested by the user will be read either from the struct ged or using other LIBGED commands. These will be applied on the collision shapes in the physics world.
  • The physics world will then be stepped just once and the ged object positions will be set to the new positions using information from the Bullet btDiscreteDynamicsWorld.
  • The repositioning of objects in Archer happens automatically by the command wrapper, once the objects are modified using LIBGED commands.
  • The C++ function will then exit and control will return to Tcl.

The Tcl command wrapper will call the C++ function N times to obtain the simulation result after N steps. As the object positions will be updated on each call to ged_runphysics(), the user will be able to see the scene’s objects animate in Archer.

Particularly with regard to Bullet, as that is the only physics engine I have used so far, I am aware that it provides facilities for contact tests [2] and callbacks using the contactTest and contactPairTest queries. These can be accelerated using faster broadphase algorithms such as btDbvtBroadphase or btAxisSweep3 which affects the speed of test for overlapping AABBs [3]. Therefore real time updates should be possible. Moreover there are facilities for more fine grained control over the collision pipeline of Bullet, utilizing a custom class derived from btCollisionDispatcher [3]. Custom collision detection algorithms can be specified using btDispatcher::registerCollisionAlgorithm [3].

Physics engines also typically provide constraints such as point to point, hinge and 6 degree of freedom constraints which can be used to join objects together and improve the rudimentary joint rigging systems currently present.

More details will be added to this section as my research proceeds.

Note: The implementation will not rely on any polygonal mesh data as BRL-CAD does not store a mesh for its primitives. Instead physics objects for Bullet’s dynamics world will be created from other geometry information e.g. radius and tire width can be used to make a bounding cylinder for a tire.

Diagram

Will be added soon.

Development timeline

  • Week 1: Discuss licensing for physics engines. Implementation of a simple plugin for Archer that allows the user to construct a sphere and allows it to fall on the ground plane. Custom collision handlers for the candidate physics engines can be tested using this scene to decide on which one to use in BRL-CAD.
  • Week 2: Adding more complex primitives and allowing the user to pick them in the GUI. Improve the custom collision handler and add precise collision support using existing BRL-CAD tools.
  • Week 3: Add support for user specified forces and further improving the custom collision handlers. Ensure BRL-CADs 20+ primitives are properly supported for collision detection and response.
  • Week 4: Investigate addition of constraints for joining bodies. Testing of added code.
  • Week 5: Add various types of constraints for joining bodies. More testing of added code.
  • Week 6-12: TBD, maybe raycast vehicle support on custom terrain, more testing and code improvements, improve Archer’s interface to the creation of physics related objects.

Expected Result and eventual benefits for BRL-CAD

The expected result is to allow the user to model an object such as a sphere or a box and apply forces on them. The forces can be gravity, but will also allow the user to specify other additional forces to be applied during the simulation. The user can then “turn on” the physics using a simple command. The command allows the user to specify the number of physics steps as well. After the simulation begins the user will be able to see the object move in the GUI as the physics is updated. As time permits accurate material properties can be allowed to be specified and will be used to affect object collisions during the simulation. The system will allow frames to be captured during the simulation for video playback later on. Adding accurate physics to BRL-CAD will expand the scope of its usage allowing users to simulate and test concepts within the software. It provides an exciting addition to a powerful piece of software.


References

  1. Bullet Physics: http://bulletphysics.org/mediawiki-1.5.8/index.php/Bullet_User_Manual_and_API_documentation
  2. Bullet custom collision callbacks and triggers : http://bulletphysics.org/mediawiki-1.5.8/index.php/Collision_Callbacks_and_Triggers
  3. Bullet User Manual: http://code.google.com/p/bullet/source/browse/trunk/Bullet_User_Manual.pdf
  4. Open Dynamics Engine: http://www.ode.org/