| 01:23.21 | *** join/#brlcad Otto_ (~Otto@cpe-24-210-25-11.columbus.res.rr.com) |
| 01:26.38 | *** part/#brlcad Otto_ (~Otto@cpe-24-210-25-11.columbus.res.rr.com) |
| 02:16.29 | CIA-48 | BRL-CAD: 03brlcad * r47299 10/brlcad/trunk/ (configure.ac src/other/Makefile.am): turn off our libpng subbuild entirely by default, even for enable-all, just so we're closer to a clean autotool distcheck for release |
| 02:40.07 | CIA-48 | BRL-CAD: 03brlcad * r47300 10/brlcad/trunk/doc/docbook/Makefile.am: typo, should be CatalogManager.properties |
| 07:26.20 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 12:09.45 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 14:56.06 | CIA-48 | BRL-CAD: 03brlcad * r47301 10/brlcad/trunk/doc/docbook/Makefile.am: this looks like the last problem remaining with the autotools distcheck. there are two files being generated in resources/brlcad that do not belong in the dist that were causing a problem. have to itemize. |
| 15:01.07 | CIA-48 | BRL-CAD: 03brlcad * r47302 10/brlcad/trunk/doc/docbook/Makefile.am: uncomment, was just for debugging |
| 15:01.45 | brlcad | abhi2011: how's it going? been a while since checked in on progress |
| 15:01.52 | brlcad | been watching the commits |
| 15:03.26 | abhi2011 | well brl-cad I am just putting up some pictures in web log explaining my work so far :) |
| 15:03.39 | brlcad | excellent :) |
| 15:03.51 | abhi2011 | so basically I have inserted a custom algorithm for collision detection between 2 boxes |
| 15:04.09 | abhi2011 | and this algorithm inserts manifold points |
| 15:04.13 | CIA-48 | BRL-CAD: 03erikgreenwald * r47303 10/brlcad/trunk/src/libgcv/bottess.c: fix bad comparison in 5 face split |
| 15:04.24 | abhi2011 | generated by raytracing in the overlap region(aabb overlap region) |
| 15:04.51 | abhi2011 | however when I do this I am not able to make a smaller box lie still on a thinner but bigger one |
| 15:05.31 | abhi2011 | so I am trying to figure out why bullet is not keeping the smaller box stable, even though I insert manifold points exactly as bullet does |
| 15:06.03 | abhi2011 | it involves investigating the dynamics part of bullet |
| 15:06.18 | abhi2011 | which is not the easiest thing I have done so far :P |
| 15:06.37 | abhi2011 | so I have posted the issue in the bullet forums |
| 15:06.40 | brlcad | lie still? |
| 15:06.45 | abhi2011 | yes |
| 15:06.56 | abhi2011 | if a box is lying on a plane |
| 15:07.04 | abhi2011 | it will stay as it is |
| 15:07.21 | abhi2011 | that is what I meant by lying still...stationery |
| 15:07.22 | brlcad | because the bb's don't overlap |
| 15:07.44 | abhi2011 | well, actually they overlap very slightly |
| 15:07.51 | abhi2011 | about 0.00001 m |
| 15:07.53 | brlcad | k |
| 15:08.06 | abhi2011 | thats allowed for smooth physics |
| 15:08.15 | brlcad | so that creates a contact interface, presumably |
| 15:08.16 | abhi2011 | some interpenetration is necesssary |
| 15:08.34 | abhi2011 | yes correct |
| 15:08.59 | brlcad | so can you explain the general algorithm to me? or is it written down somewhere? |
| 15:09.08 | brlcad | given two arbitrary bb's |
| 15:09.11 | abhi2011 | yes sure, its quite simple |
| 15:09.12 | abhi2011 | yes |
| 15:09.56 | abhi2011 | so given 2 bounding boxes I calculate where they overlap |
| 15:10.06 | abhi2011 | that will also be a cuboidal volume |
| 15:10.10 | brlcad | giving some smaller intersection box |
| 15:10.20 | brlcad | smaller or equal, rather |
| 15:10.55 | abhi2011 | yes thats right |
| 15:11.25 | abhi2011 | the volume where the 2 aabbs intersect will of course be smaller than the 2 aabbs we are intersecting |
| 15:11.34 | abhi2011 | or equal of they exactly overlap |
| 15:11.43 | abhi2011 | *if they |
| 15:11.47 | brlcad | nods |
| 15:12.30 | abhi2011 | so there is a function called get_overlap() in simrt.c which does this |
| 15:12.55 | abhi2011 | so once i have the overlap volume |
| 15:13.07 | abhi2011 | then I shoot rays along the x axis |
| 15:13.32 | abhi2011 | specifically from the minimum X towards the maximum X |
| 15:13.47 | abhi2011 | so if the overlap box is from -1,-1,-1 to 1,1,1 |
| 15:13.58 | abhi2011 | then I shoot rays from -1 to 1 parallel to x axis |
| 15:14.13 | abhi2011 | the rays will be perpendicular to the yz plane |
| 15:14.17 | brlcad | that will likely be insufficient (but can be fixed later) |
| 15:14.25 | brlcad | shooting down just one axis |
| 15:14.37 | abhi2011 | yes I intend to shoot along the y and z too |
| 15:14.53 | abhi2011 | but for the simple case that I am testing with |
| 15:15.00 | abhi2011 | its sufficient |
| 15:15.07 | brlcad | okay, though .. so you shoot a grid of rays (presumably with one_hit turned off?) |
| 15:15.20 | abhi2011 | so Iyes |
| 15:15.22 | abhi2011 | *yes |
| 15:15.36 | brlcad | so then you have partitions |
| 15:15.38 | abhi2011 | so the rays shoot though the overlap region |
| 15:15.40 | abhi2011 | yes |
| 15:15.41 | brlcad | segments |
| 15:15.46 | abhi2011 | I have a overlap callback |
| 15:15.59 | abhi2011 | which records the overlap partitions in a structure |
| 15:16.29 | abhi2011 | and I later analyze them to see the maximum X, min X etc when the ray is passing through a overlap region |
| 15:16.51 | abhi2011 | all goed so far :) |
| 15:17.51 | abhi2011 | so the place where say a ray enters a overlap region is a single point in 3D space |
| 15:17.59 | abhi2011 | so i make this one of the contact points |
| 15:19.41 | brlcad | what does bullet want? |
| 15:19.53 | abhi2011 | the contact points and the penetration depth |
| 15:20.07 | abhi2011 | so if a body A is penetrating body B |
| 15:20.08 | brlcad | do you just provide contact points, or points and vectors based on thickness of overlap? |
| 15:20.13 | brlcad | or a surface? |
| 15:20.40 | abhi2011 | I provide only the contact points for body B , the depth upto which body B has penetrated into body A and the normal from body B to A |
| 15:20.44 | abhi2011 | so 3 things |
| 15:21.00 | abhi2011 | so if we have a box lying on a ground plane |
| 15:21.12 | abhi2011 | and say the box is body A and the ground is B |
| 15:21.20 | abhi2011 | then A will slight penetrate B |
| 15:22.15 | abhi2011 | then I generate contact points for B, which will be slightly inside it |
| 15:22.25 | abhi2011 | the extent of penetration is the depth |
| 15:22.44 | abhi2011 | and the normal will simple be 0,0,1 (positive Z axis) |
| 15:23.02 | brlcad | abhi2011: hold up, gotta run out for a second .. very interesting, to be continued... :) |
| 15:23.14 | abhi2011 | yeah sure, will get some pics up meanwhile :) |
| 15:23.22 | brlcad | this is getting into meat and I'm sure I'll have more questions :) |
| 15:23.33 | abhi2011 | hehe |
| 15:30.30 | abhi2011 | right so since geometry is involves it will be easier to be on the same page (so to speak :P) : https://docs.google.com/drawings/d/1FVUPyeoq6YWHKPzlDadrZch8qOw0jBjeFgJ3FHtL1SE/edit?hl=en_GB |
| 15:52.58 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) |
| 15:58.13 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) |
| 16:00.19 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) |
| 16:39.19 | abhi2011 | more discussion here : http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=7517&p=25901#p25901 |
| 16:39.33 | abhi2011 | no replies however :( |
| 17:07.29 | brlcad | abhi2011: your message was trimmed :) |
| 17:07.52 | abhi2011 | in the forum ? |
| 17:07.55 | brlcad | yeah |
| 17:07.56 | abhi2011 | I am still updating it |
| 17:08.08 | abhi2011 | too much text to put in |
| 17:08.09 | brlcad | aha! i see |
| 17:08.24 | abhi2011 | the basic thing i want to convey is |
| 17:08.33 | abhi2011 | if i look at the bullet points |
| 17:08.43 | abhi2011 | i see A penetrate B initially |
| 17:08.53 | abhi2011 | but its gradually pushed out after iteration 12 |
| 17:09.00 | abhi2011 | and by 20 its quite stable |
| 17:09.09 | abhi2011 | however for me it justs keeps on sinking |
| 17:09.40 | brlcad | you mean some example that bullet provides? |
| 17:09.42 | abhi2011 | so the constraint solver is not constraining the contact points , which would have held the box foxed in 3d space |
| 17:10.04 | abhi2011 | no the example that I am discussing in that thread |
| 17:10.06 | brlcad | or just allowing the regular collision detection to work |
| 17:10.21 | abhi2011 | regular collision detection |
| 17:10.32 | brlcad | you're discussing a LOT of points in that thread |
| 17:10.45 | abhi2011 | if i allow regular collision detection to work then it holds the box stable on the plane |
| 17:11.16 | brlcad | might be part why there's no response .. there are lots of questions and they all probably warrant a fair bit of discussion :) |
| 17:11.37 | brlcad | you mean it's stable after 20 iterations |
| 17:11.51 | abhi2011 | hmm yeah, yet I am focussing on 1 very simple case, just that there is a lot to it |
| 17:12.07 | abhi2011 | injecting custom contact points takes some changes to the code |
| 17:12.21 | abhi2011 | yes its stable after 20 iterations |
| 17:12.32 | abhi2011 | using regular collision detection |
| 17:13.02 | abhi2011 | however if I start to inject my own contact points, then its not stable , the box passes right through the plane |
| 17:13.07 | abhi2011 | as gravity is acting |
| 17:13.43 | brlcad | so there's something happening with the default collision detection that you're not doing |
| 17:14.45 | abhi2011 | exactly |
| 17:14.54 | abhi2011 | i have been seaching for that |
| 17:15.14 | abhi2011 | the only interface is the addcontactpoints() function |
| 17:16.32 | brlcad | have you looked at the code for the default? |
| 17:16.46 | brlcad | or do they have an example that calls addcontactpoints() |
| 17:17.18 | abhi2011 | yes they have code that calls addcontactpoints() in their default box-box collider |
| 17:17.57 | abhi2011 | I dont see anything else being set, but its possible that some global member of derived member gets set in the 800 lines+ of code |
| 17:18.05 | abhi2011 | *or derived |
| 17:18.05 | brlcad | I'm thinking that you may have to not only provide the contact points and normals, but also invoke some callback to apply the forces |
| 17:18.29 | abhi2011 | yes that will happen automatically after the points are put in |
| 17:18.37 | abhi2011 | its all in 1 flow |
| 17:18.48 | abhi2011 | i just inject the points at the right point in the flow |
| 17:18.53 | brlcad | i'm saying maybe it's not automatic |
| 17:19.09 | brlcad | unless you set something that says "do it automatically" |
| 17:19.18 | abhi2011 | hmm, but the forces do act as otherwise the top box wouldnt move |
| 17:19.19 | brlcad | that would explain it |
| 17:19.33 | brlcad | there's still a global gravity force |
| 17:19.44 | abhi2011 | yes |
| 17:19.51 | brlcad | it's not applying the new force from the collision interaction |
| 17:20.05 | abhi2011 | yep, its pretty certain I am not doing something like that |
| 17:20.20 | brlcad | but then you've defined a cusom collision handler, so I could easily see them adding a callback or state value that lets you override/ignore/modify the force too |
| 17:20.40 | brlcad | the *collision/interaction* force |
| 17:20.49 | brlcad | force(s) |
| 17:21.16 | abhi2011 | yes, the thing is there is no callbacks in the force-application part of the pipeline |
| 17:21.40 | abhi2011 | only in the collision point generation part there is some callbacks and the possiblity to inject points |
| 17:21.53 | abhi2011 | so I ll go ahead with gdb |
| 17:22.16 | abhi2011 | and step through the force-application part and see whats happemning |
| 17:22.18 | brlcad | doesn't have to be a callback, could just be a bullet function that gets called (recalculateForcesBasedOnNewContactPoints()) |
| 17:22.41 | abhi2011 | yes |
| 17:22.46 | brlcad | or, like I said, some global environment set up that happens earlier |
| 17:23.20 | abhi2011 | yes |
| 17:23.49 | abhi2011 | but apart from that the algorithm is as shown in that google doc |
| 17:24.36 | abhi2011 | the rays are shot and the entry points can be converted to contact points ...and some extra logic of course for the depth and normals(VCROSS the points) |
| 17:25.31 | brlcad | nods (though I can't get to google docs until later) |
| 17:25.58 | abhi2011 | ok, yeah its the same picture as the one on the thread, the white colored background |
| 17:30.10 | abhi2011 | the last post summarizes it all |
| 17:36.42 | abhi2011 | wish there was a irc for Bullet too :) |
| 17:37.49 | brlcad | you mean like #bulletphysics? |
| 17:38.37 | abhi2011 | hehe clicked on it and got hopeful for a second :P |
| 17:38.52 | brlcad | hm? |
| 17:39.21 | abhi2011 | #bulletphysics is not an actual channel , I hoped it was |
| 17:39.31 | brlcad | it is |
| 17:39.39 | abhi2011 | oh wait the question mark came |
| 17:39.42 | abhi2011 | :P |
| 17:39.46 | abhi2011 | i ll try again |
| 17:39.57 | brlcad | just type /join #bulletphyics |
| 17:40.01 | abhi2011 | ah |
| 17:40.03 | abhi2011 | yes |
| 17:40.05 | abhi2011 | am in |
| 17:40.13 | abhi2011 | thanks :P |
| 17:41.25 | brlcad | abhi2011: have you read http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=5365&p=19270&hilit=+contact+pair+#p19270 ? |
| 17:41.59 | abhi2011 | no not yet, will have a look |
| 17:43.18 | brlcad | might not be related, but speaks some about contact pairs with a couple responses |
| 17:43.42 | abhi2011 | hmm it seems to add points over multiple iterations, I however add them in 1 shot as every iteration is a cold start |
| 17:43.58 | abhi2011 | that is from the beginning with world setup an everthing |
| 17:44.27 | brlcad | you using a btGImpactMeshShape ? |
| 17:44.34 | abhi2011 | no |
| 17:44.36 | abhi2011 | only boxes |
| 17:44.40 | abhi2011 | btBoxShape |
| 17:44.45 | brlcad | k |
| 17:45.24 | abhi2011 | for all BRL-CAD shapes (the actual shapes are of course resolved based on rt etc etc as dicussed before) |
| 17:46.07 | brlcad | hm, http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=7498&hilit=custom+collision implies there is a callback for adding contacts |
| 17:46.19 | brlcad | so perhaps the default is simply "do nothing" when you override |
| 17:46.35 | brlcad | or setCollisionFlags() needs some magic |
| 17:48.09 | brlcad | interesting snippet that uses ray casting for collision detection (car demo) |
| 17:48.09 | brlcad | http://code.google.com/p/game-ws/source/browse/branches/cardemo/src/raycast_car.cpp |
| 17:48.32 | abhi2011 | oh awesome |
| 17:48.34 | abhi2011 | :) |
| 17:52.30 | brlcad | calculateCombinedRestitution() looks somewhat important |
| 17:53.09 | brlcad | along with the CF_CUSTOM_MATERIAL_CALLBACK collision flag |
| 17:53.28 | abhi2011 | yes, I think those will be called anyway as those parts are unchanged |
| 17:53.48 | brlcad | the example I was looking at called them directly |
| 17:53.54 | abhi2011 | hmm will verify that though |
| 17:54.00 | abhi2011 | yes |
| 18:07.36 | *** join/#brlcad piksi (piksi@pi-xi.net) |
| 18:13.23 | CIA-48 | BRL-CAD: 03n_reed * r47304 10/brlcad/trunk/src/other/step/src/express/express.c: add token printing debug routine |
| 18:17.18 | CIA-48 | BRL-CAD: 03brlcad * r47305 10/brlcad/trunk/doc/docbook/Makefile.am: DO need the catalogs to be listed as BUILT_SOURCES so that they're properly cleaned up for distclean. hopefully the last dist issue. |
| 18:18.27 | abhi2011 | hmm I think I see a way out of this mess :p |
| 18:18.56 | abhi2011 | so there are basically 2 approaches possible for supporting arbitrary shapes inside Bullet |
| 18:19.53 | brlcad | yes? |
| 18:19.57 | abhi2011 | 1. The more 'low level' one , where , whenever a body touches another body , I let them penetrate a bit so I can detect the overlap using rays and generate contact points |
| 18:20.29 | abhi2011 | these contact points are injected into the bullet physics pipeline and are kept fixed in space by the constraint solver |
| 18:20.37 | abhi2011 | thus fixing the body they belong to, also in space |
| 18:20.49 | abhi2011 | 2. The more higher level approach |
| 18:21.00 | abhi2011 | which the raycast vehicle appears to use |
| 18:21.10 | abhi2011 | detect overlap using raycast as usual |
| 18:21.18 | abhi2011 | however apply the force yourself |
| 18:21.28 | abhi2011 | at the contact point |
| 18:21.46 | abhi2011 | instead of hoping-against-hope that bullet will do it for you :P |
| 18:22.02 | abhi2011 | which it wont :) |
| 18:22.35 | abhi2011 | so I think this should work for convex shapes too and any arbitrary shape |
| 18:23.29 | abhi2011 | except that the force at the contact point has to applied in the right direction : normal to the surface, and also on both bodies |
| 18:23.42 | abhi2011 | but then there is the question of how much force to apply |
| 18:24.29 | abhi2011 | that has to be calculated using restitution etc and then there is friction, so basically doing a lot of the stuff that bullet should do |
| 18:26.16 | abhi2011 | hmm guess I ll take the second approach for now since it seems to offer some control over the restitution etc too |
| 18:30.37 | abhi2011 | for calculating the magnitude of force to be applied at the point of contact, I would need to acceleration of the body in the previous frame |
| 18:32.20 | abhi2011 | concave objects can have multiple overlap regions(eg wine goblet lying on its side on the floor), but that can be dealt with later |
| 18:50.19 | brlcad | abhi2011: whichever path you plough down, handling the concave case is going to be critical |
| 18:50.52 | brlcad | it won't be usable for anything except very simple demos if it only supports convex shapes |
| 18:51.18 | brlcad | fun and neat, but not practical |
| 18:57.10 | CIA-48 | BRL-CAD: 03brlcad * r47306 10/brlcad/trunk/TODO: rtcheck within mged seems to be working just fine |
| 19:00.55 | CIA-48 | BRL-CAD: 03brlcad * r47307 10/brlcad/trunk/TODO: couldn't get red to crash with multiple/any blanks lines, so shoould be good to go for release. did notice that the mac input bug seems to be back, though. |
| 19:03.56 | ``Erik | hm, tesla lost the libel case against top gear |
| 19:04.03 | CIA-48 | BRL-CAD: 03brlcad * r47308 10/brlcad/trunk/doc/docbook/Makefile.am: define a creation rule for FOP_XML_CATALOG too since it's also a dep on all |
| 19:28.29 | CIA-48 | BRL-CAD: 03bob1961 * r47309 10/brlcad/trunk/src/tclscripts/lib/Accordian.tcl: This is an implementation in Itcl/Itk of an Accordian widget. Internally it uses ttk widgets. |
| 19:29.25 | CIA-48 | BRL-CAD: 03bob1961 * r47310 10/brlcad/trunk/src/tclscripts/lib/CMakeLists.txt: Added an entry for Accordian.tcl |
| 19:49.21 | abhi2011 | brlcad: yes i think concave objects will generally cause forces acting at various distances from the body's center leading to torques |
| 19:49.39 | abhi2011 | if these torques cancel each other out, the body will be stable |
| 19:51.06 | abhi2011 | like if we take the case of a marble dropping inside a cup |
| 19:51.56 | abhi2011 | then the forces acting on the bottom points of the marble as it makes contact with the base of the cup will stop its fall |
| 19:52.17 | abhi2011 | but contact with inside edges of the cup will cause it to roll about for some time |
| 19:57.33 | abhi2011 | i have 1 question though |
| 19:58.02 | abhi2011 | wlll the rays report the normals to the surfaces of objects |
| 19:58.42 | abhi2011 | even if the rays themsleves are entering the targetted object at an angle to the surface |
| 20:08.54 | brlcad | you can get the surface normals for all hit points |
| 20:09.20 | brlcad | RT_GET_NORMAL() as well as other means |
| 20:12.36 | CIA-48 | BRL-CAD: 03bob1961 * r47311 10/brlcad/trunk/src/tclscripts/lib/Accordian.tcl: Added the togglePanel method to cadwidgets::Accordian |
| 23:36.47 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) |