Editing User:Abhijit

From BRL-CAD

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.
  
 
====Log====
 
====Log====
*Nov 9th
 
#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
 
*Oct 5th
 
# Began writing a manifold generator based on raytracing. The rays will be shot only where broadphase collision detection finds AABBs overlaps  
 
# Began writing a manifold generator based on raytracing. The rays will be shot only where broadphase collision detection finds AABBs overlaps  
Line 192: Line 146:
 
#Finished a stand alone program based on the very high level libged for getting the bounding box of arbitrarily shaped geometry.
 
#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)====  
+
====Updated Development Time line(Oct 6th)====  
* The plan currently is to test the collision pair generation logic with as many convex shapes as possible
+
* Week 6 : Integrate rt and Bullet for detecting overlaps
 +
** Retrieve/display bounding boxes, object states.
 +
** Get the ray tracer integrated so basic spheres can collide and roll across a surface, basically rays have to be shot so that points inside overlapping regions can be added to the bullet collision points cache.
 +
** Add flags to control bounding box display and object states. Also planning to allow objects to be shot towards a scene, with a custom force and initial location.
 +
 
 +
* Week 7 : Work with more objects and larger systems. The basic focus is to realize a billiard table with multi-colored balls rolling across based on the force applied with a stick.
 +
 
 +
* Week 8 : Continue with fine-tuning the code and improving collision detection accuracy
 +
 
 +
* Week 9 : Finish the raytrace based manifold generation code.
 +
 
 +
* Week 10: Continue to improve the manifold generation. Testing will be required for static objects resting on top of each other and thus not overlapping. How will rays detect the overlap in this case ?
 +
 
 +
* Week 11: Start working on documentation for the simulate command. Integrate the code for applying forces and setting initial mass which had been inserted before but removed for debugging reasons temporarily. Significant chunks of code need to be converted from libged to librt for performance reasons.
  
* Then move on to concave-convex collisions
+
* Week 12: Finish documentation and cleanup code. Present results of past 3 months and plan the improvements to the code.
* 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====

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)