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. |