| 01:16.58 | starseeker | woo hoo! http://gitorious.org/boost/cmake/trees/cmake-1.47.0 |
| 01:17.04 | starseeker | does happy dance |
| 01:20.16 | starseeker | builds successfully too |
| 02:20.43 | starseeker | Idea: Could we put a CMakeified Boost into our svn repo and use svn:external to pull that as part of a checkout? Then people using a system Boost could just do svn co --ignore-externals and not have to pull Boost at all |
| 02:59.46 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.166) | |
| 03:03.28 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.166) | |
| 03:32.50 | *** join/#brlcad ibot (~ibot@rikers.org) | |
| 03:32.50 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || #brlcad logs: http://ibot.rikers.org/%23brlcad/ || BRL-CAD release 7.20.2 is posted (20110701) || BRL-CAD is participating in the ESA Summer of Code in Space! | |
| 03:57.07 | abhi2011 | yippeee!!!, the sphere - sphere case also works :), wasnt unitizing the direction vector while shooting rays ! |
| 03:58.05 | abhi2011 | just cant seem to get out of the newbie group :P with rt |
| 04:01.43 | CIA-109 | BRL-CAD: 03abhi2011 * r47453 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c): Committing the code used to debug errors in generating manifolds using rt, in case I need to get back to it again quickly later. |
| 04:10.04 | CIA-109 | BRL-CAD: 03abhi2011 * r47454 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c): Now the proper working code with all debugging stuff removed. |
| 04:12.02 | abhi2011 | http://imageshack.us/photo/my-images/406/forceb.png/ |
| 04:15.51 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3232 10/wiki/User:Abhijit: /* Log */ |
| 04:37.13 | starseeker | abhi2011: any chance of making a video with the spheres? |
| 04:37.38 | abhi2011 | starseeker: yes I am working on that |
| 04:37.43 | starseeker | sweet! |
| 04:38.11 | abhi2011 | I need the spheres to overlap somewhat , to generate contact points and rt does some wierd colors when objects overlap |
| 04:38.48 | abhi2011 | but it should be ok for small velocites |
| 04:39.08 | starseeker | hmm. So it's not actually a "true" contact test but a "slightly intersecting" test? |
| 04:39.27 | abhi2011 | yes thats right |
| 04:39.50 | abhi2011 | because rt will create contact points based on the overlap area |
| 04:40.06 | abhi2011 | or rather to put it better |
| 04:40.42 | abhi2011 | I can create contact points using rt, only when they overlap |
| 04:41.20 | starseeker | would it be possible to use the intersecting rays to "back up" just to the point where the longest intersecting ray becomes zero, and proceed again from there using the information? |
| 04:41.22 | abhi2011 | as the rays report overlap regions |
| 04:42.30 | abhi2011 | by becoming zero you mean, there is no overlap region reported for the longest overlapping ray ? |
| 04:42.39 | starseeker | something like that |
| 04:42.44 | abhi2011 | *longest ray |
| 04:42.46 | abhi2011 | ok |
| 04:42.50 | starseeker | just a thought |
| 04:42.56 | abhi2011 | yes I think it should be possible |
| 04:43.14 | starseeker | basically the idea would be to not have to solid things "merge slightly" when interacting... |
| 04:43.26 | abhi2011 | yes, I was also thinking that if 2 objects are very close to each other |
| 04:43.27 | starseeker | but I don't know if that's compatible with the approach - just a random thought |
| 04:43.35 | abhi2011 | then the air gap will be very small too |
| 04:43.46 | abhi2011 | so if I shoot rays in their overlap region |
| 04:43.57 | abhi2011 | and check for the smallest air gap |
| 04:44.18 | abhi2011 | then at a certain points ...say 0.04 mm, I could generate the points |
| 04:44.44 | abhi2011 | then the objects have not yet physically intersected as there is still small air gap between them |
| 04:44.49 | starseeker | nods |
| 04:45.27 | starseeker | may not need to ensure an air gap even - just stray thoughts |
| 04:45.31 | starseeker | you're the expert :-) |
| 04:45.44 | abhi2011 | currently I seem to have an issue with 2 objects penetrating too much into each other, if alowed to do so, when they have high relative velocities |
| 04:46.01 | abhi2011 | hehe, yep all ideas help :) |
| 04:46.19 | starseeker | well, it is "bullet" ;-) |
| 04:46.30 | abhi2011 | hehe yeah |
| 04:47.06 | abhi2011 | ok I ll make 2 vids, one with a sphere dropped from a low altitude |
| 04:47.15 | abhi2011 | and an another from a high one |
| 04:47.18 | abhi2011 | and see what happens |
| 04:47.22 | starseeker | sweet |
| 04:47.34 | starseeker | still fantastic progress |
| 04:47.42 | abhi2011 | thanks :) |
| 04:47.59 | abhi2011 | cant wait to try the billiard table case with custom forces :P |
| 04:48.04 | starseeker | who knows - brlcad might even think up some scenarios where overlapping would be useful |
| 04:48.08 | starseeker | hehe :-) |
| 04:48.22 | starseeker | "BRL-CAD - now, with pool simulations!" |
| 04:48.48 | abhi2011 | :) |
| 04:49.02 | abhi2011 | so , there is this powerful server everyone keeps talking about |
| 04:49.09 | abhi2011 | bullet is not installed there ? |
| 04:49.14 | starseeker | um |
| 04:49.16 | starseeker | dunno |
| 04:49.25 | starseeker | ``Erik: we have a powerful server? |
| 05:19.27 | *** join/#brlcad abhi2011 (~chatzilla@117.200.82.100) | |
| 06:05.19 | *** join/#brlcad abhi2011 (75c85d7f@gateway/web/freenode/ip.117.200.93.127) | |
| 07:38.43 | *** join/#brlcad abhi2011 (~chatzilla@117.200.89.207) | |
| 07:41.18 | abhi2011 | http://www.youtube.com/watch?v=nrOtSd07rCY |
| 07:41.25 | abhi2011 | this is with slow striking spheres |
| 07:42.33 | abhi2011 | the reaction force from the sphere at the bottom is straight upwards, opposite to the velocity of the upper sphere |
| 07:42.55 | abhi2011 | yet , it does not seem correct as the reaction should be at 45 degrees to the vertical |
| 07:43.22 | abhi2011 | so I ll try with the summing normals at the overlapping region approach and check if that gives better results |
| 07:44.49 | abhi2011 | for fast moving sphere , this more of an issue, as a fast sphere suddenly penetrates deep into the lower sphere : http://www.youtube.com/watch?v=7cZesIJapF4 |
| 07:45.10 | abhi2011 | causing a sudden high reaction force |
| 07:45.22 | abhi2011 | which does not seem correct either |
| 07:45.33 | abhi2011 | will try and figure out a solution |
| 07:49.57 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 07:50.03 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3233 10/wiki/User:Abhijit: /* Log */ |
| 07:50.47 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3234 10/wiki/User:Abhijit: /* Log */ |
| 07:51.29 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3235 10/wiki/User:Abhijit: /* Log */ |
| 08:46.50 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3236 10/wiki/User:Abhijit: /* Log Nov 9th */ |
| 08:50.21 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3237 10/wiki/User:Abhijit: /* Updated Development Time line(Oct 6th) */ |
| 08:50.50 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3238 10/wiki/User:Abhijit: /* Updated Development Time line(Nov 9th) */ |
| 08:57.04 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3239 10/wiki/User:Abhijit: /* Log */ |
| 09:02.09 | CIA-109 | BRL-CAD: 03abhi2011 * r47455 10/brlcad/trunk/src/libged/simulate/ (simrt.c simulate.c): Switched to summing of normals approach to generate contact pairs. Added a #define to switch back to velocity based generation quickly if needed. |
| 09:15.07 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3240 10/wiki/User:Abhijit: /* Log */ |
| 09:54.30 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.178) | |
| 12:10.47 | ``Erik | starseeker: he might be referring to the new gcc compile farm machine that brlcad was playing on? I think it's 64 power7 cores? |
| 12:12.09 | ``Erik | http://gcc.gnu.org/wiki/CompileFarm gcc110... 64 power7 cores at 3.55ghz, 64g ram, fedora ppc64 |
| 12:13.55 | ``Erik | I see brlcad logged into it right now, and the load is 0... altivec capable, even |
| 12:16.11 | ``Erik | would guess a hair over half a million VGR's |
| 12:17.36 | ``Erik | we also have the cat machines, those're 16 xeon cores a whack, not exactly chump change |
| 12:23.11 | ``Erik | hm, abhi isn't here |
| 12:34.40 | ``Erik | ffs, this email is going to be a book. |
| 13:54.36 | *** join/#brlcad abhi2011 (~chatzilla@117.200.87.72) | |
| 13:58.44 | abhi2011 | ``Erik: Thanks for the mail :) |
| 13:58.57 | abhi2011 | very insightful |
| 13:59.14 | abhi2011 | trying to digest all the info now |
| 14:02.35 | starseeker | abhi2011: nifty video! |
| 14:03.01 | abhi2011 | hehe, I ll try n pop in a few more stuff |
| 14:03.04 | starseeker | agree it's not quite right, but still nice progress! |
| 14:05.12 | abhi2011 | hmm, so the basic idea now is to do zero penetration physics |
| 14:05.19 | abhi2011 | or to recover from penetration |
| 14:08.32 | abhi2011 | hehe, agree on the "fairly gross simplifications of geometry" part player characters :P |
| 14:08.35 | *** join/#brlcad merzo (~merzo@193.254.217.44) | |
| 14:08.54 | abhi2011 | I think bullet uses just a capsule shape for a player, rotating it or making it jump as needed |
| 14:08.55 | ``Erik | :D most of my background comes from old (quake2 era) video games, so take it with a fat grain of salt |
| 14:09.37 | abhi2011 | :), yeah me have never done it, so any info is useful |
| 14:09.39 | ``Erik | back when I was doing it, the 'hot' thing was to have the entire character represented by a stretched sphere |
| 14:09.47 | abhi2011 | ok |
| 14:10.35 | ``Erik | the capsule supposedly better represents *shrug* |
| 14:10.48 | ``Erik | I tried to cc brlcad and starseeker, not sure if they got 'em |
| 14:11.13 | ``Erik | I think brlcad won't be back until next week, maybe :/ |
| 14:11.13 | abhi2011 | ok, hmm, yes, for large time delta, bullet breaks up the update into smaller internal sub steps |
| 14:11.20 | abhi2011 | oh ok |
| 14:12.15 | abhi2011 | was thinking about the " extending the boundary of an object slightly" idea though |
| 14:12.26 | abhi2011 | I think bullet does it with the basic shapes it uses |
| 14:12.41 | abhi2011 | but I guess trying that approach for brl-cad shapes would be tough |
| 14:13.31 | ``Erik | BRL-CAD provides both a bounding sphere and aabb for each primitive, both are easy to extend |
| 14:13.32 | abhi2011 | 'cause the entire periphery of an object would need to be detected and extended |
| 14:14.09 | abhi2011 | ok |
| 14:14.50 | abhi2011 | so a ray shot though the primitive, would give the exit point a little but further along than , it would , without extension |
| 14:15.01 | abhi2011 | and the entry point a little bit earlier |
| 14:15.19 | ``Erik | oh, and http://brlcad.svn.sourceforge.net/viewvc/brlcad/rtcmp/trunk/rt/rt.c?revision=34030 is about as simple as you're going to get for ray-tracing in BRL-CAD, the 'hit' function is more complex than you need, but the rest should be minimal |
| 14:16.05 | abhi2011 | ok |
| 14:20.22 | abhi2011 | ``Erik: so by "solve the impulse vector", you mean calculating the reaction force from the collision , by using change in momentum etc ? |
| 14:29.12 | ``Erik | yeh, though thinking, the resultant velocity vector is what you actually want in the end, not just the delta *shrug* |
| 14:37.56 | abhi2011 | well yes |
| 14:38.25 | abhi2011 | actually I let Bullet calculate the resultant velocity :) |
| 14:38.32 | abhi2011 | I just give it a resultant normal |
| 14:38.38 | abhi2011 | pointing from object A to B |
| 14:48.36 | *** join/#brlcad piksi (piksi@pi-xi.net) | |
| 14:54.23 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:20.32 | CIA-109 | BRL-CAD: 03bob1961 * r47456 10/brlcad/trunk/src/other/clipper/ (clipper.cpp clipper.hpp): Updates from Angus. |
| 17:37.24 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.182) | |
| 17:37.39 | CIA-109 | BRL-CAD: 03bob1961 * r47457 10/brlcad/trunk/src/tclscripts/mged/skt_ed.tcl: Update calls to dist and find_arc_center to reflect the fact that they are no longer in the Sketch_editor namespace. |
| 18:32.43 | CIA-109 | BRL-CAD: 03starseeker * r47458 10/brlcad/trunk/src/conv/g-obj.c: Faces were all using the same value due to variable i not being changed in the loop... report from Christopher Pitts, bug tracker #3435642 |
| 19:13.47 | CIA-109 | BRL-CAD: 03bob1961 * r47459 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Added a method for "l". The "g" command will now expand it's argument list. |
| 19:22.12 | *** join/#brlcad merzo (~merzo@91-101-133-95.pool.ukrtel.net) | |
| 21:43.15 | ``Erik | nice. http://technet.microsoft.com/en-us/security/bulletin/ms11-083 |
| 21:43.41 | ``Erik | possible remote code execution by dumping udp packets at a target machine. |
| 22:17.59 | CIA-109 | BRL-CAD: 03n_reed * r47460 10/brlcad/trunk/doc/bison_to_lemon.txt: minor update on aliases |
| 22:53.06 | CIA-109 | BRL-CAD: 03n_reed * r47461 10/brlcad/trunk/src/other/step/CMake/FindLEMON.cmake: add modified lemon_target macro |
| 22:58.52 | CIA-109 | BRL-CAD: 03n_reed * r47462 10/brlcad/trunk/src/ (2 files in 2 dirs): modified CMakeLists for alt lemon macro |
| 23:41.34 | CIA-109 | BRL-CAD: 03starseeker * r47463 10/brlcad/trunk/ (4 files in 4 dirs): Get the FindLEMON logic working with the new paradigm (specifying the target header file) |
| 23:53.11 | CIA-109 | BRL-CAD: 03n_reed * r47464 10/brlcad/trunk/src/other/re2c/ (6 files in 2 dirs): switched re2c yacc parser with lemon parser |
| 23:58.07 | CIA-109 | BRL-CAD: 03n_reed * r47465 10/brlcad/trunk/src/other/step/ (CMake/FindYACC.cmake CMakeLists.txt): FindYACC no longer used; removed |
