| Latest revision |
Your text |
| Line 34: |
Line 34: |
| | | | |
| | 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. | | 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. | | '''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. |
| | | | |
| − | ====Log==== | + | ====Diagram==== |
| − | *Nov 9th
| + | Will be added soon. |
| − | #Sphere-Sphere case works : http://imageshack.us/photo/my-images/406/forceb.png/
| |
| − | # Wasnt unitizing the vector used to indicate the direction in which the ray should be shot using rt.
| |
| − | #Trying to improve convex-convex collisions now.
| |
| − | ....but first videoz!
| |
| − | #Slow spheres: http://www.youtube.com/watch?v=nrOtSd07rCY
| |
| − | #Fast spheres : http://www.youtube.com/watch?v=7cZesIJapF4
| |
| − | #Seems like the summing normals in the overlapping region may need to be applied as the reaction force is not in the correct direction in both cases.
| |
| − | #Its dependent on the normal I give to Bullet with the contact pairs
| |
| − | #There are a number of ways to solve the case of objects striking each other while moving fast and interpenetrating too much(leading to very high reaction forces)
| |
| − | ##Measure the smallest air Gap between objects while shooting rays and when its smaller than a tolerance value, start generating 'contact' pairs.
| |
| − | ##Reduce Bullet timestep, so objects are moved in smaller increments in each step.
| |
| − | ##Increase boundary of object by a tolerance factor, so that contact pairs are produced before objects actually interpenetrate. This may be non-trivial for arbitrary objects
| |
| − | ##Another way could be to step back the simulation by one step if there is too much penetration, this would be possible as the state of each object is stored after every iteration.
| |
| − | | |
| − | *Nov 5th
| |
| − | #The box-box case appears to be stable with forces being applied to push them apart when they strike each other.
| |
| − | #It works purely on :
| |
| − | **normals(direction of the linear velocity of the body),
| |
| − | **contact pairs generated on the surface of body B(i.e. whichever body is considered as B in a colliding pair, by Bullet), these are got by shooting a circular bunch of rays in the direction of the velocity and recording the points on body B's surface where the rays exit the body.
| |
| − | **depth of penetration of body B into body A, got simply as the distance between the entry point in body A and the exit point in body B
| |
| − | Note that all 'bodies' are actually BRL-CAD combinations comprised of one or more solids.
| |
| − | #Currently I have tested a simple case as shown in this picture : http://imageshack.us/photo/my-images/708/forceb.png/
| |
| − | #Testing a more complex case with box-sphere now, where raytracing will be much more important to get the right contact points along the surface of the bodies.
| |
| − | | |
| − | *Oct 29th
| |
| − | #Trying with the contact points again as calculating forces manually and relying on Bullet is not an optimal approach. When using contact pairs, Bullet calculates the appropriate force for us, so its best to use it.
| |
| − | #The contact pair approach works for the simple sphere-sphere collision case. Testing the box-box case now.
| |
| − | | |
| − | *Oct 20th
| |
| − | #Adapting the collision logic to use forces instead of contact pairs. Simply #adding contact points between objects does not seem to cause Bullet to apply reaction forces between bodies
| |
| − | #So now forces are applied through the center of the contact region and normal to the surface of either body, which should be enough to push them apart.
| |
| − | #Friction forces need to be applied parallel to the surface too, which needs to inserted ,otherwise we won't have balls rolling on planes.
| |
| − | | |
| − | | |
| − | *Oct 16th
| |
| − | #Added contact processing callbacks to investigate the issue with forces not being applied after contact pairs between 2 objects are added to the physics world.
| |
| − | #Got rid of multiple linked lists which were put in to support varying lists of manifolds, but which turned out to be more of trouble than its worth
| |
| − | *Oct 12th
| |
| − | #Finishing the logic for creating manifolds using rays shot in the direction of the positive X axis.
| |
| − | | |
| − | *Oct 7th
| |
| − | # Grinding out memory leaks using valgrind !
| |
| − | # Lesson : when in doubt always free memory and cause a double free crash, better to be sure!
| |
| − | # Raytracer is properly recording overlap areas and hit regions now.
| |
| − | *Oct 6th
| |
| − | # Hmm things getting even more interesting, it seems that there can be extremely thin overlap regions between objects which are resting on top of each other, down to 0.000001 m, so a plane with all the manifold points can be generated for such a case, as a cuboidal regions would be too small for the solvers to analyze accurately(need to verify this).
| |
| − | # Added code to actually shoot the rays now and record the overlap regions in a circularly linked lists, needs some debugging however.
| |
| − | *Oct 5th
| |
| − | # Began writing a manifold generator based on raytracing. The rays will be shot only where broadphase collision detection finds AABBs overlaps
| |
| − | # This will allow higher accuracy with rays being shot in a 3D grid of higher granularity without sacrificing performance.
| |
| − | *Oct 4th
| |
| − | # Added code to display manifold normals correctly.
| |
| − | # Figured out how to generate the normals based on the direction in which objects overlap. This will be required when generating the contact manifolds using raytracing.
| |
| − | *Oct 3rd
| |
| − | # Contacts manifold are getting drawn and will help in reproducing them through raytracing.
| |
| − | # Corrected some code to position objects correctly and stopped creating bounding boxes every iteration as it has been causing issues.
| |
| − | *Sept 30th
| |
| − | # Added code to display bounding boxes, recalculating the BB every iteration is causing boxes that have moved to stay bent in their new position as each ounding box is inserted as a new cube in the next iteration. This problem should disappear when contact points are calculated correctly.
| |
| − | *Sept 25th
| |
| − | # Finished reorganizing the code to integrate raytracing. Ran into some issues with the positioning of objects after each physics steps, so had to revert to some older working copies.
| |
| − | # Basically at the beginning of each step I rebuild the world and after the simulation, I save the world transform and velocities(linear and angular) for initializing the next step.
| |
| − | # Each step has the bounding box for all objects in the scene calculated again as was originally planned.
| |
| − | *Sept 16th
| |
| − | # On the other hand it seems better to add a new collision detection algorithm for box-box collisions.
| |
| − | # Bullet allows custom algos for each combination of colliding shapes. However we are interested only in the box-box case since all arbitrary shapes are represented by the btBoxShape collision primitive in Bullet. However manipulation of the contact points according to rt output should still allow correct behaviour of arbitrary shapes.
| |
| − | # Inserted some framework code for a basic rt based collision algorithm.
| |
| − | # The contact manifolds will be generated by rt, the algorithm will then insert them into the bullet collision pipeline.
| |
| − | # Hopefully forward dynamics will take off correctly after that.
| |
| − | | |
| − | *Sept 15th
| |
| − | # Add callback for broadphase and narrowphase collision detection.
| |
| − | # May be possible to add contact points detected during raytracing overlaps.
| |
| − | # Wrote some tcl code to generate scenes automatically and raytrace them.
| |
| − | | |
| − | *Sept 7th - Sept 14th
| |
| − | # Chugging along, now added code to retrieve bounding boxes from Bullet
| |
| − | # Now object activation states inside Bullet (idle or sleeping) are displayed through different colors on the boxes
| |
| − | # Wrote some initial code to shoot rays and add points to the bullet points cache.
| |
| − | | |
| − | *Sept 4th - Sept 6th
| |
| − | # Not much coding done, was mostly going through the collision detection code in Bullet
| |
| − | # Almost done adding bounding box and object state colors for easier debugging in mged.
| |
| − | # Apparently a solution to arbitrary shapes is to remove all contact manifolds generated by Bullet and apply a force ourselves. Need to test the idea.
| |
| | | | |
| − | *Sep 3rd
| + | ====Development timeline==== |
| − | #Corrected object positioning code in mged
| + | * 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. |
| − | *Sep 2nd | + | * 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. |
| − | #Updated the code for the simulate command. Now objects fall "out of the sky"
| + | * Week 4: Investigate addition of constraints for joining bodies. Testing of added code. |
| − | #Finally reached the first milestone : http://www.youtube.com/watch?v=SByoQQStH2s
| + | * 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. |
| − | *Aug 29th - Sep 1st
| |
| − | #Added regions and groups to the bounding box function
| |
| − | #Added code to pass regions from a model to bullet for the sim
| |
| − | | |
| − | *Aug 22nd - Aug 28th
| |
| − | #Finished the bounding box function
| |
| − | #Modified CMake logic to compile the simulate command as a separate library
| |
| − | #Working on passing multiple objects from a Mged model to the simulation so scenarios like n balls on a billiard table can be simulated.
| |
| − | | |
| − | *Aug 21st
| |
| − | #Compiled Bullet with libged and loaded its dynamic libs with mged.
| |
| − | #Ran a sphere dropping on a plane scenario and it gave the correct results
| |
| − | #Now updating it to translate the position of a sph in mged to the final position of the sphere, before passing the bounding box etc.
| |
| − | | |
| − | *Aug 13th - Aug 20th
| |
| − | #Submitted a fix for Mged. The issue was that a body may be in edit mode when it killed. Then accepting any tranformations done on it can result in a Segmentation fault due to the NULL illump pointer. titles.c was changed.
| |
| − | #Committed changes for the simulate command in Mged.
| |
| − | #Modified top level CMakelists.txt to link to Bullet libs.
| |
| − | #Had an issue accessing the Bullet headers, but that was due to a non-standard install location of Bullet. Now trying to link to Bullet libs.
| |
| − | #Tried using db_functree() to load missing primitives into the in-mem database instance, but the tree representing the primitives are not available, so trying to find a way to convert the rt_db_internal to union tree.
| |
| − | #More code reading.
| |
| − | | |
| − | *Aug 12th
| |
| − | #Mostly read the extra articles in the BRL-CAD documentation
| |
| − | #Tried to extend the bounding box code to use rt_comb_internal instead of rt_gettree()
| |
| − | | |
| − | *Aug 11th:
| |
| − | #Submitted patch 3390331 for BB of primitives.
| |
| − | | |
| − | *Aug 10th: | |
| − | #Finished the code for the bounding box. It works now for basics shapes.Should be extended to work for regions and groups.
| |
| − | | |
| − | *Aug 9th:
| |
| − | #Mostly reading libwdb and librt code and finishing the function
| |
| − | #Read some of the tutorial articles on BRL-CAD
| |
| − | | |
| − | *Aug 8th:
| |
| − | #Mostly reading code and documentation.
| |
| − | #Started working on function for librt which calculates the bounding RPP when a shapes, region or group is passed in the database internal format struct rt_db_internal.
| |
| − | | |
| − | *Aug 7th: | |
| − | #Figured out how to transform objects to their new orientations and positions now in Mged !. The plan is to now move geometry in a model using the output transformation matrices of a physics sim. However mged draws the object only when the command is finished, so the command needs to be repeatedly called for multiple steps, to see the object animate.
| |
| − | #Changed the runphysics command to "simulate" to imply more general usage based on brlcad's suggestion.
| |
| − | #Working on a wrapper for the C++ based Bullet physics engine code to be called from the simulate.c file.
| |
| − | #Started maintaining daily logs
| |
| − | | |
| − | *Aug 5th - Aug 6th:
| |
| − | #Inserted a runphysics command in Mged.
| |
| − | #Working on moving objects using matrix transforms inside Mged
| |
| − | #Reading principles of effective modeling and going through code in librt.
| |
| − | #Downloaded and compiled Bullet to make sure its installed and working.
| |
| − | | |
| − | *Aug 3rd - Aug 4th: | |
| − | #Finished most of the tutorials and articles for BRL-CAD
| |
| − | #Worked through the Interactive Ray Tracing using NIRT guide to get familiar with ray tracing.
| |
| − | #Converted the bounding box program to use librt functions only.
| |
| − | | |
| − | *Aug 1st - Aug 2nd: | |
| − | #Compiled BRL-CAD on OpenSUSE 11.4 using debugging options
| |
| − | #Went through code in libged especially get_obj_bounds.c
| |
| − | #Finished a stand alone program based on the very high level libged for getting the bounding box of arbitrarily shaped geometry.
| |
| − | | |
| − | ====Updated Development Time line(Nov 9th)====
| |
| − | * The plan currently is to test the collision pair generation logic with as many convex shapes as possible
| |
| − | | |
| − | * Then move on to concave-convex collisions
| |
| − | * Finally introduce multiple manifolds for concave-concave collisions
| |
| − | * Targeting end of November.
| |
| | | | |
| | ====Expected Result and eventual benefits for BRL-CAD==== | | ====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. | | 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. |
| | | | |
| − | | + | ====Background work done and why I will be a good choice for the project :)==== |
| | + | * I have worked with the Bullet Physics Engine before integrating Bullet’s raycast vehicle implementation into the Orbiter Space Flight Simulator. I believe I can learn any other physics engine as well as required for the project. |
| | + | * Installed the source and compiled it (reported any compile issues in IRC). |
| | + | * Finished BRL-CAD tutorials and spent time familiarizing myself with solid modeling. Learnt usage of some of the command line tools used by BRL-CAD. |
| | + | * Writing a simple "hello world plugin" to familiarize myself with the API. Spent time getting to know the other BRL-CAD online resources like the documentation and wiki. |
| | + | * Conformed with other requirements like posting my proposal to wiki, being active in the developer mailing list or IRC for the time I have known this project. Typically available in IRC 24/7 ! |
| | + | * Shown interest to engage with the BRL-CAD developer community and patience to learn the basics before diving into code. :) |
| | + | * Have not begun work on a patch yet, but will gradually come to that after I am able to work with plugins. Furthermore will continue to be involved with BRL-CAD after SOCIS completes. |
| | | | |
| | ====References==== | | ====References==== |
