IRC log for #brlcad on 20110829

03:50.06 CIA-62 BRL-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.05 CIA-62 BRL-CAD: 03Abhi2011 07http://brlcad.org * r3085 10/wiki/User:Abhijit: /* Log */
09:35.25 CIA-62 BRL-CAD: 03Abhi2011 07http://brlcad.org * r3086 10/wiki/User:Abhijit: /* Log */
11:10.13 *** join/#brlcad juanman (~quassel@unaffiliated/juanman)
12:38.19 abhi2011 brlcad: about passing the struct db_i* in rt_bound_internal()
12:40.13 abhi2011 it would be necessary to call rt_gettree() inside this function
12:40.33 abhi2011 to get the primtives for a comb loaded
12:40.55 abhi2011 is that fine, or would it be better to avoid calling rt_gettree() ?
12:41.37 abhi2011 if I do need to call rt_gettree(), then the 2nd parameter is the name of the comb/primitive
12:44.16 abhi2011 which is generally got using a directory pointer using dp->d_namep
12:45.42 abhi2011 the only way to get a directory pointer is to use again use name of the comb and then db_lookup()
12:48.17 abhi2011 I have been searching for getting the comb or primitive name from a struct rt_db_internal if at its possible
12:51.10 abhi2011 seems all of this can be avoided if the caller code simply calls rt_gettree() before passing the struct rt_db_internal*
12:51.23 abhi2011 then we do not even need to pass the struct db_i *
12:54.56 abhi2011 or the calling code can pass the name of the comb/primitive
13:18.20 *** join/#brlcad juanman (~quassel@unaffiliated/juanman)
14:16.20 CIA-62 BRL-CAD: 03starseeker * r46446 10/brlcad/trunk/TODO.cmake: Update todo items for CMake
14:48.43 CIA-62 BRL-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.18 CIA-62 BRL-CAD: 03starseeker * r46448 10/brlcad/trunk/src/other/re2c/bootstrap/parser.hh: May need the parser.hh file too...
15:04.54 CIA-62 BRL-CAD: 03starseeker * r46449 10/brlcad/trunk/src/other/re2c/bootstrap/parser.hh: fix comment
15:08.16 CIA-62 BRL-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.44 brlcad abhi2011: gah
16:44.22 brlcad that's a problem, rt_db_internals are nameless ... forgot about that
16:44.30 abhi2011 oh shoot :P
16:44.42 abhi2011 yeah by the time its reaches the rt layer
16:44.46 abhi2011 names are no longer relevant
16:45.01 brlcad that's by design, so you can write a given rt_db_internal as many times as you want with different names
16:45.19 abhi2011 ok
16:45.21 brlcad you might have to resort one layer higher, with a struct directory *
16:46.26 abhi2011 yes , 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.59 brlcad huh?
16:47.14 brlcad libged knows the name
16:47.26 brlcad the same name you used to get the rt_db_internal
16:47.36 brlcad instead of that, you'll just pass the directory
16:48.48 abhi2011 oh 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.04 brlcad if you pass the dp, you no longer should pass the ip
16:49.09 brlcad you can get the ip from the dp
16:49.12 abhi2011 yes right
16:49.15 abhi2011 ok
16:49.26 abhi2011 I was wondering :)
16:49.39 abhi2011 why we simply have a function which accepts the dp and the name
16:49.52 abhi2011 um no scratch that
16:50.05 abhi2011 dp and dbip is enough
16:50.38 abhi2011 i thought it would be easy to have a function that just accept the name of the comb/primitive and the dbip
16:50.49 abhi2011 that would be easy to pass by a user
16:51.37 abhi2011 something like rt_bound_internal(char*name , struct db_i *dbip, point_t rpp_min, point_t rpp_max)
16:52.14 brlcad that's libged's responsibility
16:52.22 abhi2011 oh ok
16:52.25 brlcad libged works with strings, names
16:52.34 abhi2011 ok
16:53.56 abhi2011 yeah I get it now :)
16:53.57 brlcad really, 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.04 abhi2011 yes
16:54.14 brlcad don't are about names (or even directory), just want the bb given geometry
16:54.28 abhi2011 yes true
16:54.37 brlcad working with a dbip+dp is a start, though
16:55.13 brlcad that can be refactored to call a lower-level calculate-my-bb-with-just-this-ip later
16:55.53 abhi2011 ok
16:57.59 abhi2011 I have a question regarding the transformation matrices of primitives
16:58.45 abhi2011 so in the commands that somehow transform the object, I can see that the commands generally call rt_matrix_transform()
17:00.00 abhi2011 and this function ultimately goes and put a new matrix in the tl_mat member of the struct union tree
17:00.22 abhi2011 that exists in the tr_l member of a union tree*
17:00.40 brlcad usually
17:00.46 abhi2011 however this is a transform matrix, not the matrix representing the absolute world position
17:01.07 abhi2011 however bullet gives me the matrix that represents the transform in absolute world co-ordinates
17:01.50 abhi2011 so 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.27 abhi2011 now the thing is, I generally copy an existing object in mged, and then apply bullet's transform on it
17:02.41 abhi2011 however this new object is no made at the origin
17:02.58 abhi2011 its made in the existing object's position
17:03.09 abhi2011 which is correct as far as copying is concerned
17:03.42 brlcad waits for the question
17:03.51 abhi2011 however , it would be great if I were able to reset any copies I make , to the origin
17:04.02 abhi2011 there are no such commands to do this in mged however
17:04.38 abhi2011 and 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.57 brlcad you're going way too far down the rabbit hole
17:05.08 abhi2011 :)
17:05.11 brlcad ask a question :)
17:05.46 brlcad or at least ask me to explain how brl-cad tracks positions if you don't know what to ask :)
17:05.52 abhi2011 ok
17:06.39 abhi2011 yeah it would be better if you explain :)
17:07.02 abhi2011 my issue is how to apply the bullet transforms on a object which is not at the origin
17:07.48 abhi2011 since 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.28 brlcad so 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.15 brlcad geometry in brl-cad is described in a rather pure mathematical sense, sometimes in implicit form and sometimes in an explicit form
17:11.13 abhi2011 yes
17:12.28 abhi2011 however the positions of the objects are stored explicitly somewhere in a comb/prims attributes
17:12.44 brlcad yes and no (sorry multitasking)
17:12.52 brlcad combinations, for example, have no position
17:12.59 brlcad they are just a grouping
17:13.06 abhi2011 ah yes right
17:13.08 brlcad they can apply a transformation to that grouping
17:13.20 abhi2011 ok
17:13.21 brlcad that have an *implicit* position
17:13.35 abhi2011 ok
17:13.41 brlcad it's implied that the position of a combination is the position of all it's continuent submembers
17:13.48 abhi2011 yes right
17:14.06 brlcad so 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.30 abhi2011 ok
17:14.36 brlcad the same can be said of all of the primitives
17:14.57 brlcad many/most of them have an explicit position, but it's defined per primitive
17:15.18 abhi2011 ok
17:16.25 starseeker remembers he needs to look at rt_bot_bbox again...
17:16.26 brlcad for 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.00 brlcad you could get at that "position", but it's somewhat meaningless for this purpose
17:17.10 brlcad all that matters really is having a consistent handle
17:17.13 brlcad that's where the bb comes in
17:17.33 abhi2011 ok
17:17.35 brlcad get the bb for any object, then you can consistently consider the bb center to be a position
17:18.00 abhi2011 ok
17:18.02 brlcad from bullet's perspective, all you're dealing with is a lot of boxes
17:18.09 abhi2011 yes true
17:18.24 brlcad you can implement an overlap/collision detection handler later
17:18.42 abhi2011 however a bb would not roll on a surface even if it represents a sphere
17:18.49 abhi2011 yes right
17:19.00 brlcad sure it will
17:19.24 brlcad at least, it should be able to
17:19.47 brlcad you're not using the "box" as *geometry*
17:19.54 brlcad that's just your handle
17:19.59 abhi2011 yes right I get that now
17:20.20 abhi2011 its the handle to the geometry in mged
17:21.31 brlcad the bbox routines you're working with are also not oobb's, they' aabb's
17:21.42 abhi2011 yes right
17:22.25 brlcad so even for simple arb8's, you'll not be able to get objects doing anything more than translating without collision detection
17:22.39 brlcad translation should be the first proof-of-concept step though
17:22.58 abhi2011 ok
17:23.49 brlcad e.g., take a 10x10x10 axis-aligned box at 0 0 100, drop it to a ground plane at 0 0 0
17:24.06 brlcad demo should either stop immediately or bounce :)
17:24.12 CIA-62 BRL-CAD: 03starseeker * r46451 10/brlcad/trunk/src/other/CMakeLists.txt: when doing win, also need xlib
17:24.17 abhi2011 yes ok
17:24.51 abhi2011 but say the user runs the sim for 100 steps
17:24.56 brlcad that initial collision detection could rely purely on bullet since the bb's are all axis-aligned
17:25.23 brlcad or you write a collision detection routine that just returns 1 if the bb's overlap
17:25.23 abhi2011 ok
17:25.33 abhi2011 right
17:25.52 abhi2011 about setting the position of the box
17:25.57 abhi2011 in mged
17:27.14 brlcad so for starters, you should only work with comb's for now (in mged and in code), just to keep things simple
17:27.18 brlcad one entity type
17:28.07 brlcad no primitives by themselves
17:28.43 abhi2011 ok, 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.06 abhi2011 I mean *how far the* comb* has translated
17:29.28 brlcad you know how to apply a translation matrix, I presume?
17:29.53 abhi2011 yes, just pass it to rt_matrix_transform()
17:30.12 abhi2011 with the proper elements set
17:30.46 brlcad there are loads of vector and matrix routines in vmath.h and libbn (bn.h and src/libbn)
17:31.24 abhi2011 ok
17:33.16 brlcad for example
17:33.57 brlcad the 'rot' and 'orot' (aka orotate) commands are how rotations are applied to geometry within mged
17:34.09 brlcad src/libged/rot.c and src/libged/orot.c
17:34.45 brlcad you can see there how rot.c sets up a rotation vector and calls bn_mat_angles() to obtain a rotation matrix
17:35.47 abhi2011 yes, I have seen rot.c and orot.c, they both transform the object's existing orientation
17:35.56 brlcad similarly 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.28 abhi2011 so I would need to get the transform of the comb wrt the position of the comb at the beginning of the sim
17:36.46 abhi2011 so if the comb is say at position 0,0,100 and at the end of it at 0,0,1
17:37.19 abhi2011 then I would need the translation matrix to be set for a translation of 0,0,99
17:37.21 abhi2011 and not the translation with respect to the origin of 0,0,1
17:38.36 brlcad for translation (what you need first), tra.c is keen which sets up a translation vector then calls vutil.c
17:39.15 abhi2011 yes I checked that yesterday, quite straighforward code
17:39.57 abhi2011 the mistake I was making was applying the wrong translations (with respect to the origin)
17:40.05 brlcad actually, if it starts at 0,0,100, it won't end at 0,0,1 .. :)
17:40.37 abhi2011 yeah it will fall to 0,0,0
17:40.58 abhi2011 at the end
17:41.25 abhi2011 before bouncing around
17:42.08 abhi2011 if the ground plane is at 0,0,0
17:42.37 brlcad if 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.02 abhi2011 yes , i was ignoring the height, yes right
17:46.06 brlcad so 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.14 brlcad if it's a vector, you just apply it like tra
17:46.42 brlcad if it's a point, you calculate the vector based on the previous position and apply that vector like tra
17:47.13 abhi2011 yes , 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.49 abhi2011 yes right
17:49.03 CIA-62 BRL-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.34 CIA-62 BRL-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.22 CIA-62 BRL-CAD: 03starseeker * r46454 10/brlcad/trunk/src/other/incrTcl/itk/CMakeLists.txt: more itk build logic cleanup
18:14.07 brlcad nice ... in response to "why reinvent the wheel?"
18:14.12 brlcad "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.48 brlcad that probably trucated the end...
18:15.50 brlcad "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.01 starseeker heh
18:18.07 starseeker supposes some of the CMake logic probably would fall into that category...
18:20.51 starseeker "oh, so THAT
18:20.58 starseeker 's why that compile flag is there"
18:45.17 brlcad starseeker: you could change the -D_FORTIFY_SOURCE=2 to a #define and you'd elimiante the MSVC conditional
18:46.09 starseeker erm. you mean #define D_FORTIFY_SOURCE 2 in brlcad_config.h?
18:46.17 starseeker how would that eliminate the conditional?
18:46.38 *** join/#brlcad Yoshi47 (~jan@64.235.102.210)
18:46.54 brlcad you'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.12 brlcad that turns into -D_FORTIFY_SOURCE=2 to gcc
18:47.17 starseeker right
18:47.26 brlcad presumably /D_FORTIFY_SOURCE=2 for msvc or something similar
18:48.06 brlcad either 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.06 CIA-62 BRL-CAD: 03n_reed * r46455 10/brlcad/trunk/src/conv/obj-g_new.c: Added check for valid number of command line arguments.
18:48.17 brlcad that is equivalent to #define _FORTIFY_SOURCE 2
18:48.25 starseeker not an error, just a blathering warning from MSVC
18:48.26 brlcad -DVAR=VAL
18:48.36 brlcad is #define VAR VAL
18:49.24 brlcad so 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.40 brlcad less logic, no conditionals
18:51.07 brlcad if (MSVC) conditionals make baby jesus cry, el no le gusta
18:51.11 starseeker should it still be conditionalized on debugging?
18:51.15 brlcad sure
18:51.20 starseeker hmm...
18:51.59 starseeker <snort> I'd say MSVC takes care of the crying all by itself
18:52.51 brlcad sure, 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.11 brlcad there's always a better way and it's usually not even more code if refactored according to dry principle
18:56.34 CIA-62 BRL-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.47 starseeker that what you mean?
18:57.45 brlcad exactly
18:58.19 starseeker wonders why he didn't do that initially... did I misread the autotools logic?
18:59.09 brlcad wouldn't have been an msvc issue for autotools build
18:59.27 brlcad most all *nix platforms support -DVAR=VAL
18:59.37 brlcad s/platforms/compilers/ so the test works
18:59.48 starseeker ah, right
18:59.48 brlcad that assumption is flawed for non
18:59.54 brlcad "non gcc-like" compilers
19:00.21 brlcad CHECK_C_FLAG_GATHER must be something you wrote?
19:00.25 starseeker yes
19:00.35 brlcad because stfw results only in references to brl-cad :)
19:01.44 starseeker yeah, there are a few custom macros - I really should probably try to cut down / consolidate those at some point
19:03.32 n_reed brlcad: stfw... your initialisms are starting to get obscure
19:14.59 brlcad ~stfw
19:14.59 ibot [stfw] Search The F*cking Web. See http://justf*ckinggoogleit.com/
19:15.56 n_reed Already looked it up.
19:17.02 n_reed Just that "pita" took me a sec because it wasn't in caps. "dry" I knew, but stfw...
19:17.22 brlcad wow, you knew dry but now stfw.. that's pretty much backwards ;)
19:17.36 brlcad dry is pretty obscure
19:17.54 brlcad half million hits for stfw can't be that obscure
19:18.20 n_reed well i don't text or chat as a rule, but i have read 97 things, so...
19:23.26 brlcad stfw is pretty chat-specific, maybe even irc-specific
19:23.34 brlcad (but not likely)
19:25.50 ``Erik dry is pretty big with ruby and python folk O.o
19:26.59 n_reed of which i'm neither; that makes sense though i guess
19:56.29 starseeker O.o http://labs.qt.nokia.com/2011/08/24/qt-quick-3d-tutorial-video/
20:03.52 CIA-62 BRL-CAD: 03n_reed * r46457 10/brlcad/trunk/src/libgcv/wfobj/obj_grammar.yy: Allowing "" as a user-defined object name.
20:05.14 CIA-62 BRL-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.41 starseeker woot! new obj-g (kinda) works on Windows
21:14.36 abhi2011 brlcad: I have a question regarding solid table pointers : const struct soltab
21:15.40 abhi2011 so is there a way to get one from the struct rt_db_internal of a primtive
21:16.30 abhi2011 I need to insert it into the rt_comb_internal
21:16.40 abhi2011 while finding the bb of a primtive
21:26.06 abhi2011 or 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.07 abhi2011 there 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.01 abhi2011 hmm found rt_find_solid(), will use that
22:11.48 *** join/#brlcad merzo (~merzo@24-13-133-95.pool.ukrtel.net)
23:11.30 CIA-62 BRL-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.