| 01:44.48 | brlcad | yeah, the two should be decoupled, but even at a low framerate, that penetration shouldn't happen -- implies something is amiss |
| 01:44.55 | brlcad | still, that is fantastic |
| 01:45.17 | brlcad | haven't seen a proper brl-cad animation since the old joint days, probably 8 years ago |
| 03:59.59 | *** part/#brlcad n_reed (~nreed1@c-68-55-142-136.hsd1.md.comcast.net) |
| 04:28.20 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) |
| 05:42.02 | abhi2011 | Thanks everyone :) |
| 05:42.45 | abhi2011 | brlcad: Yes the view seems to change to accomodate all objects with the 1024 by 1024 image size |
| 05:43.03 | abhi2011 | I ll play around with the rtcheck parameters to see whats up |
| 05:43.49 | abhi2011 | I mean rt |
| 05:45.12 | abhi2011 | Yeah I think the penetration will no happen if I specify a plane as the ground plane |
| 05:46.15 | abhi2011 | currently I make a box shape with the same parameters as a arb8 shape in mged (the command looks for a gp.s arb8 shape and uses its bb for the ground plane) |
| 05:46.39 | abhi2011 | but yeah that cant be an excuse, penetration shouldnt happen either way |
| 09:12.51 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 09:52.50 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 12:27.38 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 12:56.30 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 12:58.13 | brlcad | abhi2011: the "what's up" is that a view isn't specified, so it just autosizes the view based on what is being drawn |
| 12:58.50 | brlcad | the view merely needs to be specified (if you run "saveview" within mged, you'll get a view script that you could re-use to render each frame consistently) |
| 12:59.02 | abhi2011 | oh ok, I ll try that |
| 12:59.23 | abhi2011 | I have 1 more question |
| 12:59.30 | abhi2011 | so I have been trying to draw a stack of cubes |
| 12:59.34 | abhi2011 | upon each other |
| 12:59.36 | abhi2011 | in mged |
| 12:59.44 | abhi2011 | so I run a tcl loop |
| 12:59.54 | brlcad | I suspect the penetration is because you're using AABBs |
| 13:00.25 | brlcad | you're passing the aabb's to bullet as simple cubes .. bullet applies rotations to them which causes them to tumble |
| 13:00.38 | brlcad | you correctly apply the tumble transformation to them |
| 13:01.15 | brlcad | but don't feed bullet new aabbs (as they get bigger when the arb8 tumbles), so it's allowed to get too close to the surface |
| 13:02.22 | brlcad | I suspect if you changed the arb8s to all spheres, it wouldn't penetrate (but then the spheres would bounce off each other before they actually touch) |
| 13:02.36 | brlcad | at least until you get the custom collision handler implemented |
| 13:02.37 | abhi2011 | yes, but bullet maintains it own aabbs too |
| 13:02.55 | abhi2011 | thats how it eliminates a large number of objects in broadphase collison detection |
| 13:02.55 | brlcad | so sounds like three things todo |
| 13:03.54 | brlcad | 1) you need some means to update the bb to bullet each timestep if that's not happening already, not just reusing the original bb |
| 13:05.13 | brlcad | 2) you'll need to register a custom collision detection callback for bullet to call, this will be a callback you write that shoots a simple small grid of rays |
| 13:05.33 | brlcad | 3) render with a view set ;) |
| 13:13.24 | abhi2011 | ok |
| 13:13.48 | abhi2011 | yes, actually I dont set the aabb at all in bullet |
| 13:14.08 | abhi2011 | I just make a box with the same dimensions as the aabb |
| 13:14.29 | abhi2011 | I suspect bullet updates the aabb, but maybe not |
| 13:15.11 | abhi2011 | so I was thinking about the sphere dropping on a plane scenario |
| 13:15.35 | abhi2011 | what I would do now is create a cube aligned to the aabb of the sphere |
| 13:15.39 | abhi2011 | and start the sim |
| 13:16.08 | abhi2011 | when the cube touches the ground plane, then bullet would generate a bunch of contact points all along the bottom face of the aabb |
| 13:16.27 | abhi2011 | however at this point I am arranging for a callback to my code |
| 13:17.42 | abhi2011 | in this callback function, I ll use rtcheck or something similar to check the regions which overlap, which in this case would be a sphere region and a ground plane region |
| 13:18.25 | abhi2011 | and I ll modify the contact point list to the 1 single point at the bottom of the sphere which actually makes contact from the region perspective |
| 13:19.10 | abhi2011 | consequently the sphere region aabb may roll over as its contact points have been modified |
| 13:19.32 | abhi2011 | note I am not talking about geometry here at all as discussed before |
| 13:20.34 | abhi2011 | I am dealing simply with regions and their aabbs :) |
| 13:21.14 | abhi2011 | all this is based on the fact that a tool does exist in brl-cad which can give me a list of contact points when 2 regions overlap in 3d space |
| 13:37.40 | brlcad | so a tool exists, but I think you'll find it even easier to shoot the rays yourself (where you can easily control the resolution) |
| 13:38.12 | abhi2011 | ok |
| 13:39.18 | brlcad | as for the aabbs, that was my point -- you pass the aabb (which you feed to bullet as a box), bullet treats it as a box and begins to tumble and apply rotations |
| 13:39.57 | brlcad | once you apply that rotation which came back from bullet, the bb needs to be recalculated and set AGAIN in bullet |
| 13:40.22 | brlcad | if you do that, then there will be no object bounding box penetration |
| 13:40.50 | brlcad | then you can write the collision detection callback that will more accurately report the contact points when bb's overlap |
| 13:41.44 | abhi2011 | ok yeah I can do that for sure, it would require calculating the aabb every simulation tick but that should be ok |
| 13:42.01 | brlcad | yeah, should be instantaneous until the objects get into the thousands |
| 13:42.39 | brlcad | the collision detection callback is going to be what slows things down a little |
| 13:43.18 | brlcad | but what I suggest is starting with the bare minimum, shooting two 3x3 grids of rays |
| 13:44.22 | abhi2011 | ok, but 3 by 3 grid means, if the rays are far apart then they may miss many cubes |
| 13:44.25 | brlcad | er, 3x3x3 grid of rays, a 3x3 for each axis, giving you 27 rays |
| 13:44.35 | abhi2011 | ok |
| 13:44.51 | brlcad | that's just a starting point to make sure things are working |
| 13:44.55 | abhi2011 | ok |
| 13:45.47 | brlcad | that number can EASILY be increased for better detection, but it will slow things down at a cubic rate |
| 13:46.02 | abhi2011 | yes true |
| 13:46.21 | abhi2011 | no point in resetting the contatc manifold multiple times in the same frame |
| 13:48.06 | abhi2011 | though different rays would pass through the overlap region in different places, so new points would be generated by every ray within the overlap region |
| 13:50.11 | brlcad | yes, and the points generated would be precise including the contact point and hit point normal |
| 14:42.53 | abhi2011 | by the way I came across a strange issue while moving objects into position in mged |
| 14:43.07 | abhi2011 | so I generally use rt_matrix_transform() |
| 14:43.43 | abhi2011 | seems if i directly pass it a matrix in the opengl format (after transposing it as brlcad is row major while opengl is column major) |
| 14:43.56 | abhi2011 | then the rotations are applied first and then the translation |
| 14:44.10 | abhi2011 | so the object ends up in a wierd place |
| 14:44.44 | abhi2011 | currently i translate to the origin , do the rotation and then translate again wrt orgin to get to the final position |
| 17:22.31 | *** join/#brlcad juanman (~quassel@unaffiliated/juanman) |
| 17:26.43 | *** join/#brlcad abhi2011_ (~chatzilla@x033197.its-s.tudelft.nl) |
| 17:30.23 | *** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl) |
| 18:19.57 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 19:14.18 | *** join/#brlcad merzo (~merzo@170-171-133-95.pool.ukrtel.net) |
| 19:33.52 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 20:56.07 | CIA-62 | BRL-CAD: 03jordisayol * r46563 10/brlcad/trunk/misc/debian/control: Change building dependencies from make to cmake for debian sources |
| 21:04.40 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |