IRC log for #brlcad on 20110829

03:50.06CIA-62BRL-CAD: 03Jimblack 07http://brlcad.org * r3084 10/wiki/Main_Page:
05:06.55*** join/#brlcad ibot (~ibot@rikers.org)
05:06.55*** 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!
07:18.40*** join/#brlcad merzo (~merzo@193.254.217.44)
09:35.05CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3085 10/wiki/User:Abhijit: /* Log */
09:35.25CIA-62BRL-CAD: 03Abhi2011 07http://brlcad.org * r3086 10/wiki/User:Abhijit: /* Log */
11:10.13*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:38.19abhi2011brlcad: about passing the struct db_i* in rt_bound_internal()
12:40.13abhi2011it would be necessary to call rt_gettree() inside this function
12:40.33abhi2011to get the primtives for a comb loaded
12:40.55abhi2011is that fine, or would it be better to avoid calling rt_gettree() ?
12:41.37abhi2011if I do need to call rt_gettree(), then the 2nd parameter is the name of the comb/primitive
12:44.16abhi2011which is generally got using a directory pointer using dp->d_namep
12:45.42abhi2011the only way to get a directory pointer is to use again use name of the comb and then db_lookup()
12:48.17abhi2011I have been searching for getting the comb or primitive name from a struct rt_db_internal if at its possible
12:51.10abhi2011seems all of this can be avoided if the caller code simply calls rt_gettree() before passing the struct rt_db_internal*
12:51.23abhi2011then we do not even need to pass the struct db_i *
12:54.56abhi2011or the calling code can pass the name of the comb/primitive
13:18.20*** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:16.20CIA-62BRL-CAD: 03starseeker * r46446 10/brlcad/trunk/TODO.cmake: Update todo items for CMake
14:48.43CIA-62BRL-CAD: 03starseeker * r46447 10/brlcad/trunk/src/other/CMakeLists.txt: mark BRLCAD_TERMLIB_BUILD as advanced
14:53.27*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl)
14:57.11*** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ)
15:04.18CIA-62BRL-CAD: 03starseeker * r46448 10/brlcad/trunk/src/other/re2c/bootstrap/parser.hh: May need the parser.hh file too...
15:04.54CIA-62BRL-CAD: 03starseeker * r46449 10/brlcad/trunk/src/other/re2c/bootstrap/parser.hh: fix comment
15:08.16CIA-62BRL-CAD: 03starseeker * r46450 10/brlcad/trunk/misc/CMake/CompilerFlags.cmake: MSVC doesn't know what to do with D_FORTIFY_SOURCE, apparently
16:38.14*** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-186-249.wlan.tudelft.nl)
16:42.44brlcadabhi2011: gah
16:44.22brlcadthat's a problem, rt_db_internals are nameless ... forgot about that
16:44.30abhi2011oh shoot :P
16:44.42abhi2011yeah by the time its reaches the rt layer
16:44.46abhi2011names are no longer relevant
16:45.01brlcadthat's by design, so you can write a given rt_db_internal as many times as you want with different names
16:45.19abhi2011ok
16:45.21brlcadyou might have to resort one layer higher, with a struct directory *
16:46.26abhi2011yes , however a struct directory * is made using db_lookup(), which unfortunately also requires a name , and I cannot use a dummy name, I have to use the exact name of the comb the user passed
16:46.59brlcadhuh?
16:47.14brlcadlibged knows the name
16:47.26brlcadthe same name you used to get the rt_db_internal
16:47.36brlcadinstead of that, you'll just pass the directory
16:48.48abhi2011oh ok, so I pass the directory and the struct db_i *, something like this : rt_bound_internal(struct db_i *dbip, struct directory *dp , struct rt_db_internal *ip, point_t rpp_min, point_t rpp_max)
16:49.04brlcadif you pass the dp, you no longer should pass the ip
16:49.09brlcadyou can get the ip from the dp
16:49.12abhi2011yes right
16:49.15abhi2011ok
16:49.26abhi2011I was wondering :)
16:49.39abhi2011why we simply have a function which accepts the dp and the name
16:49.52abhi2011um no scratch that
16:50.05abhi2011dp and dbip is enough
16:50.38abhi2011i thought it would be easy to have a function that just accept the name of the comb/primitive and the dbip
16:50.49abhi2011that would be easy to pass by a user
16:51.37abhi2011something like rt_bound_internal(char*name , struct db_i *dbip, point_t rpp_min, point_t rpp_max)
16:52.14brlcadthat's libged's responsibility
16:52.22abhi2011oh ok
16:52.25brlcadlibged works with strings, names
16:52.34abhi2011ok
16:53.56abhi2011yeah I get it now :)
16:53.57brlcadreally, I want to just pass the rt_db_internal, but as we already discussed, another routine needs to be written first to fill out the comb's tree properly
16:54.04abhi2011yes
16:54.14brlcaddon't are about names (or even directory), just want the bb given geometry
16:54.28abhi2011yes true
16:54.37brlcadworking with a dbip+dp is a start, though
16:55.13brlcadthat can be refactored to call a lower-level calculate-my-bb-with-just-this-ip later
16:55.53abhi2011ok
16:57.59abhi2011I have a question regarding the transformation matrices of primitives
16:58.45abhi2011so in the commands that somehow transform the object, I can see that the commands generally call rt_matrix_transform()
17:00.00abhi2011and this function ultimately goes and put  a new matrix in the tl_mat member of the struct union tree
17:00.22abhi2011that exists in the tr_l member of a union tree*
17:00.40brlcadusually
17:00.46abhi2011however this is a transform matrix, not the matrix  representing the absolute world position
17:01.07abhi2011however bullet gives me the matrix that represents the transform in absolute world co-ordinates
17:01.50abhi2011so if the object were to start from (0,0,0) and with no rotations along any of the axes, then the transform matrix from bullet can be applied to get the object to its intended position
17:02.27abhi2011now the thing is, I generally copy an existing object in mged, and then apply bullet's transform on it
17:02.41abhi2011however this new object is no made at the origin
17:02.58abhi2011its made in the existing object's position
17:03.09abhi2011which is correct as far as copying is concerned
17:03.42brlcadwaits for the question
17:03.51abhi2011however , it would be great if I were able to reset any copies I make , to the origin
17:04.02abhi2011there are no such commands to do this in mged however
17:04.38abhi2011and if I apply bullet's transforms on a copy, which is not in the origin, then the translation adds to the existing position
17:04.57brlcadyou're going way too far down the rabbit hole
17:05.08abhi2011:)
17:05.11brlcadask a question :)
17:05.46brlcador at least ask me to explain how brl-cad tracks positions if you don't know what to ask :)
17:05.52abhi2011ok
17:06.39abhi2011yeah it would be better if you explain :)
17:07.02abhi2011my issue is how to apply the bullet transforms on a object which is not at the origin
17:07.48abhi2011since the transforms got from bullet specify the translations of the object with respect to the origin, not the position of the object at the start of the simulation
17:08.28brlcadso if you remember my earlier comments from when you first got started -- and why you've been messing around with bounding boxes for so long...
17:10.15brlcadgeometry in brl-cad is described in a rather pure mathematical sense, sometimes in implicit form and sometimes in an explicit form
17:11.13abhi2011yes
17:12.28abhi2011however the positions of the objects are stored explicitly somewhere in a comb/prims attributes
17:12.44brlcadyes and no  (sorry multitasking)
17:12.52brlcadcombinations, for example, have no position
17:12.59brlcadthey are just a grouping
17:13.06abhi2011ah yes right
17:13.08brlcadthey can apply a transformation to that grouping
17:13.20abhi2011ok
17:13.21brlcadthat have an *implicit* position
17:13.35abhi2011ok
17:13.41brlcadit's implied that the position of a combination is the position of all it's continuent submembers
17:13.48abhi2011yes right
17:14.06brlcadso if you calculate that bb of a comb, for example, you could pretend that one of the corners or that the center is that comb's "position"
17:14.30abhi2011ok
17:14.36brlcadthe same can be said of all of the primitives
17:14.57brlcadmany/most of them have an explicit position, but it's defined per primitive
17:15.18abhi2011ok
17:16.25starseekerremembers he needs to look at rt_bot_bbox again...
17:16.26brlcadfor a sphere, it's the center point; for a cylinder, it's the center of the base oval; for a torus, it's also at the center which doesn't even happen to be *on* the object (it's in the void in the middle)
17:17.00brlcadyou could get at that "position", but it's somewhat meaningless for this purpose
17:17.10brlcadall that matters really is having a consistent handle
17:17.13brlcadthat's where the bb comes in
17:17.33abhi2011ok
17:17.35brlcadget the bb for any object, then you can consistently consider the bb center to be a position
17:18.00abhi2011ok
17:18.02brlcadfrom bullet's perspective, all you're dealing with is a lot of boxes
17:18.09abhi2011yes true
17:18.24brlcadyou can implement an overlap/collision detection handler later
17:18.42abhi2011however a bb would not roll on a surface even if it represents a sphere
17:18.49abhi2011yes right
17:19.00brlcadsure it will
17:19.24brlcadat least, it should be able to
17:19.47brlcadyou're not using the "box" as *geometry*
17:19.54brlcadthat's just your handle
17:19.59abhi2011yes right I get that now
17:20.20abhi2011its the handle to the geometry in mged
17:21.31brlcadthe bbox routines you're working with are also not oobb's, they' aabb's
17:21.42abhi2011yes right
17:22.25brlcadso even for simple arb8's, you'll not be able to get objects doing anything more than translating without collision detection
17:22.39brlcadtranslation should be the first proof-of-concept step though
17:22.58abhi2011ok
17:23.49brlcade.g., take a 10x10x10 axis-aligned box at 0 0 100, drop it to a ground plane at 0 0 0
17:24.06brlcaddemo should either stop immediately or bounce :)
17:24.12CIA-62BRL-CAD: 03starseeker * r46451 10/brlcad/trunk/src/other/CMakeLists.txt: when doing win, also need xlib
17:24.17abhi2011yes ok
17:24.51abhi2011but say the user runs the sim for 100 steps
17:24.56brlcadthat initial collision detection could rely purely on bullet since the bb's are all axis-aligned
17:25.23brlcador you write a collision detection routine that just returns 1 if the bb's overlap
17:25.23abhi2011ok
17:25.33abhi2011right
17:25.52abhi2011about setting the position of the box
17:25.57abhi2011in mged
17:27.14brlcadso for starters, you should only work with comb's for now (in mged and in code), just to keep things simple
17:27.18brlcadone entity type
17:28.07brlcadno primitives by themselves
17:28.43abhi2011ok, and I set the comb position by simply obtaining how far the object has translated along z axis and using rt_matrix_transform() to translate the comb to the new position
17:29.06abhi2011I mean *how far the* comb* has translated
17:29.28brlcadyou know how to apply a translation matrix, I presume?
17:29.53abhi2011yes, just pass it to rt_matrix_transform()
17:30.12abhi2011with the proper elements set
17:30.46brlcadthere are loads of vector and matrix routines in vmath.h and libbn (bn.h and src/libbn)
17:31.24abhi2011ok
17:33.16brlcadfor example
17:33.57brlcadthe 'rot' and 'orot' (aka orotate) commands are how rotations are applied to geometry within mged
17:34.09brlcadsrc/libged/rot.c and src/libged/orot.c
17:34.45brlcadyou can see there how rot.c sets up a rotation vector and calls bn_mat_angles() to obtain a rotation matrix
17:35.47abhi2011yes, I have seen rot.c and orot.c, they both transform the object's existing orientation
17:35.56brlcadsimilarly orotate.c calls bn_mat_angles() but then also bn_mat_xform_about_pt() along with some routines to normalize the matrix before applying it to a comb
17:36.28abhi2011so I would need to get the transform of the comb wrt the position of the comb at the beginning of the sim
17:36.46abhi2011so if the comb is say at position 0,0,100 and at the end of it at 0,0,1
17:37.19abhi2011then I would need the translation matrix to be set for a translation of 0,0,99
17:37.21abhi2011and not the translation with respect to the origin of 0,0,1
17:38.36brlcadfor translation (what you need first), tra.c is keen which sets up a translation vector then calls vutil.c
17:39.15abhi2011yes I checked that yesterday, quite straighforward code
17:39.57abhi2011the mistake I was making was applying the wrong translations (with respect to the origin)
17:40.05brlcadactually, if it starts at 0,0,100, it won't end at 0,0,1 .. :)
17:40.37abhi2011yeah it will fall to 0,0,0
17:40.58abhi2011at the end
17:41.25abhi2011before bouncing around
17:42.08abhi2011if the ground plane is at 0,0,0
17:42.37brlcadif the box is 10x10x10, and you're using center as V and ground at 0,0,0, then it'll stop at 0,0,5 :)
17:43.02abhi2011yes , i was ignoring the height, yes right
17:46.06brlcadso what I imagine will happen is you'll get the bb's for all objects, pass those to bullet to set up the scene, perform one timestep and bullet is going to return some information indicating that the box moves down (a vector) OR that the box is in a new position (a new position)
17:46.14brlcadif it's a vector, you just apply it like tra
17:46.42brlcadif it's a point, you calculate the vector based on the previous position and apply that vector like tra
17:47.13abhi2011yes , I would need to create a rigid body and give it a collision shape in bullet, so I ll just use a box for now
17:47.49abhi2011yes right
17:49.03CIA-62BRL-CAD: 03starseeker * r46452 10/brlcad/trunk/src/other/incrTcl/itk/CMakeLists.txt: Ah, right - if itk is taking responsibility for its path setting, need to be more complete.
17:55.07*** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net)
18:03.34CIA-62BRL-CAD: 03n_reed * r46453 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Only reporting first syntax error instead of all of them.
18:06.22CIA-62BRL-CAD: 03starseeker * r46454 10/brlcad/trunk/src/other/incrTcl/itk/CMakeLists.txt: more itk build logic cleanup
18:14.07brlcadnice ... in response to "why reinvent the wheel?"
18:14.12brlcad"Because after long enough time, there's always someone who's irked about the performance of the wheel and wants to replace it with conveyor belts or robot legs. Sometimes even square wheels. And because we've done round wheels for so long, old lessons have faded or been deemed outdated and so we try it. Then it turns out it's not that great except for very limited use cases, but we're too deep invested and stubborn so we'll try fixing it. After a lot of fightin
18:15.48brlcadthat probably trucated the end...
18:15.50brlcad"After a lot of fighting against windmills, we slowly reinvent and rediscover the reasons why we used a wheel in the first place. Then the cycle starts over. Same with most NIH projects, they start out as being radically different and then end up looking much the same after tackling the same challenges."
18:17.01starseekerheh
18:18.07starseekersupposes some of the CMake logic probably would fall into that category...
18:20.51starseeker"oh, so THAT
18:20.58starseeker's why that compile flag is there"
18:45.17brlcadstarseeker: you could change the -D_FORTIFY_SOURCE=2 to a #define and you'd elimiante the MSVC conditional
18:46.09starseekererm.  you mean #define D_FORTIFY_SOURCE 2  in brlcad_config.h?
18:46.17starseekerhow would that eliminate the conditional?
18:46.38*** join/#brlcad Yoshi47 (~jan@64.235.102.210)
18:46.54brlcadyou're presently checking for a "c flag" (which is bogus, it's a cppflag) named "D_FORTIFY_SOURCE=2"
18:47.02*** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl)
18:47.12brlcadthat turns into -D_FORTIFY_SOURCE=2 to gcc
18:47.17starseekerright
18:47.26brlcadpresumably /D_FORTIFY_SOURCE=2 for msvc or something similar
18:48.06brlcadeither way, I assume you hit some compilation error due to that since the D_FORTIFY_SOURCE is rather lame gcc-specific way to test that flag
18:48.06CIA-62BRL-CAD: 03n_reed * r46455 10/brlcad/trunk/src/conv/obj-g_new.c: Added check for valid number of command line arguments.
18:48.17brlcadthat is equivalent to #define _FORTIFY_SOURCE 2
18:48.25starseekernot an error, just a blathering warning from MSVC
18:48.26brlcad-DVAR=VAL
18:48.36brlcadis #define VAR VAL
18:49.24brlcadso that's my point, you could eliminate the blather by outputting the symbol instead of trying to pass it as a compile flag
18:49.40brlcadless logic, no conditionals
18:51.07brlcadif (MSVC) conditionals make baby jesus cry, el no le gusta
18:51.11starseekershould it still be conditionalized on debugging?
18:51.15brlcadsure
18:51.20starseekerhmm...
18:51.59starseeker<snort> I'd say MSVC takes care of the crying all by itself
18:52.51brlcadsure, but it still gets to the whole platform vs feature issue -- the conditional is only valid today and is a major pita to maintain, debug, and unwind later
18:54.11brlcadthere's always a better way and it's usually not even more code if refactored according to dry principle
18:56.34CIA-62BRL-CAD: 03starseeker * r46456 10/brlcad/trunk/ (3 files in 3 dirs): Make _FORTIFY_SOURCE a config.h define instead of a compile flag check.
18:56.47starseekerthat what you mean?
18:57.45brlcadexactly
18:58.19starseekerwonders why he didn't do that initially... did I misread the autotools logic?
18:59.09brlcadwouldn't have been an msvc issue for autotools build
18:59.27brlcadmost all *nix platforms support -DVAR=VAL
18:59.37brlcads/platforms/compilers/ so the test works
18:59.48starseekerah, right
18:59.48brlcadthat assumption is flawed for non
18:59.54brlcad"non gcc-like" compilers
19:00.21brlcadCHECK_C_FLAG_GATHER must be something you wrote?
19:00.25starseekeryes
19:00.35brlcadbecause stfw results only in references to brl-cad :)
19:01.44starseekeryeah, there are a few custom macros - I really should probably try to cut down / consolidate those at some point
19:03.32n_reedbrlcad: stfw... your initialisms are starting to get obscure
19:14.59brlcad~stfw
19:14.59ibot[stfw] Search The F*cking Web.  See http://justf*ckinggoogleit.com/
19:15.56n_reedAlready looked it up.
19:17.02n_reedJust that "pita" took me a sec because it wasn't in caps. "dry" I knew, but stfw...
19:17.22brlcadwow, you knew dry but now stfw.. that's pretty much backwards ;)
19:17.36brlcaddry is pretty obscure
19:17.54brlcadhalf million hits for stfw can't be that obscure
19:18.20n_reedwell i don't text or chat as a rule, but i have read 97 things, so...
19:23.26brlcadstfw is pretty chat-specific, maybe even irc-specific
19:23.34brlcad(but not likely)
19:25.50``Erikdry is pretty big with ruby and python folk O.o
19:26.59n_reedof which i'm neither; that makes sense though i guess
19:56.29starseekerO.o  http://labs.qt.nokia.com/2011/08/24/qt-quick-3d-tutorial-video/
20:03.52CIA-62BRL-CAD: 03n_reed * r46457 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Allowing "" as a user-defined object name.
20:05.14CIA-62BRL-CAD: 03starseeker * r46458 10/brlcad/trunk/src/mged/CMakeLists.txt: Fix space in mged CMakeLists.txt - also did this for bwish, got sucked into a previous commit.
20:29.41starseekerwoot! new obj-g (kinda) works on Windows
21:14.36abhi2011brlcad:  I have a question regarding solid table pointers : const struct soltab
21:15.40abhi2011so is there a way to get one from the struct rt_db_internal of a primtive
21:16.30abhi2011I need to insert it into the rt_comb_internal
21:16.40abhi2011while finding the bb of a primtive
21:26.06abhi2011or I can avoid making a rt_comb_internal and just use the bounds already got in the rtip (as rt_gettree() has been called)
21:31.07abhi2011there is a third option to use ip->idb_meth->ft_bbox() which is the new interface for finding bbs of primitives, but thats known to not work correctly for BOTs
21:39.01abhi2011hmm found rt_find_solid(), will use that
22:11.48*** join/#brlcad merzo (~merzo@24-13-133-95.pool.ukrtel.net)
23:11.30CIA-62BRL-CAD: 03n_reed * r46459 10/brlcad/trunk/src/conv/obj-g_new.c: MSVC compiler doesn't support %zu format. Changed all instances to %lu.

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.