Editing User:Abhijit


User account "Abhijit" is not registered. Please check if you want to create/edit this page.

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
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.
*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
#Corrected object positioning code in mged
*Sep 2nd
#Updated the code for the simulate command. Now objects fall "out of the sky"
#Finally reached the first milestone : http://www.youtube.com/watch?v=SByoQQStH2s
*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
====Development timeline====
* Finally introduce multiple manifolds for concave-concave collisions
* Week 1: Determine method for creating bb for arbitrary geometry in brlcad. Insert bb in a physics engine(ODE and Bullet) and test whether custom collision handlers get called when the bb overlaps. Work with a simple "sphere dropping to ground plane" model.
* Targeting end of November.
* 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====
====Expected Result and eventual benefits for BRL-CAD====

Please note that all contributions to BRL-CAD may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BRL-CAD:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)