| 02:06.02 | *** join/#brlcad nsd_ (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) |
| 02:38.05 | starseeker | bhinesley: excellent! |
| 02:47.17 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 05:11.11 | abhi2011 | ok I have got objects updating inside mged now using rt_matrix_transform() according to bullet output |
| 10:44.25 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 11:48.08 | abhi2011 | ok I was wondering how conditional compiling is implemented in the build system |
| 11:48.43 | abhi2011 | so I have some files which are based on Bullet's libraries, but if Bullet is not installed then the compile will fail |
| 11:49.19 | abhi2011 | yet if these files are not compiled then a function which is called from libged will not exsist and that too would cause the build to fail |
| 11:50.05 | abhi2011 | perhaps there is a way to compile a dummy function in a separate file if bullet is not detected , so both the above errors can be avoided ? |
| 11:53.19 | kunigami1 | abhi2011: you can do something I did for OSL. take a look at Cmakelists.txt at liboptical |
| 11:53.39 | abhi2011 | kunigami1: thanks I ll take a look |
| 11:59.46 | abhi2011 | ok so you use a top level cmake flag to enable or disable osl : BRLCAD-ENABLE_OSL |
| 12:00.13 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 12:57.10 | starseeker | IF(BULLET_FOUND) could be my first guess |
| 13:07.34 | *** join/#brlcad Elrohir (~kvirc@p5B149541.dip.t-dialin.net) |
| 13:50.19 | kunigami1 | abhi2011: by the way, to set the BLCAD-ENABLE_OSL flag there, you can call cmake with -DBRLCAD-ENABLE_OSL=ON |
| 13:54.14 | CIA-62 | BRL-CAD: 03erikgreenwald * r46310 10/brlcad/trunk/src/libged/simulate.c: #if 0 out some unused code |
| 13:54.48 | CIA-62 | BRL-CAD: 03erikgreenwald * r46311 10/brlcad/trunk/src/mged/cmd.c: remove unused variable |
| 14:00.21 | *** join/#brlcad abhi2011 (~chatzilla@wlan-145-94-185-238.wlan.tudelft.nl) |
| 14:39.24 | ``Erik | fwiw, I believe today is "pencils down" for gsoc |
| 14:40.42 | ``Erik | abhi: awesome, very awesome |
| 14:47.32 | abhi2011 | yep preparing the cmake logic for commit now :) |
| 15:33.59 | CIA-62 | BRL-CAD: 03d_rossberg * r46312 10/brlcad/trunk/src/librt/ (bbox.c primitives/rpc/rpc.c): |
| 15:33.59 | CIA-62 | BRL-CAD: For the Windows build: MSVC is not C99 |
| 15:33.59 | CIA-62 | BRL-CAD: moved variable declarations upwards |
| 15:43.15 | CIA-62 | BRL-CAD: 03bob1961 * r46313 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): The rectangle used for selection was no longer being drawn due to a previous modification (i.e. not drawing rectangle if its lwidth is 0). This restores the desired behavior in Archer. |
| 15:44.55 | plaes | congrats on the new logo |
| 16:40.40 | *** join/#brlcad DarkCalf (DC@173.231.40.98) |
| 19:01.35 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 19:36.45 | brlcad | starseeker: for submodels, each callback is basically a mini program in itself meaning they have to open the subdatabase files (like rt and company) to do their processing |
| 19:36.58 | brlcad | responding to backlog so comments may be OBE |
| 19:45.27 | brlcad | abhi2011: there should be no reason to prefer static over dynamic libraries when linking bullet (and you shouldn't be adding /usr/local/* to the default link/search paths (e.g., LINK_DIRECTORIES)) .. that's something to be specified during cmake |
| 19:46.07 | brlcad | (i.e. that's a "non-std" location in itself) |
| 19:47.16 | brlcad | plaes: thx! it is pretty nifty |
| 19:47.40 | plaes | yup, nice and simple |
| 19:53.04 | brlcad | kunigami1: you can't export variables to a parent context so you'd have to wrap that in a script |
| 19:53.53 | plaes | are these images here created with brlcad: http://ronja.twibright.com/3d/ ? |
| 19:54.07 | brlcad | abhi2011: you can't just mark a variable as 'const' and expect it to work -- that's why I said you'd have to make a copy. if you're calling a non-const function but need the object to remain unmodified, you have to make your own copy of that object beforehand |
| 19:54.12 | brlcad | plaes: yes |
| 19:55.36 | plaes | how do I save such images? :) |
| 19:57.04 | brlcad | what do you mean? |
| 19:57.56 | *** join/#brlcad DarkCalf (DC@173.231.40.98) |
| 19:58.03 | plaes | well, I know that the models are made by brlcad, but how do I save such black-and-white images |
| 19:58.58 | brlcad | rtedge |
| 19:59.17 | plaes | \o/ |
| 19:59.20 | brlcad | rt is the usual renderer, but there are a handful of other rt* renderes |
| 19:59.54 | brlcad | rt and rtedge both work within mged equivalently |
| 20:00.04 | brlcad | some of the others are external to mged |
| 20:00.14 | brlcad | all can be run external |
| 20:01.09 | plaes | lots of cool stuff still hidden in all these programs ;) |
| 20:01.22 | brlcad | nods |
| 20:04.36 | plaes | building stuff with primitives is like "simulating" machining.. ;) |
| 20:06.20 | plaes | first build a part on the computer and then try it out in real life - http://timmu.store20.com/galerii/?galerie=frees |
| 20:17.45 | abhi2011 | brlcad: ok , yes I understand now |
| 20:19.43 | abhi2011 | I was checking with the db_functree() function and i saw that it tries to lookup the primitives for a combination in the dbip which I pass to it, which is of course what it should do |
| 20:20.31 | abhi2011 | and it fails as expected as the dbip does not have the primitive in it , as its the in mem db_i I made in the function |
| 20:22.20 | brlcad | plaes: that's a pretty nifty old machine there |
| 20:22.39 | abhi2011 | so its back to square one , which is how to get union tree for the constituent primitives when passed just the rt_db_internal for a region containing those primitives |
| 20:29.20 | brlcad | abhi2011: that's why I said earlier that in order to call db_functree(), you need to use the unmodified dbi from the original dbip ... not your in-mem copy |
| 20:29.50 | brlcad | to use the inmem, you'd need to recursively call db_functree() on the original dbi and copy them into the inmem, just so you could look them up again |
| 20:30.02 | brlcad | basically a big pain and probably unnecessary |
| 20:30.25 | brlcad | much easier to create a new comb, add your primitive, then have all objects go through the other existing bb routine |
| 20:30.42 | abhi2011 | brlcad: ok yah that would work, I was trying to find a way to not pass an extra parameter as the idea was to just pass a rt_db_internal |
| 20:31.08 | abhi2011 | yes so I tried making a comb too |
| 20:31.14 | abhi2011 | however it needs a tree as well |
| 20:31.27 | abhi2011 | if you lines 414 to 418 in bbox.c |
| 20:31.32 | abhi2011 | *if you see |
| 20:31.44 | brlcad | you don't need an extra parameter |
| 20:32.18 | abhi2011 | the unmodfiied db_i is globally available then ? |
| 20:32.35 | abhi2011 | the original db_i i mean |
| 20:33.21 | brlcad | I think you might be a bit confused by the different approaches being discussed |
| 20:34.22 | abhi2011 | well there are 2 approaches : either use db_functree() or make a comb :) |
| 20:35.10 | abhi2011 | since making a comb is easier , lets focus on that then |
| 20:36.14 | abhi2011 | so the idea was that make a rt_comb_internal with 1 leaf for shapes , for combinations, well they are already a rt_comb_internal |
| 20:36.43 | brlcad | so far, sounding good |
| 20:36.50 | abhi2011 | ok :P |
| 20:37.33 | abhi2011 | so the basics challenge in making a rt_comb_internal out of a shape is : the tree parameter in the rt_comb_internal structure |
| 20:37.50 | CIA-62 | BRL-CAD: 03bob1961 * r46314 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Updated ArcherCore::selectTreePath to make the selected tree item visible. |
| 20:38.10 | abhi2011 | or rather the tree member |
| 20:38.12 | brlcad | not a challenge at all erally :) |
| 20:38.38 | abhi2011 | umm but I would need the tree for the shape right, I cant get that from the rt_db_internal |
| 20:38.56 | brlcad | you need a tree, yes |
| 20:39.09 | brlcad | filling in a tree is simple |
| 20:39.34 | brlcad | if the rt_db_internal is already a comb, you can just access the comb's tree |
| 20:39.50 | brlcad | if the rt_db_internal is a primitive, you'll make a comb and add that primitive to the comb's tree |
| 20:40.21 | abhi2011 | so something like combp->tree = intern->tree |
| 20:40.23 | brlcad | see the comb.c file, for the comb command, shows creating an rt_comb_internal and filling it in |
| 20:40.34 | abhi2011 | where intern is the rt_db_internal |
| 20:40.41 | abhi2011 | for the primitive |
| 20:40.53 | brlcad | that doesn't look or sound right |
| 20:41.16 | brlcad | intern->tree is not valid |
| 20:41.39 | abhi2011 | yes rt_db_internal does not have a tree member, so the tree in the rt_db_internal has to be accessed |
| 20:42.01 | abhi2011 | ok that part should be easy |
| 20:42.11 | brlcad | IFF intern is a comb, then intern->idb_ptr is an rt_comb_internal |
| 20:42.20 | abhi2011 | oh! :P |
| 20:42.56 | abhi2011 | umm no I knew that |
| 20:43.22 | abhi2011 | IFF intern is a primitive, then where is the tree , will find that out |
| 20:43.29 | brlcad | so you'd call something like rt_bound_tree(intern->idb_ptr->tree) if it's a comb or rt_bound_tree(my_comb->tree) if it's a primitive |
| 20:43.29 | abhi2011 | :) |
| 20:43.46 | abhi2011 | yes I understand that |
| 20:44.03 | brlcad | you have to make my_comb |
| 20:44.08 | abhi2011 | yes |
| 20:44.13 | brlcad | see comb.c :) |
| 20:44.19 | abhi2011 | yep :) |
| 20:44.32 | brlcad | you'll need a tiny subset similar to what _ged_combadd() does |
| 20:45.02 | brlcad | look for the GETSTRUCT lines to see where an rt_comb_internal is allocated |
| 20:45.19 | abhi2011 | ok |
| 20:46.46 | abhi2011 | by the way , on a different note, I am curious about the other approach : that is using db_functree(), you said the original db_i need not be passed |
| 20:47.09 | abhi2011 | so then it can be got using a global variable or a function ? |
| 20:52.24 | brlcad | no, I think you're misunderstanding something I was saying -- you are passed a db_i to your function -- you can just use it |
| 20:52.32 | brlcad | you just need to make a copy of it if you're going to pass it to some other non-const function |
| 20:54.55 | abhi2011 | well , the function is like this : int rt_bound_internal(struct rt_db_internal *ip, point_t rpp_min, point_t rpp_max), so there is no db_i passed |
| 20:55.53 | brlcad | sorry, I was using "db_i" to mean db_internal |
| 20:56.21 | brlcad | not to be confused with a database instance db_i |
| 20:56.24 | abhi2011 | oh ok , I though you meant struct db_i |
| 20:56.28 | abhi2011 | yah i get it :) |
| 20:57.35 | brlcad | you only needed a db_i to call rt_dirbuild() iirc, so that primitive bounding boxes get calculated |
| 20:58.11 | abhi2011 | yes, this db_i however was constructed from the original .g database file |
| 20:58.20 | abhi2011 | so it had all the primitives |
| 20:58.21 | brlcad | that approach is still fine, it's just combs that are even simpler with rt_bound_tree(ip->idb_ptr->tree) |
| 20:58.41 | abhi2011 | yes |
| 20:58.46 | abhi2011 | <PROTECTED> |
| 20:59.00 | abhi2011 | meanwhile, I got bullet running in mged |
| 20:59.04 | abhi2011 | and the cmake logic done |
| 20:59.08 | brlcad | outstanding |
| 20:59.33 | abhi2011 | about to commit that : had some changes to top level cmake file , hope starseeker is standing by :P |
| 20:59.35 | brlcad | sounds like more work is needed on the cmake logic, but shouldn't be too difficult |
| 20:59.48 | brlcad | what's the diff look like? |
| 21:00.05 | abhi2011 | I ll pastebin it 1 sec |
| 21:01.19 | abhi2011 | basically added logic to compile a dummy simulate.c file that does nto bullet headers, if bullet is absent |
| 21:01.46 | abhi2011 | in the top level there is logic to find the bullet library and link /usr/local/lib |
| 21:03.10 | brlcad | presuming you saw my earlier comment, assuming /usr/local/lib is no good |
| 21:04.04 | abhi2011 | oh ok, I think I missed that |
| 21:04.31 | abhi2011 | reading now :) |
| 21:04.40 | brlcad | I mean, /usr/local is probalby the only "non-default" system locations that could be added, but adding it should be systematic for include headers, libs, and bins |
| 21:05.11 | brlcad | and it still shouldn't be subdir aware like /usr/local/lib/bullet/. |
| 21:06.03 | brlcad | libs not in "system" paths should be declared to cmake or handled by some Find*.cmake routines |
| 21:07.46 | abhi2011 | ok, I would have thought that /usr/local/lib would be searched by default by cmake |
| 21:07.57 | abhi2011 | so I would not need to specify it |
| 21:08.18 | abhi2011 | well I am using the stock FindBullet.cmake module |
| 21:09.09 | abhi2011 | its installed by cmake, and it finds and sets the ${BULLET_INCLUDE_DIR}, ${BULLET_LIBRARIES} correctly |
| 21:09.44 | abhi2011 | but its not setting the ${BULLET_LIBRARY_DIR} variable, which is what I would link to , to keep things standard |
| 21:10.35 | abhi2011 | here is the top level CMakeLists.txt diff : http://bin.cakephp.org/view/1810550039 |
| 21:10.46 | abhi2011 | will try to get rid of LINK_DIRECTORIES("/usr/local/lib") |
| 21:13.17 | abhi2011 | this is the libged/CMakeLists.txt file that also required changes : http://bin.cakephp.org/view/860235467 |
| 21:16.44 | abhi2011 | ok , so I am thinking maybe I can remove the LINK_DIRECTORIES("/usr/local/lib") line in the top level CMakeLists.txt file |
| 21:17.09 | abhi2011 | as long as a user does not enable bullet , the rest of the build will be fine |
| 21:17.27 | abhi2011 | if he does enable bullet, then there will be a linking error |
| 21:17.53 | abhi2011 | so the exact location where the user has installed the libs can be specified using a cmake command line flag |
| 21:18.20 | abhi2011 | that would eliminate any hardcoded library paths |
| 21:21.55 | abhi2011 | of course that begs the question as to why ${BULLET_LIBRARY_DIR} is not being set by the stock FindBullet.cmake module , its probably not looking at the right place |
| 21:26.28 | brlcad | so several comments |
| 21:26.50 | brlcad | sure, searching /usr/local/lib might be expected .. but that has nothing to do with bullet and shouldn't be part of your patch/commit |
| 21:27.12 | brlcad | certainly shouldn't be specific to an if(BRLCAD-ENABLE_BULLET) section |
| 21:27.58 | brlcad | which brings up my second point, and enable/disable toggle for that seems unnecessary -- it should test for bullet and, if found, use it. otherwise, the command implementation is disabled at compile-time |
| 21:30.08 | abhi2011 | brlcad: ok I understand |
| 21:30.26 | brlcad | abhi2011: you also do not need simulatedummy.c -- that should be logic contained within the simulate.c file (#ifdef) OR put it all in a subdir with it's own CMakeLists.txt file |
| 21:30.45 | brlcad | probably should put it all in a subdir anyways just because you have multiple implementation files |
| 21:31.13 | abhi2011 | ok , yes that will be easier |
| 21:32.25 | abhi2011 | yes I thought about the #ifdef , but I havent found a compile time symbol that is defined if bullet was found |
| 21:33.38 | abhi2011 | ok, I think there will be some symbol which will be defined if the bullet headers are detected, will go through the headers |
| 21:33.48 | brlcad | if one is not defined, you can define one |
| 21:33.59 | brlcad | but make sure one isn't already defined |
| 21:34.04 | abhi2011 | yes, but bullet is detected by cmake |
| 21:34.16 | brlcad | yes, so? :) |
| 21:34.20 | abhi2011 | i cant define a symbol to be used in a c file , in the cmake logic |
| 21:34.26 | brlcad | sure you can |
| 21:34.29 | abhi2011 | umm...but as usual i am off mark :P |
| 21:34.37 | abhi2011 | ok thats totally cool :) |
| 21:34.56 | abhi2011 | ok will find out about it |
| 21:35.15 | brlcad | see include/brlcad_config.h in your build directory for a list of symbols already being defined during cmake |
| 21:35.26 | abhi2011 | ok |
| 22:02.07 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 22:15.15 | *** join/#brlcad kunigami (~kunigami@201.53.206.27) |
| 23:00.39 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 23:28.47 | CIA-62 | BRL-CAD: 03brlcad * r46315 10/brlcad/trunk/src/libged/edit.c: quellage, may be unitialized |