| 00:15.37 | abhi2011 | brlcad: I have modifying the bb function to work on groups and regions : http://bin.cakephp.org/view/1394071764 |
| 00:16.32 | abhi2011 | I am calling rt_gettree() before rt_bound_tree() to evaluate the tree first |
| 00:17.59 | abhi2011 | I am testing with a region made as follows in mged r part1.r u rcc2.s - sph2.s |
| 00:19.18 | abhi2011 | so when traversing the tree in the rt_bound_tree() call , the first call sees the subtraction operator in tp->tr_op and proceeds smoothly down to the left child |
| 00:20.34 | abhi2011 | however in the left tree where it should find the primitive rcc2.s, it encounters an unknown op 12, I think it should have encountered a tr_op = OP_SOLID for the rcc.s primitive |
| 00:22.05 | abhi2011 | this is probably related to the fact that the rt_gettree() calls reports missing primitives for the region : db_lookup(rcc2.s) failed in /dummy, db_lookup(sph2.s) failed in /dummy, |
| 00:22.07 | abhi2011 | rt_gettrees(dummy) warning: no primitives found |
| 00:24.31 | abhi2011 | so probably the missing primitives need to be added to the dbi , before the rt_gettree() call, so that the tree is evaluated properly |
| 00:53.16 | abhi2011 | ok, 12 is a OP_DB_LEAF as defined in raytrace.h: line 1177, wonder why rt_bound_tree() cant interpret it |
| 01:23.29 | starseeker | hah, cool: http://www.pointclouds.org/ |
| 01:27.00 | starseeker | wonders if we can feed raytrace points into that and get NURBS back... |
| 01:43.08 | starseeker | bhinesley: curious - how close is your command to being fully functional? |
| 02:09.12 | CIA-62 | BRL-CAD: 03starseeker * r45959 10/brlcad/trunk/CMakeLists.txt: Make sure BRLCAD_BUNDLED_LIBS is in the cache |
| 02:31.17 | CIA-62 | BRL-CAD: 03starseeker * r45960 10/brlcad/trunk/ (misc/CMake/ThirdParty_TCL.cmake src/other/CMakeLists.txt): Tweaks to get Tcl/Tk package testing going again. |
| 02:34.29 | bhinesley | starseeker: translate? Quite; I'd say that the "generic" subcommand processing plus the translate command is at 90% at worst. I'd planed on putting in some time this weekend, in the hopes that I will have translate completed, which would imply that generic subcommand processing is done as well. I'm aiming to have 'rotate' done by the end of GSoC; I'm not sure if I can, but that's what I'm shooting for. I highly doubt that I |
| 02:37.13 | CIA-62 | BRL-CAD: 03starseeker * r45961 10/brlcad/trunk/CMakeLists.txt: Constrain the CMake dropdown menu options for CMAKE_BUILD_TYPE to Debug and Release |
| 02:48.15 | bhinesley | recalculates: more like 95% at worst |
| 02:52.44 | starseeker | bhinesley: cool. the "recommended" pencil's down date for coding is the 15th, with a week to document what has been done - I was thinking, given the complexity of the command(s) your working on, it might not be a bad idea to start a docbook man page for this sucker - brlcad, what do you think? should bhinesley keep chugging on the code? |
| 02:53.12 | starseeker | can see arguments both ways, but I really hate to interrupt your momentum on the code |
| 02:53.30 | starseeker | particularly when it's something like this where having it all "loaded" in your head is important |
| 02:53.37 | bhinesley | ou know, I was actually thinking the same thing earlier today. I would be fine with documenting translate/edit before moving on. |
| 02:53.55 | starseeker | bhinesley: do you have any experience with docbook? |
| 02:53.59 | bhinesley | none |
| 02:54.02 | starseeker | winces |
| 02:54.07 | starseeker | urm |
| 02:54.24 | bhinesley | can't be that bad... |
| 02:54.57 | starseeker | posts that one on the "famous last words" hall of fame... |
| 02:55.11 | starseeker | the toplevel MGED command is "edit", correct? |
| 02:56.04 | bhinesley | yes; but ged_edit recognizes the command name being used, and if it is a subcommand, uses it transparently |
| 02:56.14 | starseeker | O.o hmm |
| 02:56.43 | starseeker | bhinesley: keep coding for now - I need to think about how to organize that doc wise |
| 02:57.27 | bhinesley | I don't know if the edit command itself all that necessary |
| 02:58.10 | bhinesley | we could hide it behind subcommands, or not hide it... I don't see that it makes any difference |
| 02:58.28 | bhinesley | unlikely that anyone is going to use "edit translate" when "translate" is available |
| 02:58.36 | starseeker | would have taken the approach of having a powerful "edit" command, and then have tcl level "wrappers" that translate "rotate" to "edit rotate" |
| 02:58.50 | starseeker | nods |
| 03:00.32 | bhinesley | we could still do that. Right now, there are edit/translate/rotate/scale commands all tied to ged_edit(). We could get rid of translate/rotate/scale, and do it at a TCL level. |
| 03:01.01 | starseeker | would like to have brlcad's opinion on that one |
| 03:02.07 | starseeker | not a big deal, I'm thinking - and I think you're right that the "man page" level is probably rotate/translate/scale - with perhaps a simpler one for edit showing the full syntax and referencing the individual man pages for each "subcommand" for more details |
| 03:02.26 | starseeker | otherwise edit would be a true monster of a man page |
| 03:02.37 | bhinesley | that's basically the format I had for the "mock" manual pages in edit.c |
| 03:02.59 | starseeker | was looking at those - nice work, and I think that will translate fairly cleanly to the docbook system |
| 03:03.47 | starseeker | bhinesley: I guess the thing to do is first make sure translate is solid, and see what brlcad thinks |
| 03:05.37 | bhinesley | alright. For the record, I tend to agree that translate should be documented before moving on. |
| 03:50.10 | CIA-62 | BRL-CAD: 03starseeker * r45962 10/brlcad/trunk/src/other/CMakeLists.txt: Need to flag ITCL_LIBRARY as advanced here too. |
| 04:19.48 | CIA-62 | BRL-CAD: 03starseeker * r45963 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake): (log message trimmed) |
| 04:19.48 | CIA-62 | BRL-CAD: Use a variation on the three way option trick to get more sophisticated about |
| 04:19.48 | CIA-62 | BRL-CAD: turning on/off the optimization flags as a function of CMAKE_BUILD_TYPE - if |
| 04:19.48 | CIA-62 | BRL-CAD: Auto, optimization flags are on for Release and off for Debug, but 'hard' |
| 04:19.48 | CIA-62 | BRL-CAD: setting BRLCAD_FLAGS_OPTIMIZATION to ON or OFF will override the build-type |
| 04:19.48 | CIA-62 | BRL-CAD: based decision. Also, clear the compile flags before we do our thing to |
| 04:19.49 | CIA-62 | BRL-CAD: eliminate any flags CMake automatically adds for a given build type - that's why |
| 04:24.36 | CIA-62 | BRL-CAD: 03starseeker * r45964 10/brlcad/trunk/CMakeLists.txt: |
| 04:24.36 | CIA-62 | BRL-CAD: Go with the most expected/convenient behavior - can't think of a valid case to |
| 04:24.36 | CIA-62 | BRL-CAD: install a rel into a dev dir or vice versa, complete and deceptive violation of |
| 04:24.36 | CIA-62 | BRL-CAD: convention and more convenient/useful to have the install dir swapped as a |
| 04:24.36 | CIA-62 | BRL-CAD: function of build type. |
| 06:14.31 | CIA-62 | BRL-CAD: 03starseeker * r45965 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/CompilerFlags.cmake): Just like the optimization flag, except with the opposite defaults, enable smart autosetting of the debug flags. |
| 06:29.49 | CIA-62 | BRL-CAD: 03starseeker * r45966 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): A pattern emerges, time for a macro. CMAKE_BUILD_TYPE aware options. |
| 06:33.26 | CIA-62 | BRL-CAD: 03starseeker * r45967 10/brlcad/trunk/ (CMakeLists.txt misc/CMake/BRLCAD_Util.cmake): Don't really need the project name and it's limiting flexibility. |
| 06:54.43 | CIA-62 | BRL-CAD: 03starseeker * r45968 10/brlcad/trunk/ (7 files in 7 dirs): |
| 06:54.43 | CIA-62 | BRL-CAD: Key the static lib building on the build type. Exposed a problem with making |
| 06:54.43 | CIA-62 | BRL-CAD: the trigger variable an OPTION in sub-builds - doing so forces the setting into |
| 06:54.43 | CIA-62 | BRL-CAD: the cache and makes it impractical for the AUTO_OPTION macro to do its thing. |
| 06:54.43 | CIA-62 | BRL-CAD: Fortunately, the only files doing that were the ones we wrote - corrected them, |
| 06:54.43 | CIA-62 | BRL-CAD: and we're good to go. |
| 06:57.26 | CIA-62 | BRL-CAD: 03starseeker * r45969 10/brlcad/trunk/CMakeLists.txt: Mark rtgl as advanced. Starting to look fairly clean now, at least on Linux. |
| 07:01.40 | starseeker | brlcad: hopefully that looks better, need to sleep now |
| 17:46.06 | CIA-62 | BRL-CAD: 03starseeker * r45970 10/brlcad/trunk/misc/CMake/BRLCAD_Util.cmake: do some validation on auto_options - probably should at least make these case insensitive, figure out best way to do that later. |
| 17:54.47 | CIA-62 | BRL-CAD: 03starseeker * r45971 10/brlcad/trunk/misc/CMake/ThirdParty_TCL.cmake: Silly me - use tcl to ensure returning just the highest available package number, no need for bizarre regex foo in CMake. |
| 19:16.34 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:35.47 | kunigami | I used boost bcp to select the necessary headers to compile both osl and oiio. it copied a subset of the library into a separated directory. when building though, it does not generate lib's for libraries such as threads. does anyone have experience on doing this? |