| 00:07.02 | Ralith | that's no fun |
| 00:51.27 | CIA-23 | BRL-CAD: 03starseeker * r32013 10/brlcad/branches/STABLE/src/ (456 files in 67 dirs): Update src of STABLE to rel-7-12-4 |
| 00:59.12 | *** join/#brlcad Byron1 (n=byron@pool-96-251-1-116.lsanca.fios.verizon.net) | |
| 00:59.28 | CIA-23 | BRL-CAD: 03starseeker * r32014 10/brlcad/branches/STABLE/ (4 files in 4 dirs): Remove from STABLE misc files that aren't in rel-7-12-4 |
| 00:59.49 | Byron1 | Is there a tutorial on how to use the matrix selection option in mged? |
| 01:01.26 | starseeker | the graphical one or the command line? |
| 01:02.21 | Byron1 | The graphical one I have the command line |
| 01:02.35 | starseeker | 'fraid not |
| 01:02.47 | starseeker | at least, that I've found so far |
| 01:04.49 | Ralith | trail-and-error it, then write one :D |
| 01:05.45 | starseeker | does small happy dance - that should bring STABLE up to 7.12.4 |
| 01:07.15 | starseeker | now to pull in whatever can be easily swiped from trunk and get ready for the actual 7.12.6 testing... |
| 01:25.31 | starseeker | brlcad: How do you want me to handle the snarfing of changes from trunk for 7.12.6? Should I do it all outside svn and then do one big commit, or add them as I go? |
| 01:26.15 | *** join/#brlcad yukonbob (i=1000@s142-179-54-198.bc.hsia.telus.net) | |
| 01:27.26 | CIA-23 | BRL-CAD: 03starseeker * r32015 10/brlcad/branches/STABLE/HACKING: Add r31220 from trunk - brlcad's better release tagging example. |
| 01:44.27 | *** join/#brlcad jonored (n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) | |
| 01:46.40 | brlcad | Byron1: if you read the OED tutorial, it is perfectly applicable to the matrix selection gui |
| 01:47.23 | brlcad | the gui has you pick a right-hand-side then a left-hand-side just like oed requires |
| 01:47.36 | brlcad | from there, the edits are the same |
| 01:50.47 | starseeker | should add a note to the oed tutorial about how to move assemblies/groups that are referenced in multiple locations |
| 01:50.57 | starseeker | that threw me early on |
| 01:52.09 | CIA-23 | BRL-CAD: 03brlcad * r32016 10/brlcad/trunk/src/mged/ (33 files): remove the now empty mged_solid.h header |
| 01:53.08 | brlcad | PrezKennedy: wow, really? put one together yourself or bought something? |
| 01:53.59 | brlcad | starseeker: if they're fully tested, can add them as you go |
| 01:54.24 | brlcad | in general STABLE is supposed to be a branch where it'll always checkout, build, and run and be something we've fully tested |
| 01:54.43 | starseeker | crud |
| 01:54.56 | brlcad | i.e. much higher validity overhead that it not only compiles by default everywhere but also passes all our known tests |
| 01:55.12 | starseeker | had better wait then - this will take long enough without per-commit building |
| 01:55.48 | brlcad | you could create a branch, commit your changes there |
| 01:56.02 | starseeker | That's a thought |
| 01:56.05 | brlcad | then when it's all working, merge that over to stable |
| 01:56.30 | starseeker | had better do that - this will get too hard to keep track of otherwise |
| 01:56.34 | brlcad | that's probably the best route given it's an adhoc set of changes that need to be integrated |
| 01:59.17 | *** join/#brlcad stustev (n=stustev@ip72-205-246-167.ks.ks.cox.net) | |
| 02:00.01 | stustev | hello |
| 02:03.27 | brlcad | hello starseeker |
| 02:03.28 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 02:03.33 | brlcad | oops, hello stustev |
| 02:04.00 | PrezKennedy | brlcad, renting a cheapo one |
| 02:05.49 | CIA-23 | BRL-CAD: 03starseeker * r32017 10/brlcad/branches/pre-7-12-6/: Create working branch in which to prepare 7.12.6. |
| 02:06.55 | starseeker | brlcad: maybe we should tell CIA to ignore this branch? the STABLE update was noisy enough |
| 02:08.16 | brlcad | PrezKennedy: ah |
| 02:08.28 | starseeker | has no wish to spam |
| 02:08.34 | brlcad | nah, it's fine |
| 02:09.04 | brlcad | shows the live activity, tis a good thing :) |
| 02:09.14 | starseeker | :-) |
| 02:09.24 | starseeker | rather like slashdot reruns though... |
| 02:09.37 | brlcad | anyone that doesn't like the irc chatter can add an /ignore |
| 02:09.43 | starseeker | Ah |
| 02:10.06 | stustev | I am new to BRLCAD |
| 02:10.22 | starseeker | should go home soon but is hitting his stride now... |
| 02:10.32 | stustev | I want to know if I can use variables for the arguments |
| 02:10.43 | stustev | I haven't found that in the documentation |
| 02:10.44 | PrezKennedy | brlcad, the only thing in the house that runs Linux is the router |
| 02:11.00 | stustev | is it an undocumented feature? |
| 02:11.54 | Ralith | stustev: arguments in mged commands? |
| 02:11.58 | stustev | brlcad: are you the one that answered my bug report - if you are thanks a lot - I did an svn update and it compiled and runs good |
| 02:12.18 | Ralith | starseeker: imo CIA activity is always fun to see, even if it's a repeat; as brlcad says, it shows active development which is very satisfying. |
| 02:12.18 | stustev | yes - I want to build model with parameters |
| 02:12.57 | Ralith | stustev: iirc, the mged command line interface is actually a modified TCL interpreter; you can write code directly into it, so yes, veriables can be used as arguments. |
| 02:13.00 | CIA-23 | BRL-CAD: 03starseeker * r32018 10/brlcad/branches/pre-7-12-6/ (include/rtserver.h src/librtserver/rtserver.c): Add trunk r31226 by johnranderson for 32-bit vs 64-bit architectures |
| 02:13.19 | Ralith | the mged tutorial has an somewhat fairly early on of using a loop to modify the properties of 8 spheres |
| 02:14.13 | stustev | I will look for the 8 spheres. It will probably be just what I want. Thanks |
| 02:14.27 | starseeker | Ralith: Does that example still work? |
| 02:14.52 | Ralith | starseeker: uh, I don't recall hitting any problems when I did it |
| 02:14.57 | Ralith | starseeker: it's part of the candle tutorials |
| 02:14.58 | Ralith | er |
| 02:15.02 | Ralith | stustev: it's part of the candle tutorials |
| 02:15.35 | stustev | off to the candle tutorial - thanks again - bbl |
| 02:16.01 | CIA-23 | BRL-CAD: 03starseeker * r32019 10/brlcad/branches/pre-7-12-6/ (8 files in 4 dirs): Add trunk revisions 31229-31231 - various fixes |
| 02:17.43 | Ralith | stustev: you can even pass commands to mged from other sources, meaning you can easily script modelling in just about anything |
| 02:18.06 | CIA-23 | BRL-CAD: 03starseeker * r32020 10/brlcad/branches/pre-7-12-6/src/nirt/nirt.c: Add trunk revision 31239 - switch nirt's listforms to bu_vls. |
| 02:18.26 | Ralith | and if you really want to get fancy you can forego mged entirely and work with the libraries it's based on to build models using any language that supports C linkage |
| 02:20.18 | CIA-23 | BRL-CAD: 03brlcad * r32021 10/brlcad/trunk/AUTHORS: time to level up. upgrade cliff yapp's entry from code contributor to developer. has had many months of sustained effort, hundreds of commits and counting. awesomeness. |
| 02:20.47 | brlcad | stustev: probably, I answer a lot of reports .. but welcome(!) regardless |
| 02:21.29 | starseeker | brlcad: thank you! :-) |
| 02:21.43 | brlcad | stustev: there are a lot of ways to model parametrically too, depending on what your actual goal is |
| 02:21.47 | starseeker | is humbled and honored |
| 02:22.03 | brlcad | using tcl in mged, using C, using scripting outside mged, etc |
| 02:23.09 | brlcad | starseeker: you probably passed up chris today :) |
| 02:25.02 | starseeker | brlcad: Oh, while I'm thinking of it - do you want the hyp primitive in 7.12.6 or does it need more work first? |
| 02:25.07 | CIA-23 | BRL-CAD: 03brlcad * r32022 10/brlcad/trunk/AUTHORS: ws |
| 02:25.17 | brlcad | i.e., into the top-ten committers |
| 02:25.22 | brlcad | it needs more work |
| 02:25.31 | starseeker | Ah :-) |
| 02:25.37 | brlcad | there are todo items for it |
| 02:25.49 | starseeker | well, doing a stable branch update is cheating a bit, but cool! :-) |
| 02:26.15 | brlcad | ah, actually good point -- those don't affect your stats :) |
| 02:26.28 | brlcad | so maybe not yet, but pretty close |
| 02:26.44 | starseeker | :-) |
| 02:27.51 | brlcad | mm, there's one more that deserves mention too |
| 02:28.08 | CIA-23 | BRL-CAD: 03starseeker * r32023 10/brlcad/branches/pre-7-12-6/src/mged/ (adc.c chgview.c): Add trunk revisions 31245-31246 - brlcad tweaks for M_SQRT@_DIV2 and using vmath.h for defines. |
| 02:29.48 | CIA-23 | BRL-CAD: 03starseeker * r32024 10/brlcad/branches/pre-7-12-6/ (doc/deprecation.txt include/vmath.h): Add trunk revisions 31246-31248 - more math tweaks, depreciate M_SQRT2_DIV2. |
| 02:30.09 | brlcad | starseeker: next step .. break into that list of "core devs" .. seems to be a big jump to cross the 1000 count mark :) |
| 02:30.40 | starseeker | Hehe :-) |
| 02:30.47 | starseeker | "I have not yet begun to code" |
| 02:31.04 | brlcad | misses mike .. |
| 02:31.18 | brlcad | between him, bob, and I .. *damn* |
| 02:31.45 | brlcad | he'd probably be between 15-20k commits now |
| 02:32.00 | starseeker | can believe it |
| 02:33.31 | stustev | brlcad: my goal is learning brlcad and modeling a replacement part for a machine of mine. I want to maintain an edge margin on a round plate for a bolt hole pattern. I would like to insert the diameter of the plate and the edge margin parametrically and then when I change the plate diameter the hole pattern diameter changes along with it. |
| 02:33.39 | CIA-23 | BRL-CAD: 03starseeker * r32025 10/brlcad/branches/pre-7-12-6/ (4 files in 4 dirs): Add trunk revisions 31262-31264 - Bob's fixes for graphical nirt. |
| 02:35.19 | PrezKennedy | i miss mike too |
| 02:35.52 | CIA-23 | BRL-CAD: 03starseeker * r32026 10/brlcad/branches/pre-7-12-6/src/ (5 files in 3 dirs): Add trunk revisions 31268-31270 - more nirt fixes. |
| 02:36.09 | stustev | I can see the substitution should work. It is all over the command line parameter. I am sure BRLCAD will do it. Does it use a # sign before the variable to tell the interpreter this is a variable? |
| 02:37.25 | brlcad | # are comments |
| 02:39.03 | CIA-23 | BRL-CAD: 03starseeker * r32027 10/brlcad/branches/pre-7-12-6/src/ (libbu/argv.c librtserver/rtserver.c): Add trunk revisions 31272, 31274, 31275 - john's obliquities calculation fix and brlcad's header fixes |
| 02:39.07 | starseeker | wonders just how bad this will blow up on him when he tries to build it... |
| 02:40.46 | CIA-23 | BRL-CAD: 03starseeker * r32028 10/brlcad/branches/pre-7-12-6/misc/win32-msvc8/tclsh/library/installTree.tcl: Add trunk revisions 31277 - Bob's fix for copying nirt sfiles and mods to code that copies g_xxx.c - the latter may be an issue in this branch, TOCHECK |
| 02:42.25 | jonored | stustev: it's $ to tell the interpreter this is a variable. If you're doing math than stuff like [expr {(1+2)/3}] (square brackets substitute return values, expr does math) is probably also helpful. The usual math functions are there in expr, too. |
| 02:43.45 | CIA-23 | BRL-CAD: 03starseeker * r32029 10/brlcad/branches/pre-7-12-6/src/adrt/ (7 files in 3 dirs): Add trunk revisions 31292-31296 - adrt tweaks. |
| 02:44.46 | CIA-23 | BRL-CAD: 03starseeker * r32030 10/brlcad/branches/pre-7-12-6/src/nirt/parse_fmt.c: Add trunk revision 31297 - fix to nirt's dest command. |
| 02:46.02 | CIA-23 | BRL-CAD: 03starseeker * r32031 10/brlcad/branches/pre-7-12-6/src/tclscripts/archer/ArcherCore.tcl: Add trunk revision 31299 - Archer raytrace control panel fix. |
| 02:46.55 | CIA-23 | BRL-CAD: 03starseeker * r32032 10/brlcad/branches/pre-7-12-6/src/nirt/parse_fmt.c: Add trunk revision 31300 - nirt whitespace fix. |
| 02:48.14 | starseeker | 31300, that's a nice round number on which to call it a night |
| 02:48.29 | starseeker | only 700 odd more to consider... |
| 02:49.36 | brlcad | it's also worth noting -- though I'm sure the tutorial series covers it somewhere -- is that the mged tcl interpreter has "globbing" enabled by default so things like "draw [abc]*.r" works which otherwise wouldn't -- have to "set glob_compat_mode 0" if you want a pure tcl interpreter |
| 02:49.54 | brlcad | starseeker: hehe |
| 02:50.05 | brlcad | are you going through every committed revision? |
| 02:50.29 | starseeker | essentially - scanning the svn log looking for things not related to libged, the summer projects, etc |
| 02:50.39 | brlcad | nods |
| 02:50.55 | brlcad | check NEWS to, to see at least from a high-level what you might want to include |
| 02:51.02 | brlcad | s/to,/too,/ |
| 02:51.16 | starseeker | I'll undoubtedly suck in some build config changes unintentially, but that'll have to be fixed at the end once I know the final layouts |
| 02:51.19 | starseeker | nots |
| 02:51.21 | starseeker | er nods |
| 02:51.31 | brlcad | most bug fixes are good to have |
| 02:51.45 | brlcad | anything metaball related of course |
| 02:52.12 | starseeker | expects to have to take a closer look at that, since metaball work may have come after the primitives directory restructuring |
| 02:52.23 | starseeker | did you want to include that, btw? |
| 02:52.36 | brlcad | the restructuring itself doesn't matter |
| 02:52.50 | starseeker | Ah - might be easier to include it, if it doesn't tie in too heavily with libged |
| 02:53.01 | brlcad | it doesn't tie in at all |
| 02:53.08 | starseeker | oh, good :-) |
| 02:53.11 | brlcad | it should be pretty safe |
| 02:53.20 | starseeker | that'll make life much easier |
| 02:53.27 | brlcad | src/libged mostly interacts with src/mged |
| 02:53.35 | starseeker | didn't realize how many nirt fixes hadn't made it into a tarball release yet - ouch |
| 02:53.39 | brlcad | and src/libtclcad to a lesser extent |
| 02:54.01 | brlcad | yeah, sucks not being able to make a release, so this will be really good |
| 02:54.12 | brlcad | hopefully we can post it before siggraph |
| 02:54.36 | starseeker | will of course avoid most of the docbook for this purpose, but will probably stuff the tire doc in there since the latest/greatest tire should be in this release |
| 02:55.02 | starseeker | will try - he is gradually getting the hang of svn and getting the big 7.12.2 -> 7.12.4 jump behind him helped |
| 02:57.26 | starseeker | Oh - can I go ahead and include that tk fix for the newest Xorg releases? |
| 02:57.51 | starseeker | <selfish> can't run without that on his home machine </selfish> |
| 03:00.18 | brlcad | go for it |
| 03:01.31 | stustev | jonored: thanks - I will look for the examples and try them. I very much appreciate the info and help! |
| 03:05.09 | jonored | stustev: It's worth looking up some tutorial stuff on tcl if you can't find all of what you want in the brlcad docs - some of that came from reading up on tcl for me. |
| 03:05.32 | brlcad | stustev: any time, we're always here ;) |
| 03:06.47 | brlcad | new devs and power users (i.e. folks that leverage scripting) get my attention pretty quick, it's what we need more of most :) |
| 03:12.05 | Ralith | who was mike? |
| 03:12.21 | brlcad | Mike Muuss |
| 03:12.34 | Ralith | also, the new release will have metaballs? Neat! I wasn't aware those were even CAD-relevant. |
| 03:12.44 | brlcad | http://en.wikipedia.org/wiki/Mike_Muuss |
| 03:13.36 | Ralith | oh. |
| 03:13.49 | brlcad | a truly brilliant guy to work with, exceptionally charismatic |
| 03:15.08 | Ralith | I can imagine, with a history like that. |
| 03:15.46 | brlcad | the wiki page doesn't really do him justice to say the least, but still informative |
| 03:15.51 | Ralith | opens up his /usr/src/sbin/ping/ping.c |
| 03:15.53 | Ralith | <PROTECTED> |
| 03:15.53 | Ralith | <PROTECTED> |
| 03:15.57 | Ralith | awesome. |
| 03:16.50 | brlcad | brl-cad is sort of like ping a thousand times over |
| 03:17.17 | Ralith | in what respect? |
| 03:18.10 | brlcad | in that the characteristics that have made ping useful and a great tool for so many environments for so long |
| 03:18.22 | Ralith | ah. |
| 03:18.48 | brlcad | ping was the result of a late afternoon of focused intent, brl-cad the same focus over more than a decade |
| 03:19.01 | Ralith | I'd thought that brl-cad's internals seemed amazingly well designed. |
| 03:19.10 | Ralith | seems I was justified :) |
| 03:19.19 | brlcad | yeah, they really are |
| 03:19.30 | brlcad | i mean every code, every api has room for improvement |
| 03:19.38 | Ralith | well, of course |
| 03:19.51 | brlcad | but as far as long-lived codes go, pretty darn nice |
| 03:19.57 | Ralith | but it's rare to find a package that hasn't been ruined by deadlines or ill-thought-out decisions |
| 03:20.29 | Ralith | hell, it's rare to find any code at all that's survived more than five years outside of things like unix system internals |
| 03:21.14 | Ralith | said quality is one of the things that engages me most about brl-cad, really |
| 03:21.21 | CIA-23 | BRL-CAD: 03brlcad * r32033 10/brlcad/trunk/AUTHORS: yet another level up. long overdue credit to dev daniel for his sustained and varied contributions to the project. |
| 03:21.52 | brlcad | Ralith: that reminds me.. |
| 03:22.24 | Ralith | without that I'd have lost interest long ago. |
| 03:23.50 | brlcad | you now have commit access so you can apply your patches yourself |
| 03:24.00 | Ralith | wow |
| 03:24.02 | Ralith | thanks! |
| 03:24.08 | brlcad | I reviewed them and it was a mix of good and not so good for applying the changes to the rt^3 sources |
| 03:24.24 | brlcad | think of it as probationary, don't break anything ;) |
| 03:24.26 | Ralith | hehe |
| 03:24.30 | brlcad | and be sure to read HACKING if you haven't yet |
| 03:24.37 | Ralith | will do. |
| 03:24.42 | pacman87 | Ralith: congrats |
| 03:24.54 | brlcad | the biggest issue with the patches is that they were all bandaids instead of fixes |
| 03:25.10 | brlcad | which is fine for src/other code -- those should always be the utter minimum to maintain portability |
| 03:25.16 | Ralith | to be fair, that was my goal |
| 03:25.42 | Ralith | most of them are likely to be outdated by changes to the build system or upstream improvements |
| 03:25.43 | brlcad | nods |
| 03:25.58 | brlcad | and changes that will likely be lost the next time we sync with upstream |
| 03:27.14 | brlcad | in addition to not breaking anything, be sure to talk to mafm if you're working on that module |
| 03:27.24 | Ralith | of course. |
| 03:28.54 | brlcad | fyi, the Makefile he set up is entirely temporary .. if he or I or whomever can't get CMakeLists.txt to behave easily enough, I'll end up gutting the whole thing for GBS like the main brlcad module |
| 03:29.46 | Ralith | yeah, that's what I was referring to with respect to my patchs' temporary nature |
| 03:30.26 | stustev | wow - are all the tcl capabilities available in brlcad? |
| 03:33.43 | brlcad | yep |
| 03:34.08 | brlcad | most of tk's too |
| 03:55.13 | Ralith | Is it desired behavior that mged does not exit when all GUI elements have been closed, and it's providing no command line interface (as when launched with no options)? |
| 03:57.09 | Ralith | also, both reference links are broken :/ |
| 03:57.14 | Ralith | (in HACKING) |
| 03:58.01 | Ralith | (in rt^3) |
| 04:02.02 | brlcad | that's a bug, it should shut down |
| 04:02.45 | brlcad | it used to shut down if the graphics menu was closed (only) but even that was undesirable since you might still want the command line and vice versa |
| 04:03.08 | brlcad | rt^3's HACKING is a bit out-dated -- sorry for not mentioning that |
| 04:03.27 | brlcad | see the one in the brlcad module |
| 04:03.43 | brlcad | most of the same principles apply, just that it doesn't address some of the c++isms |
| 04:05.33 | Ralith | kk |
| 04:05.44 | Ralith | I noticed the main one seemed very different |
| 04:07.02 | brlcad | rt^3 was originally for a different purpose but with a lot of overlapping intent with a more recent development, so it's become the place to define a separation between the new OO api and new gui from the rest of brl-cad |
| 04:07.34 | brlcad | a way to encourage separation of responsibilities and not pollute the api in particular |
| 04:27.48 | starseeker | reaches home base |
| 04:28.20 | starseeker | Mike lent me his Mastering CMake book, so once I can find time to read it I'll take a more serious look at cmake |
| 04:28.48 | starseeker | REALLY likes the idea of "change config once, build everywhere" |
| 04:29.33 | brlcad | getting cmake to that point without a slew of platform-specific checks is going to be tough (instead of feature-specific) |
| 04:30.10 | starseeker | true, but it at least provides a unified framework for the logic |
| 04:30.17 | brlcad | right now, optional sub-configured cmakes is the bigger issue |
| 04:31.56 | brlcad | hm, even GBS provides a unified framework for the logic |
| 04:32.29 | brlcad | the difference is just that it'll generate various target types instead of just Makefiles |
| 04:33.01 | brlcad | otherwise they're both single cross-platform solutions to the extent that make (and having a shell) is cross-platform |
| 04:34.10 | starseeker | was under the impression that generating Microsoft specific build files was a considerable advantage |
| 04:34.13 | brlcad | most of the work for either is the feature tests -- how do I "know" that this platform needs DM_OGL defined for example so that our opengl framebuffer compiles |
| 04:34.41 | starseeker | ah |
| 04:35.13 | brlcad | gbs's solution was scripted feature, compilation, and runtime tests that you can write (in a m4+shell script language) |
| 04:35.37 | brlcad | how cmake deals with that portably to various environments is much more limited, making those tests a bit harder |
| 04:35.50 | brlcad | s/bit/LOT/ |
| 04:36.25 | starseeker | wait - GBS? |
| 04:36.42 | brlcad | begging projects to just fall back to "if I'm on windows, do this" style checks which are expensive to maintain over a long-term |
| 04:36.45 | brlcad | ~gbs |
| 04:36.46 | ibot | gbs is probably the GNU Build System, aka the Autotools, aka the suite of tools frequently used on UNIX and UNIX-like platforms that utilize the GNU Autoconf, Automake, and Libtool build tools. See http://en.wikipedia.org/wiki/GNU_build_system for more details. |
| 04:36.49 | starseeker | ah |
| 04:37.15 | starseeker | could the issue be raised with the cmake devs? |
| 04:41.47 | starseeker | really should sleep now... |
| 04:47.21 | *** part/#brlcad Byron1 (n=byron@pool-96-251-1-116.lsanca.fios.verizon.net) | |
| 04:50.11 | brlcad | stustev: it's really a fundamental implementation issue -- side effect of supporting various output formats |
| 04:50.30 | brlcad | cmake has support for it -- it's just not *as* flexible as gbs |
| 04:50.37 | brlcad | in the end, it could very well be good enough |
| 04:50.54 | brlcad | most of the feature tests have a specific pattern anyways |
| 04:51.01 | starseeker | one of those "we only find out by putting in an absurd amount of effort" questions? |
| 04:51.35 | starseeker | scowls as his svn checkout and wonders if Comcast is up to their tricks again... |
| 04:52.12 | Ralith | I know comcast does all sorts of nasty things, but messing with svn? |
| 04:52.31 | starseeker | if it's tunneling through ssh, they might treat it like one more ssh connection |
| 04:52.45 | starseeker | and they sure haven't liked my screen remote sessions through ssh in the past |
| 04:52.51 | Ralith | they treat my ssh connections ok, so long as I don't leave them idle for long periods |
| 04:53.10 | Ralith | otherwise they drop them |
| 04:53.28 | starseeker | they do seem to be a bit better lately |
| 04:53.33 | starseeker | ok, sleep |
| 04:53.36 | Ralith | night |
| 04:53.38 | starseeker | later all :-) |
| 04:56.17 | brlcad | starseeker: pretty much |
| 04:56.34 | brlcad | have to put a solid two weeks into it at least |
| 04:57.02 | brlcad | fortunately, rt^3 is tiny so it's not so bad but it should provoke many of the same test types |
| 04:58.03 | brlcad | Ralith: that sucks .. I don't tend to see that unless they're perfectly idle (e.g. on a screen window with no activity, but fine on an irc session) |
| 04:59.27 | Ralith | brlcad: that's what I was referring to; I've never had an active session dropped, only things that I wasn't using/had forgotten about anyway. |
| 05:02.02 | Ralith | it was only annoying insofar as that it tended to invalidate the master sockets that freebsd's ssh generates by default, meaning I'd have to manually delete them before opening a new session. |
| 05:05.49 | brlcad | o.O |
| 05:06.35 | brlcad | i've not seen that be an issue to .bz (brlcad.org) which I'm always on via screen, use for irssi -- that's an old 5.2 box |
| 05:12.41 | Ralith | on completely idle connections? |
| 05:20.47 | brlcad | probably not |
| 05:21.08 | brlcad | but idle enough to get me disconnected if I'm on a quiet screen context |
| 05:43.50 | Ralith | well, I only ever have to deal with comcast when I'm using someone else's wifi anyway. |
| 05:44.27 | Ralith | normally (and currently) I'm on a neat local ISP which accidentally made my consumer-level link symmetric a year or two ago. |
| 05:49.34 | brlcad | nice! |
| 05:50.34 | brlcad | doubts it was accidental though .. probably just cheaper (e.g. some tech in the isp office saying "oh noes, we ran out of adsl ports .. gotta use the sdsl ones now" |
| 05:51.40 | Ralith | hehe |
| 05:51.46 | Ralith | well, I'm not about to call them up and ask what's going on. |
| 05:53.20 | brlcad | iinteresting .. http://www.sdbestpractices.com/ |
| 05:53.35 | brlcad | wonder how technical it actually gets, some interesting tracks |
| 05:53.40 | brlcad | spensive as hell though |
| 05:56.17 | brlcad | wonders if anyone he knows has ever gone |
| 05:58.31 | Ralith | not that great a website for a group that's all about software development. |
| 06:14.12 | brlcad | heh |
| 06:19.07 | Ralith | so what's a use case for metaballs in CAD? |
| 06:19.41 | brlcad | analysis purposes |
| 06:20.17 | brlcad | say you want to represent field strengths surrounding a given object |
| 06:20.39 | brlcad | and determine when two fields are interacting, or when you are within a given field |
| 06:21.22 | brlcad | metaballs serve that purpose very well to implicitly represent envelopes that have variable power associations between points in the field |
| 06:23.09 | brlcad | useful for representing proximity as well -- if you want to roughly know when you are within a meter of a given object for example -- define a metaball structure for the primary boundary points on the given object, automatic solid envelope results |
| 06:24.42 | brlcad | more of a CAE capability, but closely related |
| 06:25.59 | Ralith | ahh. |
| 06:28.18 | Ralith | it makes a lot more sense in that context. |
| 06:28.58 | brlcad | yeah, wouldn't necessarily use it to represent actual geometry |
| 06:29.11 | brlcad | unless you're in the business of making blobby things |
| 06:29.41 | brlcad | could be used to represent certain fluids (inefficiently) |
| 06:30.58 | Ralith | I can't imagine a CAD suite, especially a CSG one, would be the tool of choice for someone in the business of making blobby things. |
| 06:31.23 | Ralith | still, it would be pretty fun to have full support for boolean operations on metaballs |
| 06:32.01 | brlcad | nods |
| 07:09.48 | *** join/#brlcad clock_ (n=clock@84-72-91-240.dclient.hispeed.ch) | |
| 08:19.17 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 08:21.06 | mafm | heya |
| 08:40.38 | *** part/#brlcad vedge (n=vedge@205-237-251-204.ilesdelamadeleine.ca) | |
| 08:45.44 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 09:17.11 | mafm | w00t |
| 09:17.37 | mafm | I'm getting orthographic modes working, and I think that I indirectly fixed another issue :) |
| 09:24.17 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 09:44.30 | CIA-23 | BRL-CAD: 03mafm * r32034 10/rt^3/trunk/src/g3d/ (CameraMode.cxx CameraMode.h): |
| 09:44.30 | CIA-23 | BRL-CAD: Fixing the problems with zooming in orthographic mode with minimum hassle, using |
| 09:44.30 | CIA-23 | BRL-CAD: some of the capabilities of OGRE (instead of previous trials modifying view |
| 09:44.30 | CIA-23 | BRL-CAD: matrices and so on). It works as expected with all current camera/input modes. |
| 10:06.25 | brlcad | awesome! |
| 10:07.30 | mafm | still have problems with panning though :D |
| 10:07.48 | brlcad | heh |
| 10:08.37 | mafm | there are two problems |
| 10:09.07 | mafm | 1) with keyboard, I want to get panning to work the same independent of zoom |
| 10:10.44 | *** join/#brlcad Elperion (n=Bary@p5B14DB05.dip.t-dialin.net) | |
| 10:11.20 | mafm | 2) with mouse, I cannot get the model to follow exactly the mouse |
| 10:23.25 | brlcad | sounds like you have a fair bit of work ahead of you then :) |
| 10:25.28 | brlcad | by panning independent of zoom, do you mean so that one key event corresponds to some amount of absolute translation or translation that is relative to the view (so a object will move N pixels left regardless of zoom/size) |
| 10:25.48 | mafm | the latter |
| 10:25.53 | brlcad | k |
| 10:26.06 | mafm | well, whatever is desired |
| 10:26.12 | clock_ | -/win 12 |
| 10:26.14 | brlcad | that works |
| 10:26.30 | mafm | but at the moment I only get absolute translations |
| 10:29.18 | brlcad | ~botmail for homovulgaris 29 jul - pcConstraint.h:39:20: error: pcHSet.h: No such file or directory |
| 10:37.48 | mafm | one thing... |
| 10:38.12 | mafm | in orthogonal mode, I see the same width in front of me than in the infinitum, right? |
| 10:38.53 | mafm | say, if my camera is a box of 10m, I only see objects at max of that size either if they're in the foreground or in the background, right? |
| 10:39.17 | mafm | (or otherwise they're cropped and I only see a chunk of the whole object) |
| 10:44.29 | brlcad | right |
| 10:45.52 | brlcad | you might have depth-clipping, but things are otherwise parallel such that a 2mx2mx2m box looks the same as a 2mx2mx200m box (presuming you're looking down the z axis) |
| 10:46.08 | brlcad | oh, and if it wasn't mentioned! .. jeez |
| 10:46.16 | brlcad | I sure hope you used right-hand rule |
| 10:46.21 | brlcad | +Z is up |
| 10:46.55 | brlcad | should have made sure I said that earlier, much earlier |
| 10:49.25 | brlcad | if you want to add support for left-handed or other orientations (e.g. +y is up), go for it -- but default for all modes should be +Z is up, right hand rule, and if you're looking down the -X axis with +Z going up, +Y goes to the right .. +x is the "front", +y is the "left", +z is the "top", etc |
| 10:49.57 | brlcad | example diagram is on the mged quick reference |
| 10:50.26 | brlcad | pretty standard for most CAD systems, but not for some graphics systems |
| 10:50.40 | mafm | yahooooo, I got it (for blender mode) |
| 10:51.12 | brlcad | ~mafm++ |
| 10:51.19 | mafm | +Z is up? |
| 10:51.23 | mafm | ~mafm-- :P |
| 10:54.27 | brlcad | +Z is most definitely "up" |
| 10:54.47 | brlcad | we were going to make shirts for that for last year's gsoc party :) |
| 10:56.23 | mafm | I have +X right, +Y up, +Z backwards |
| 10:56.28 | brlcad | some games also chose differently, mostly due to directx pollution |
| 10:56.41 | brlcad | yeah, that's bad |
| 10:57.07 | brlcad | that's view-centric coordinates instead of 3D environment-centric |
| 10:57.56 | brlcad | basing it on an XY plane to match your display (usually for rendering purposes), but when you move to 3D environments, that is the ground-plane and z goes up |
| 10:58.28 | brlcad | that'll definitely need to change |
| 10:59.19 | mafm | uh |
| 10:59.58 | mafm | that'll hurt |
| 11:00.24 | mafm | I was just using OGRE defaults, didn't know that there were different habits for CAD systems |
| 11:01.06 | brlcad | yeah, the alternative is entirely counter-intuitive to CAD |
| 11:01.34 | brlcad | ogre has a setting for which orientation iirc |
| 11:01.50 | brlcad | one of its perks |
| 11:02.06 | mafm | for "which orientation"? |
| 11:02.18 | brlcad | for setting the orientation |
| 11:02.20 | brlcad | right/left hand |
| 11:02.29 | brlcad | z up, y up iirc |
| 11:02.57 | brlcad | otherwise z-up/y-up should be easy to fix, it's one rotation |
| 11:03.21 | *** join/#brlcad elmom (n=elmom@hoasnet-ff04dd00-187.dhcp.inet.fi) | |
| 11:03.53 | brlcad | what you described is a left-handed coordinate system |
| 11:04.13 | brlcad | that's wrong on two-counts ;) |
| 11:04.37 | mafm | really? Z is backwards, pointing towards you |
| 11:04.56 | brlcad | ah, okay |
| 11:04.58 | mafm | I think that it's only a rotation away (along X axes) |
| 11:05.49 | brlcad | I read +z backwards as +z going away from you |
| 11:06.50 | mafm | why is that important? for creating things programatically? |
| 11:07.28 | brlcad | it cascades across various issues |
| 11:08.34 | mafm | saving/loading files too |
| 11:08.45 | brlcad | you're constantly dealing with proper orientation and alignments, tools and commands that rely on knowing which way up is |
| 11:09.54 | brlcad | import/export of data for sure, though many importers will give you an option to realign since there are still a small minority that use a different handedness or a different orientation |
| 11:09.56 | mafm | oh goody |
| 11:13.28 | brlcad | most real-world systems (flight control, simulators, cartography) use the convention of living in the X/Y plane (what should be natural/intuitive) |
| 11:13.44 | brlcad | CAD systems reflect that |
| 11:13.55 | brlcad | (as they should) |
| 11:15.12 | mafm | that's a religious thing I guess, for me it's more natural the OGRE way :D |
| 11:15.53 | mafm | Ogre::RenderSystem::_setViewMatrix || Ogre::RenderSystem::_setWorldMatrix |
| 11:16.11 | mafm | one of these would do, wouldn't it? |
| 11:16.31 | brlcad | it's not just religion -- if I asked you to draw a top-down view of your house on a sheet of paper and asked you to draw a coordinate grid over it -- you'd most likely label them x and y |
| 11:17.24 | brlcad | one of those should do the trick I believe yes |
| 11:17.52 | mafm | hopefully that won't thrash the GUI! |
| 11:19.02 | brlcad | the *only* reason the other convention came to pass was because of display system programmers that started with a 2D context, which was naturally labeled x/y, was extended to 3D where they just went "into" the display |
| 11:19.07 | mafm | the X/Y it depends on the situation, if you're used to draw coordinates of a projectile (classical high school physics problems) you'd do Y up :) |
| 11:19.28 | brlcad | it's focusing on what is doing the looking instead of what you're looking at, the world being represented and how that correlates with the one we live in |
| 11:19.50 | mafm | I guess that I'm biased because of the displays too :D |
| 11:19.52 | brlcad | you do X/Y when you only have two to work with no matter what view |
| 11:22.43 | CIA-23 | BRL-CAD: 03mafm * r32035 10/rt^3/trunk/src/g3d/ (4 files): Fixing the problems with panning when controlled by keyboard (currently for Blender Camera mode only). |
| 11:23.56 | brlcad | like I said, it's mostly whether you emphasize the viewer (viewing system) or the environment being viewed .. I even learned +Y is up for graphics and thought similarly until I had to model stuff that mattered and became familiar with both |
| 11:24.34 | mafm | scared |
| 11:25.11 | mafm | ok ok +Z is up, but don't make me learn it by modeling with MGED! :P |
| 11:25.12 | mafm | ;) |
| 11:25.53 | mafm | have to go to lunch, hopefully I'll get inspiration for fixing the panning with mouse for MGED mode |
| 11:25.55 | mafm | bbiab |
| 11:26.06 | brlcad | heh, cya |
| 11:49.31 | CIA-23 | BRL-CAD: 03bob1961 * r32036 10/brlcad/trunk/src/ (archer/archer.bat mged/mged.bat util/rtwizard.bat): Update version to 7.13.0 |
| 11:53.44 | CIA-23 | BRL-CAD: 03homovulgaris * r32037 10/brlcad/trunk/src/libpc/pcConstraint.h: unbreaking the build. accidental premature code insertion |
| 11:55.34 | mafm | "accidental premature code insertion"... so that's how they call it now |
| 12:02.31 | CIA-23 | BRL-CAD: 03bob1961 * r32038 10/brlcad/trunk/src/mged/ (dir.c setup.c): |
| 12:02.31 | CIA-23 | BRL-CAD: Added the killrefs command that kills/removes all references of the specified |
| 12:02.31 | CIA-23 | BRL-CAD: objects by combinations. The objects themselves are not killed. Also added the |
| 12:02.31 | CIA-23 | BRL-CAD: -a option to killtree that arranges for "all" references to also be removed. |
| 12:08.17 | CIA-23 | BRL-CAD: 03bob1961 * r32039 10/brlcad/trunk/ (63 files in 8 dirs): Fleshing out a few libged commands that were previously stubbed in. |
| 12:15.02 | CIA-23 | BRL-CAD: 03starseeker * r32040 10/brlcad/branches/pre-7-12-6/ (6 files in 4 dirs): Add revisions 31301-31305 to pre-7-12-6; misc. fixes to Tcl, nirt, config.ac |
| 12:25.55 | CIA-23 | BRL-CAD: 03bob1961 * r32041 10/brlcad/trunk/src/libged/ (Makefile.am wdb_track.c): Temporarily adding wdb_track. |
| 12:30.46 | CIA-23 | BRL-CAD: 03bob1961 * r32042 10/brlcad/trunk/src/libged/ (Makefile.am killrefs.c): Adding killrefs. |
| 12:43.25 | mafm | yay! got it |
| 12:43.45 | CIA-23 | BRL-CAD: 03bob1961 * r32043 10/brlcad/trunk/src/libged/open.c: Cut-n-paste fix. |
| 12:44.51 | CIA-23 | BRL-CAD: 03bob1961 * r32044 10/brlcad/trunk/ (include/ged.h src/libtclcad/ged_obj.c): Removed ged_rt_gettrees. |
| 12:45.39 | CIA-23 | BRL-CAD: 03mafm * r32045 10/rt^3/trunk/src/g3d/ (CameraManager.cxx CameraModeMGED.cxx): |
| 12:45.39 | CIA-23 | BRL-CAD: Fixing the problems with panning when controlled by mouse (currently for |
| 12:45.39 | CIA-23 | BRL-CAD: MGED/Shift-grips Camera mode only). In the end it was very simple, but only |
| 12:45.39 | CIA-23 | BRL-CAD: once we got the relative dimensions of the camera and we're working in |
| 12:45.39 | CIA-23 | BRL-CAD: orthogonal projection mode. |
| 12:51.51 | CIA-23 | BRL-CAD: 03starseeker * r32046 10/brlcad/branches/pre-7-12-6/ (362 files in 41 dirs): Start merging the primitives reorg into pre-7-12-6 |
| 12:52.44 | mafm | brlcad: the constrained modes work according to the initial coordinates, not with the screen coordinates... are there any document explaining this? |
| 12:55.04 | mafm | any other person knowing the information is welcome to reply, of course |
| 13:00.53 | mafm | when using unconstrained mode, it works in "screen mode", you move the object according to the camera plane |
| 13:01.15 | mafm | or rather, move the camera up/down/left/right |
| 13:01.55 | *** join/#brlcad thing0 (n=ric@58.171.212.200) | |
| 13:02.40 | mafm | but when using constrained mode, this works constraining to "X" axis in world coordinates or something like that, so you hardly can control where to move the view to |
| 13:03.24 | mafm | at least I'd expect that constrained modes would constrain it to only up/down or left/right in "camera space" |
| 13:06.30 | CIA-23 | BRL-CAD: 03starseeker * r32047 10/brlcad/branches/pre-7-12-6/src/librt/primitives/ (68 files in 33 dirs): more primitive directory restructuring |
| 13:14.47 | CIA-23 | BRL-CAD: 03starseeker * r32048 10/brlcad/branches/pre-7-12-6/ (59 files in 49 dirs): Merge trunk r 31311-31319 - tweaks, adrt updates |
| 13:30.06 | CIA-23 | BRL-CAD: 03erikgreenwald * r32049 10/brlcad/trunk/src/libged/dup.c: make prototype match declaration for ged_dir_check (missing static) |
| 13:30.53 | CIA-23 | BRL-CAD: 03mafm * r32050 10/rt^3/trunk/src/g3d/ (4 files): Saving the state of camera rotations before dragging, so they continue to rotate from the current position instead of starting from scratch (for both Blender and MGED modes). |
| 13:30.54 | mafm | what happens today with brl-cad, developers on asteroids? :) |
| 13:31.12 | mafm | amazing, being that it's the peak of the summer :) |
| 14:03.01 | PrezKennedy | programmers are allergic to the sun ;) |
| 14:03.31 | d_rossberg | brlcad: did you get my e-mail from friday? |
| 14:56.41 | CIA-23 | BRL-CAD: 03mafm * r32051 10/rt^3/trunk/src/g3d/ (4 files): Cleanup of #includes |
| 14:57.52 | CIA-23 | BRL-CAD: 03mafm * r32052 10/rt^3/trunk/src/g3d/GuiWindowManager.h: Renaming to remove inconsistencies |
| 14:59.16 | CIA-23 | BRL-CAD: 03mafm * r32053 10/rt^3/trunk/src/g3d/ (CameraManager.cxx CameraManager.h GuiWindowManager.cxx): Adding event for when we update the camera every frame |
| 15:05.09 | CIA-23 | BRL-CAD: 03bob1961 * r32054 10/brlcad/trunk/ (4 files in 3 dirs): Temporarily adding wdb_importFg4Section. |
| 15:06.14 | CIA-23 | BRL-CAD: 03bob1961 * r32055 10/brlcad/trunk/src/libged/ged_private.h: Declare ged_open_dbip(). |
| 15:20.59 | CIA-23 | BRL-CAD: 03bob1961 * r32056 10/brlcad/trunk/src/libged/ged.c: The declaration of ged_open_dbip has moved to ged_private.h |
| 15:21.45 | CIA-23 | BRL-CAD: 03erikgreenwald * r32057 10/brlcad/trunk/src/libged/Makefile.am: sort source files |
| 15:25.37 | CIA-23 | BRL-CAD: 03bob1961 * r32058 10/brlcad/trunk/src/ (libged/importFg4Section.c libtclcad/ged_obj.c): Added the importFg4Section command to libged. |
| 15:31.29 | poolio | ooo, when's the new release supposed to be out? |
| 15:41.30 | CIA-23 | BRL-CAD: 03johnranderson * r32059 10/brlcad/trunk/src/librtserver/rtserver.c: do not call rt_resource_clean_complete() for rt_uniresource |
| 15:42.30 | CIA-23 | BRL-CAD: 03johnranderson * r32060 10/brlcad/trunk/src/librtserver/rtserverTest.c: Mods to work with changes in rtserver |
| 16:11.56 | CIA-23 | BRL-CAD: 03johnranderson * r32061 10/brlcad/trunk/src/librt/prep.c: rt_clean_resource_basic() now sets the conditions that are checked by rt_init_resource(), allowing resource structures to be cleaned and initialized again. |
| 16:14.51 | CIA-23 | BRL-CAD: 03johnranderson * r32062 10/brlcad/trunk/src/librtserver/rtserver.c: Now that the init-clean-init cycle is possible, restore the call to rt_clean_resource_complete() for rt_uniresource. Librtserver is once again free of memory leaks. |
| 16:24.51 | starseeker | poolio: It'll be a bit yet - I'm still collecting updates while trying to avoid accidently pulling libged changes |
| 16:27.20 | starseeker | then there's all the testing, plus this being my first time putting a release together :-) |
| 16:35.57 | CIA-23 | BRL-CAD: 03starseeker * r32063 10/brlcad/branches/pre-7-12-6/ (5 files in 2 dirs): Add r31321-31326 from trunk - TODO updates and nirt features. |
| 16:37.08 | poolio | starseeker: good luck :) |
| 16:38.30 | CIA-23 | BRL-CAD: 03starseeker * r32064 10/brlcad/branches/pre-7-12-6/ (COPYING configure.ac): Add r31329-31331 from trunk - typo fixes, don't mix sysystem tcl with non-system itcl. |
| 16:42.07 | CIA-23 | BRL-CAD: 03starseeker * r32065 10/brlcad/branches/pre-7-12-6/ (3 files in 2 dirs): Add r31333 from trunk - add asc2g and g2asc to cmake lists. |
| 16:43.38 | CIA-23 | BRL-CAD: 03starseeker * r32066 10/brlcad/branches/pre-7-12-6/include/bu.h: Add r31337-31338 from trunk - new bu_list example. |
| 16:48.55 | CIA-23 | BRL-CAD: 03starseeker * r32067 10/brlcad/branches/pre-7-12-6/ (BUGS NEWS src/proc-db/tire.c): Add r31348,31349,31354,31358 - tire fixes. |
| 16:51.10 | CIA-23 | BRL-CAD: 03starseeker * r32068 10/brlcad/branches/pre-7-12-6/src/adrt/libtie/tie_kdtree.c: Add r31366-74 - adrt tweaks. |
| 16:55.46 | CIA-23 | BRL-CAD: 03starseeker * r32069 10/brlcad/branches/pre-7-12-6/src/rt/viewarea.c: Add r31406 - viewarea fix. |
| 17:16.26 | CIA-23 | BRL-CAD: 03mafm * r32070 10/rt^3/trunk/src/g3d/GuiBaseWindow.cxx: Cleanup of #includes |
| 17:20.50 | CIA-23 | BRL-CAD: 03starseeker * r32071 10/brlcad/branches/pre-7-12-6/doc/docbook/oed/oed.xml: Add r31430 - Add oed tweaks suggested by Paul Tanenbaum, add acknowledgements. |
| 17:34.18 | CIA-23 | BRL-CAD: 03starseeker * r32072 10/brlcad/branches/pre-7-12-6/doc/docbook/oed/oed.xml: Fix to lollipop model suggested by Paul Tanenbaum (r31458) |
| 17:36.34 | CIA-23 | BRL-CAD: 03starseeker * r32073 10/brlcad/branches/pre-7-12-6/ (5 files in 3 dirs): Upload r31456 and 31457 - rtserver simplification and loop -c feature |
| 17:37.45 | CIA-23 | BRL-CAD: 03starseeker * r32074 10/brlcad/branches/pre-7-12-6/HACKING: Update how to make ChangeLog |
| 17:42.03 | CIA-23 | BRL-CAD: 03starseeker * r32075 10/brlcad/branches/pre-7-12-6/ (TODO include/bu.h src/libbu/argv.c src/mged/rtif.c): Upload r31480,81, and 87 - libbu updates and TODO update |
| 17:42.51 | brlcad | aaah, the mged quick ref is finally getting out of date .. hrmph |
| 17:43.03 | brlcad | beams at all the activity |
| 17:45.02 | CIA-23 | BRL-CAD: 03starseeker * r32076 10/brlcad/branches/pre-7-12-6/ (NEWS doc/Makefile.am doc/mged.sh doc/mged.tr): News updates, rename mged.tr to mged.sh |
| 17:48.12 | CIA-23 | BRL-CAD: 03starseeker * r32077 10/brlcad/branches/pre-7-12-6/ (9 files in 3 dirs): Naming convention build target updates. |
| 17:51.30 | CIA-23 | BRL-CAD: 03starseeker * r32078 10/brlcad/branches/pre-7-12-6/ (TODO misc/nsis/brlcad.nsi): Upload r31523 NSIS updates for version aware Windows installation |
| 17:53.55 | CIA-23 | BRL-CAD: 03starseeker * r32079 10/brlcad/branches/pre-7-12-6/misc/archlinux/PKGBUILD: archlinux PKGBUILD update - don't strip debugging, keep docs |
| 17:54.45 | CIA-23 | BRL-CAD: 03brlcad * r32080 10/brlcad/trunk/NEWS: |
| 17:54.45 | CIA-23 | BRL-CAD: per modeler request, bob added a new killrefs command that removes all |
| 17:54.45 | CIA-23 | BRL-CAD: references to a given object (without killing the object itself) as well as a |
| 17:54.45 | CIA-23 | BRL-CAD: new -a option to killtree so it removes all references in addition to killing |
| 17:54.45 | CIA-23 | BRL-CAD: the object and it's hierarchy. these be very very dangerous commands. |
| 18:01.14 | starseeker | next step, kill tree except for objects referenced in another tree ;-) |
| 18:04.31 | CIA-23 | BRL-CAD: 03starseeker * r32081 10/brlcad/branches/pre-7-12-6/ (6 files in 5 dirs): Commit r31542, 31544-51549 - new mged regression test, tire cleanup by Sean, column width change in helplib.tcl, other tweaks |
| 18:06.28 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 18:16.14 | CIA-23 | BRL-CAD: 03starseeker * r32082 10/brlcad/branches/pre-7-12-6/ (35 files in 7 dirs): Uploaded r31575 - 31585 - cleanup by Sean |
| 18:17.44 | CIA-23 | BRL-CAD: 03starseeker * r32083 10/brlcad/branches/pre-7-12-6/sh/ (news2tracker.sh tracker.sh): Update news2tracker.sh and tracker.sh, r31611-12 |
| 18:18.02 | CIA-23 | BRL-CAD: 03bob1961 * r32084 10/brlcad/trunk/misc/win32-msvc8/asc2g/asc2g.vcproj: Update version to 7.13.0 |
| 18:28.55 | CIA-23 | BRL-CAD: 03starseeker * r32085 10/brlcad/branches/pre-7-12-6/ (5 files in 3 dirs): Uploaded r31669 - 31675 - cleanup by Sean, fast4-g checks, note pipe primitive issue |
| 18:34.35 | CIA-23 | BRL-CAD: 03starseeker * r32086 10/brlcad/branches/pre-7-12-6/ (5 files in 5 dirs): Upload trunk r31695:31699 Updates and fixes to sketch and extrude |
| 18:36.13 | CIA-23 | BRL-CAD: 03starseeker * r32087 10/brlcad/branches/pre-7-12-6/ (include/raytrace.h src/librt/primitives/sketch/sketch.c): Upload trunk r31701 - more sketch updates |
| 18:38.44 | mafm | I go now, take care folks |
| 18:39.35 | CIA-23 | BRL-CAD: 03starseeker * r32088 10/brlcad/branches/pre-7-12-6/src/conv/g2asc.c: Upload trunk r31703 - g2asc tweak |
| 18:41.52 | CIA-23 | BRL-CAD: 03starseeker * r32089 10/brlcad/branches/pre-7-12-6/ (include/bu.h src/conv/CMakeLists.txt): r31721 comment, BU_BITV_ZEROALL requires #include <string.h> |
| 18:44.31 | CIA-23 | BRL-CAD: 03starseeker * r32090 10/brlcad/branches/pre-7-12-6/src/librt/primitives/sketch/sketch.c: r31729 - sketch sanity checks |
| 18:46.01 | CIA-23 | BRL-CAD: 03starseeker * r32091 10/brlcad/branches/pre-7-12-6/src/proc-db/tire.c: r31736 - remove tire debugging printout |
| 18:51.38 | CIA-23 | BRL-CAD: 03starseeker * r32092 10/brlcad/branches/pre-7-12-6/ (BUGS src/librt/primitives/pipe/pipe.c): r31743-44 - fix pipe performance issue by eliminating BU_GETSTRUCT for hits, note about failure of toy jeep to triangulate |
| 18:55.28 | CIA-23 | BRL-CAD: 03starseeker * r32093 10/brlcad/branches/pre-7-12-6/src/libged/wdb_obj.c: r31772,31775 - fix for infinite loop when dbconcat was called with NO_AFFIX |
| 19:35.56 | *** join/#brlcad andrecastelo___ (n=chatzill@189.71.12.203) | |
| 20:02.15 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 20:07.39 | poolio | brlcad: Do you know if there is a way, given a 3d curve, to get the 2d trimming curve when projecting that 3d curve onto the surface? I'm thinking of just manually evaluating the control points, but was wondering if you knew of any opennurbs functionality like that? |
| 20:16.20 | brlcad | poolio: src/librt/opennurbs_ext.cpp |
| 20:16.35 | brlcad | pullback_curve() in particular |
| 20:17.16 | brlcad | very much green code |
| 20:17.21 | brlcad | but does exactly that |
| 20:17.45 | poolio | brlcad: ah, thanks |
| 20:17.59 | Ralith | >.< |
| 20:18.08 | Ralith | so my g++ has decided not to support exceptions for some reason. |
| 20:18.28 | brlcad | Ralith: odd |
| 20:18.53 | brlcad | gcc needs -fexceptions, but it should be enabled by default for g++ |
| 20:19.10 | Ralith | passing -fexceptions manually changes nothing |
| 20:19.25 | brlcad | then sounds like you might have some other problem.. |
| 20:20.27 | Ralith | serious one, too |
| 20:20.43 | Ralith | I can't properly test any of my changes until ogre works, and ogre depends on exceptions being catchable |
| 20:20.45 | poolio | brlcad: hmm, so that routine looks very imprecise. If I find the (u,v) for each of the 3d control points, will that work? |
| 20:21.05 | brlcad | poolio: imprecise how? |
| 20:21.23 | brlcad | make it more precise ;) |
| 20:21.33 | poolio | well, it's sampling and interpolating between points |
| 20:21.44 | poolio | By definition, isn't that inaccurate? |
| 20:22.22 | brlcad | of course it is, but what alternative approach did you have in mind? |
| 20:22.50 | brlcad | for two joined surfaces, there's definitely something better that can be done |
| 20:22.59 | brlcad | but for a single curve, single surface.. |
| 20:23.13 | poolio | Well, I have all the control points for the 3d curve, I just want to have a 2d curve that traces that 3d curve on a planar surface (note that the 3d curve is on the 3d plane) |
| 20:25.39 | brlcad | and.. how do you go about tracing that curve |
| 20:26.16 | poolio | So my real question is whether a curve defined by the same knots, but control points in a different dimension will match the 3d curve when the 2d control points are the (u,v) on the surface that corresponde to the (x,y,z) of the control points of the 3d curve |
| 20:26.33 | *** join/#brlcad clock_ (n=clock@77-56-83-99.dclient.hispeed.ch) | |
| 20:30.00 | brlcad | hm |
| 20:32.32 | brlcad | if the surfaces have the same order and are planar, probably (at least that's the intuitive assumption) |
| 20:33.02 | brlcad | not sure about curved surfaces though |
| 20:33.18 | brlcad | actually don't think so for curved |
| 20:33.34 | poolio | wait, surfaces plural? I'm just doing one 3d curve on one surface |
| 20:33.52 | brlcad | just one surface |
| 20:34.12 | poolio | yeah, for planar I thought it would work. Maybe I'll just try it and see :) |
| 20:34.24 | Ralith | ahah! fixed my gcc. |
| 20:34.36 | brlcad | Ralith: congrat |
| 20:36.13 | Ralith | aaand g3d loads! :D |
| 20:36.20 | brlcad | woot |
| 20:40.36 | CIA-23 | BRL-CAD: 03starseeker * r32094 10/brlcad/branches/pre-7-12-6/ (BUGS TODO): r31791 - note primitive selection bug in mged |
| 20:41.30 | brlcad | starseeker: be sure to revert the cpa changes to src/rt/rtarea.c for release |
| 20:41.31 | Ralith | aaand latest svn doesn't build :/ |
| 20:42.22 | starseeker | brlcad: So we no longer want those to go in before the next release per the TODO? |
| 20:42.28 | Ralith | fixd. |
| 20:43.25 | brlcad | starseeker: yeah, the center of presented area changes (from andre) modify the output format and hasn't been fully tested yet |
| 20:43.44 | starseeker | Ah, ok |
| 20:43.46 | brlcad | it needs to be a separate section in the file and coordianted with the s2 folks |
| 20:43.47 | starseeker | sorry |
| 20:43.51 | brlcad | since they rely on it |
| 20:43.54 | brlcad | you didn't know |
| 20:44.37 | starseeker | has probably bitten off way more than he can chew, but oh well - after all the chatter in IRC I have to make it work now :-) |
| 20:44.39 | brlcad | so since that's not done yet, just easier to revert it for now until it can be fixed |
| 20:45.00 | brlcad | Ralith: I see no commits to fix anything.. :) |
| 20:45.25 | Ralith | brlcad: that's because I'm polishing and killing unnecessary stuff still. |
| 20:45.52 | Ralith | e.g. OIS seems to work fine without the mouse tweaks |
| 20:46.00 | brlcad | ah, k |
| 20:47.01 | starseeker | me blinks - trunk doesn't have rtarea.c |
| 20:47.07 | starseeker | at least not in src/rt |
| 20:47.22 | starseeker | confound it, I missed that somehow |
| 20:48.20 | brlcad | no you didn't |
| 20:48.27 | brlcad | i said the wrong file |
| 20:48.34 | brlcad | all the rt's are view*.c |
| 20:48.38 | starseeker | ah |
| 20:48.39 | brlcad | viewarea.c |
| 20:49.03 | brlcad | they use the same front-end and back-end, just using different view files for behavior |
| 20:49.41 | poolio | brlcad: well it looks like there is no way in opennurbs to go from (x,y,z) -> (u,v) for a given surface :\ |
| 20:51.29 | brlcad | poolio: nope |
| 20:51.35 | brlcad | they don't have any evaluation routines |
| 20:51.47 | brlcad | seriously, that's what pullback does |
| 20:52.04 | brlcad | you could modify the algorithm to detect pullback onto a planar surface |
| 20:52.33 | brlcad | but that's the action of (x,y,z) -> (u,v) .. you pull back a 3D point into 2D uv space |
| 20:52.34 | CIA-23 | BRL-CAD: 03starseeker * r32095 10/brlcad/branches/pre-7-12-6/ (10 files in 2 dirs): revert r31046 from trunk, per advice from Sean - needs more testing |
| 20:53.16 | brlcad | there are other evaluation routines in opennurbs_ext.cpp .. built up from functionality (intentionally) missing from openNURBS |
| 20:53.57 | brlcad | they removed all evaluation routines specifically because they don't want the library to be used exactly the way we're using it -- at least they're not going to help |
| 20:54.26 | brlcad | they sell a product (Rhino SDK) that implements all the needed algorithms (via some of the best approaches) |
| 20:54.33 | poolio | Hmm, alright. It just seems like it shouldn't be this difficult...I have a 3d edge and I just want a face with the area it encloses |
| 20:58.49 | starseeker | poolio: <grin> There's the moon right there doggone it - I just want to go stand on it ;-) |
| 20:59.19 | poolio | starseeker: ... silly rabbit |
| 21:00.13 | poolio | brlcad: Do you know how the old nurbs code did it? The way they define the surfaces for the top and bottom of the tgc is by defining the rectangular surface and then defining a 3d curve. That's it |
| 21:00.22 | CIA-23 | BRL-CAD: 03ralith * r32096 10/rt^3/trunk/src/other/Makefile: Improvements to portability and removal of explicit build from install targets |
| 21:00.32 | Ralith | :] |
| 21:00.50 | poolio | oh hey, Ralith's first commit? |
| 21:00.54 | Ralith | yep |
| 21:00.57 | poolio | ~Ralith++ |
| 21:01.02 | Ralith | :D |
| 21:02.47 | brlcad | starseeker: oh, and I need to revert an mged command too -- remind me when it's starts stabilizing |
| 21:02.56 | brlcad | ~ralith++ |
| 21:03.24 | starseeker | brlcad: Will do |
| 21:03.39 | brlcad | poolio: ah, and you need the 2D uv to define that surface |
| 21:03.52 | starseeker | is taking the naive approach of grabbing everything that looks like it might be appropriate, and then figuring out what broke |
| 21:04.02 | brlcad | poolio: that means there is a nurb_* pullback routine somewhere too |
| 21:04.23 | poolio | ah k. I'll mess around with pullback then |
| 21:04.29 | brlcad | though that's odd -- paul stay didn't finish trims |
| 21:04.40 | brlcad | odd that he'd use a trimmed surface |
| 21:05.22 | brlcad | poolio: and there should be a third implementation of pullback in boole too ;) |
| 21:06.20 | CIA-23 | BRL-CAD: 03starseeker * r32097 10/brlcad/branches/pre-7-12-6/src/librt/primitives/dsp/dsp.c: Commit r31810 and r31811 (31810 got sucked into the previous commit) - regression test typo fix and ignore dsps with no data more gracefully. |
| 21:08.35 | CIA-23 | BRL-CAD: 03starseeker * r32098 10/brlcad/branches/pre-7-12-6/src/librt/primitives/dsp/dsp.c: r31813 - clean up dsp warning messages |
| 21:10.32 | pacman87 | woohoo |
| 21:10.45 | pacman87 | finally got the union working |
| 21:10.55 | pacman87 | still needs more thorough testing |
| 21:11.08 | Ralith | hm. Anyone know the freenode channel for autotools? |
| 21:14.54 | CIA-23 | BRL-CAD: 03starseeker * r32099 10/brlcad/branches/pre-7-12-6/ (5 files in 4 dirs): r31816, r31819-22 - cleanup, RFC822 format support |
| 21:15.30 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 21:16.21 | CIA-23 | BRL-CAD: 03starseeker * r32100 10/brlcad/branches/pre-7-12-6/src/other/tk/generic/tk.h: r31823 - fix to Tk for newer Xorg installations. |
| 21:18.11 | CIA-23 | BRL-CAD: 03starseeker * r32101 10/brlcad/branches/pre-7-12-6/ (Makefile.am include/conf/Makefile.am): r31831 - reset compilation time every time make is invoked |
| 21:19.48 | CIA-23 | BRL-CAD: 03starseeker * r32102 10/brlcad/branches/pre-7-12-6/src/librt/primitives/dsp/dsp.c: r31834 - fix bug in dsp caught by solids regression test |
| 21:19.50 | brlcad | Ralith: #gnu iirc |
| 21:20.00 | brlcad | did you have a specific question, though? |
| 21:20.05 | brlcad | pretty strong expertise in here |
| 21:21.27 | Ralith | oh, I suppose there would be |
| 21:22.02 | CIA-23 | BRL-CAD: 03starseeker * r32103 10/brlcad/branches/pre-7-12-6/src/libbu/parse.c: r31835 - use strcad instead of strcpy |
| 21:22.42 | Ralith | I could make my OIS fix a lot more elegant if I knew how to set a boolean, and include/exclude certain files from the build as well as define/leave undefined a preprocessor macro |
| 21:22.54 | Ralith | according to the state of that boolean |
| 21:24.48 | CIA-23 | BRL-CAD: 03starseeker * r32104 10/brlcad/branches/pre-7-12-6/src/libbu/parse.c: r31837 - reactivate %S format in bu_structparse_argv |
| 21:24.50 | Ralith | that way I could define something along the lines of USE_JOYSTICK to false on all non-windows/linux platforms, exclude certain files from the build entirely (removing the messy entire file #ifdef hack my patch used) and use a feature-specific rather than platform-specific #define in config.h for the files that need to be only partially modified |
| 21:26.16 | Ralith | I could hack up something to provide the preprocessor macro via cflags from a ./configure check for the linux joystick headers, but that's still pretty inelegant |
| 21:26.27 | Ralith | and would probably break windows joysticks |
| 21:29.51 | Ralith | I think all I need to do is make conditional the contents of libOIS_la_SOURCES from src/Makefile.am and the value of a new config.h #define |
| 21:30.37 | Ralith | preferably through the same mechanism, such that no situation could produce a case in which the files were added but the macro was defined false |
| 21:30.42 | Ralith | or vis versa |
| 21:30.42 | CIA-23 | BRL-CAD: 03starseeker * r32105 10/brlcad/branches/pre-7-12-6/ (8 files in 5 dirs): push USE_PROTOTYPES up into common.h, push USE_FBSERV into dm.h |
| 21:31.52 | brlcad | catchs up and reads |
| 21:37.20 | *** join/#brlcad Elperion (n=Bary@p5B14DB05.dip.t-dialin.net) | |
| 21:42.29 | brlcad | Ralith: is it OIS that's using GBS? |
| 21:42.55 | brlcad | the src/other/Makefile is temporary until someone(tm) can hook up proper build system integration |
| 21:43.10 | brlcad | that gets at the cmake comments I made yesterday |
| 21:52.03 | Ralith | it's OIS, yes |
| 21:52.41 | Ralith | I didn't worry about elegance when fixing up the generic makefile for exactly that reason |
| 22:02.00 | brlcad | nods |
| 22:02.12 | brlcad | yeah, I wouldn't worry about the clean fix for their build system |
| 22:02.47 | brlcad | absolute minimum effort to make them work (which sometimes is "replace their build system") |
| 22:05.43 | brlcad | in that specific case, what will be interesting is how cmake can be configured to optionally compile a sub-project that is gbs-based |
| 22:06.44 | brlcad | ois is pretty small at least, so worse case is write a cmake build for them (presuming we stick with cmake instead of gbs ourselves) |
| 22:13.56 | Ralith | kk |
| 22:14.00 | Ralith | dirty hack it is |
| 22:15.56 | *** join/#brlcad jonored (n=jonored@pool-72-74-102-223.bstnma.east.verizon.net) | |
| 22:20.06 | CIA-23 | BRL-CAD: 03ralith * r32106 10/rt^3/trunk/src/other/ois/src/linux/ (4 files): Dirty hacks to make OIS build on FreeBSD until upstream ports joystick support properly |
| 22:30.15 | Ralith | Anybody familiar with cmake? |
| 22:32.32 | CIA-23 | BRL-CAD: 03ralith * r32107 10/rt^3/trunk/src/other/mocha/ (6 files in 3 dirs): FreeBSD support for Mocha |
| 22:41.30 | *** join/#brlcad andrecastelo (n=chatzill@189.71.12.203) | |
| 22:46.31 | *** join/#brlcad jonored_ (n=jonored@pool-72-74-102-223.bstnma.east.verizon.net) | |
| 22:48.14 | stustev | good evening gentlemen - I have a good handle on the variables - I am able to write a script using variables and create geometry. I have a question about patterns this evening. The example in the documentation stops as if some pages are left out. I am talking about the cylindrical pattern example. The other patterns are not very clear about the implementation but the cylinder pattern seems to stop short. Can anyone point me to a completed |
| 22:53.57 | *** part/#brlcad stustev (n=stustev@ip72-205-246-167.ks.ks.cox.net) | |
| 22:56.42 | *** join/#brlcad jonored__ (n=jonored@pool-72-74-102-223.bstnma.east.verizon.net) | |
| 23:08.06 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 23:08.54 | *** join/#brlcad jonored (n=jonored@pool-72-74-102-223.bstnma.east.verizon.net) | |
| 23:42.25 | starseeker | stustev: I would suggest looking at clone for patterning geometry |
| 23:42.32 | brlcad | he left |
| 23:42.40 | starseeker | ah |
| 23:42.55 | starseeker | notes scrollback after the fact |
| 23:43.58 | CIA-23 | BRL-CAD: 03starseeker * r32108 10/brlcad/branches/pre-7-12-6/ (4 files in 4 dirs): r31882-85 misc tweaks, doc updates |
| 23:45.28 | CIA-23 | BRL-CAD: 03starseeker * r32109 10/brlcad/branches/pre-7-12-6/src/ (libtclcad/Makefile.am other/blt/Makefile.am): r31904-5 - update blt dependancy information |
| 23:47.29 | CIA-23 | BRL-CAD: 03starseeker * r32110 10/brlcad/branches/pre-7-12-6/ (4 files in 2 dirs): r31909-13 - merge rt_simple into rtexample, configure.ac tweak |
| 23:49.46 | CIA-23 | BRL-CAD: 03starseeker * r32111 10/brlcad/branches/pre-7-12-6/ (configure.ac include/vmath.h src/librtserver/rtserver.c): r31932-34 add V2ADD3 to vmath.h, typo fix, rtserver cleanup |
| 23:55.13 | CIA-23 | BRL-CAD: 03starseeker * r32112 10/brlcad/branches/pre-7-12-6/ (NEWS src/proc-db/tire.c): r31935,36,46,93 - fix accidental tread clipping and jagged edge. |
| 23:57.21 | *** join/#brlcad stustev (n=stustev@ip72-205-246-167.ks.ks.cox.net) | |