| 00:19.43 | yukonbob | hello, cadheads |
| 00:22.07 | Ralith | hello, tundrahead |
| 00:24.14 | yukonbob | :) |
| 00:40.07 | CIA-23 | BRL-CAD: 03starseeker * r32178 10/brlcad/branches/pre-7-12-6/ (5 files in 3 dirs): re-merge r31669 - fast4-g cleanup |
| 00:40.48 | starseeker | arrgh - |
| 00:43.25 | CIA-23 | BRL-CAD: 03starseeker * r32179 10/brlcad/branches/pre-7-12-6/ (COPYING INSTALL misc/enigma/COPYING misc/enigma/INSTALL): ack, how'd that happen? put trunk's COPYING and INSTALL files back |
| 00:51.27 | starseeker | can't figure out how those COPY and INSTALL files got switched |
| 00:51.31 | starseeker | grrrr |
| 00:55.15 | starseeker | is a bit freaked out |
| 01:02.34 | poolio | brlcad: tgc almost works, it's flipped about the z-axis... |
| 01:35.49 | CIA-23 | BRL-CAD: 03starseeker * r32180 10/brlcad/branches/pre-7-12-6/ (9 files in 6 dirs): re-merge up to r31701, previously in this branch 32087 |
| 01:38.00 | starseeker | thinks he may be finally getting the hang of this merge thing |
| 01:38.05 | starseeker | ++FileMerge~ |
| 01:43.43 | ``Erik | effin' fate bitch pizz0wned one of my astros and it'll take 3 hours to get a liberation fleet there *sigh* |
| 01:44.30 | starseeker | isn't sure if ``Erik is playing a game or learning a new language |
| 01:50.10 | *** join/#brlcad jonored (n=jonored@pool-72-74-102-223.bstnma.east.verizon.net) | |
| 01:59.22 | CIA-23 | BRL-CAD: 03starseeker * r32181 10/brlcad/branches/pre-7-12-6/ (3 files in 3 dirs): re-merge up to r31744 where the changes weren't related to new work, including extensive changes to pipe.c , previously in this branch 32092 |
| 02:00.36 | brlcad | starseeker: that can happen during an automatic regeneration during make |
| 02:01.11 | brlcad | if you update/merge configure.ac and Makefile.am updates, and don't run autogen.sh -- it will try automatically |
| 02:01.45 | brlcad | and depending on the exact ordering of things, it can end up blowing away what you have and sticking defaults |
| 02:02.05 | brlcad | I'd bitched about it (informally) to the gnu guys in the past but they didn't seem to really care |
| 02:02.35 | brlcad | since it's obscure and it's the content they think should be in every one's copy of those files anyways |
| 02:02.41 | starseeker | ah |
| 02:02.56 | brlcad | poolio: awesome! |
| 02:03.04 | starseeker | grumbles in the direction of the GNU guys, who sure won't listen to him if they don't listen to brlcad |
| 02:03.17 | brlcad | starseeker: go for it |
| 02:03.37 | brlcad | it was several years ago, I'm sure it's just a matter of catching the right guy(s) at the right time |
| 02:03.54 | brlcad | one of them was zealotry trolling |
| 02:03.55 | stustev | good evening gentlemen |
| 02:04.02 | brlcad | with which I sometimes have very little patience |
| 02:04.11 | brlcad | howdy starseeker |
| 02:04.14 | stustev | question - how do I use TRA? |
| 02:04.53 | starseeker | heh - howdy stustev |
| 02:05.11 | starseeker | hands brlcad some coffee |
| 02:05.14 | stustev | I can't seem to get it to affect anything |
| 02:07.10 | stustev | do I describe geometry after I issue tra xxx yyy zzz? I am trying to mirror and move an object |
| 02:09.21 | brlcad | stustev: you have to be in an edit mode first |
| 02:09.44 | brlcad | either solid/primitive edit or object/matrix edit mode |
| 02:09.45 | stustev | I can't issue this in the command window? |
| 02:10.04 | brlcad | sure, sed primitive ; tra 100 0 0 |
| 02:10.11 | brlcad | accept |
| 02:10.13 | brlcad | reject |
| 02:10.19 | stustev | this is for editing one object at a time? |
| 02:10.29 | brlcad | what are you trying to do? |
| 02:10.41 | brlcad | that would apply an edit to a specific primitive |
| 02:10.42 | stustev | I have a region. |
| 02:10.55 | brlcad | sed == solid edit mode == for editing primitives individually |
| 02:10.58 | stustev | I want to mirror the region and translate it. |
| 02:11.06 | brlcad | oed is for editing groups |
| 02:11.39 | stustev | trying |
| 02:11.41 | brlcad | so mirror; oed; tra |
| 02:12.26 | brlcad | mirror old new ; oed / new/path/to/primitive ; tra x y z ; accept |
| 02:12.59 | brlcad | there is a great tutorial on oed specifically on the website under documentation |
| 02:15.23 | stustev | I will try to tutorial - thanks |
| 02:15.30 | stustev | s/to/the |
| 02:18.31 | brlcad | stustev: starseeker wrote it so if you have any questions -- he's the man |
| 02:18.55 | brlcad | it describes the command pretty well and in detail, including its limitations |
| 02:19.07 | brlcad | as well as it's power/flexibility |
| 02:19.16 | starseeker | feedback welcome :-) |
| 02:20.03 | starseeker | does need to add a section in there about moving objects used multiple times in a combination by blasting in just that component and working on it alone... |
| 02:23.25 | brlcad | more useful would be implementing "oed all.g" ;) |
| 02:23.37 | starseeker | hehe |
| 02:23.52 | starseeker | should add that to the TODO |
| 02:24.05 | brlcad | or even 'ed object' |
| 02:24.21 | starseeker | with type identification that could work |
| 02:24.44 | brlcad | there's no useful reason for there to be two |
| 02:24.50 | brlcad | it was just a technical artifact |
| 02:24.53 | starseeker | absolutely :-) |
| 02:24.56 | brlcad | just like rhs |
| 02:25.36 | starseeker | would very much like to do that, but then he'd have to redo all the docs for it again :-P |
| 02:25.41 | brlcad | and I really hate to say it, but 'e' should probably enter edit mode |
| 02:26.11 | starseeker | wouldn't that cause a lot of trouble with our old timers? |
| 02:26.13 | brlcad | the one-letter commands all need reviewed |
| 02:26.18 | brlcad | yeah it would |
| 02:26.22 | brlcad | so not likely going to happen |
| 02:26.28 | brlcad | but it should" |
| 02:26.40 | brlcad | e means edit, but you don't actually get to edit |
| 02:27.03 | brlcad | s/means/meant/ |
| 02:27.25 | brlcad | rather "display for editing" .. but that's often also just viewing |
| 02:27.31 | starseeker | maybe we can have "command profiles" the way g3d has blender and MGED modes? |
| 02:27.35 | brlcad | hence draw == e |
| 02:27.48 | brlcad | yeah, command sets |
| 02:28.08 | brlcad | and "standard aliases" |
| 02:28.24 | brlcad | i.e. treat it like a full shell |
| 02:28.29 | brlcad | make it BE a full shell |
| 02:28.46 | starseeker | that would rock |
| 02:28.53 | brlcad | then e would just be an alias to the draw command in the mged-compatibility command profile |
| 02:29.50 | starseeker | hehe - e, ed, sed and oed would all end up leading to the same command by default |
| 02:30.58 | starseeker | maybe have the sed and oed versions check to make sure what they're editing, to preserve behavior |
| 02:31.10 | starseeker | or the sed one anyway |
| 02:32.35 | brlcad | possibly, though the modal edit modes need to go eventually too |
| 02:33.34 | brlcad | or combine it into a new non-modal command space |
| 02:33.56 | *** join/#brlcad SWPadnos__ (n=Me@dsl107.esjtvtli.sover.net) | |
| 02:34.06 | brlcad | so things like "tra object 100 0 0" would work, or "object tra 100 0 0" |
| 02:34.56 | starseeker | would like to have the option to go modal or non-modal - modality can be tremendously productive if you want to take the time to learn it (vim) |
| 02:35.12 | starseeker | but the default should be non-modal |
| 02:36.31 | brlcad | in our case, though -- there are still N lines of commands |
| 02:36.50 | brlcad | so the modality really just introduces errors |
| 02:37.43 | brlcad | all it saves you us is typing object names per command as there is a modal "loaded" set (e'd objects) |
| 02:39.08 | CIA-23 | BRL-CAD: 03starseeker * r32182 10/brlcad/branches/pre-7-12-6/ (18 files in 7 dirs): re-merge up to r31822, previously in this branch 32099 |
| 02:45.38 | *** join/#brlcad jonored (n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) | |
| 02:49.24 | *** join/#brlcad andrecastelo (n=chatzill@189.71.78.186) | |
| 02:52.57 | *** join/#brlcad Ralith (n=ralith@c-71-197-213-172.hsd1.or.comcast.net) | |
| 03:40.45 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 03:49.06 | starseeker | brlcad: sorry, connection decided to quit |
| 03:49.31 | starseeker | true, modality does mainly save typing names |
| 03:50.36 | brlcad | could get a similar effect with named edit sets, akin to registers |
| 03:51.14 | brlcad | register 1 obj1 obj2 obj3 |
| 03:51.18 | brlcad | tra 1 100 0 0 |
| 03:51.47 | starseeker | hmm - essentially create temporary groups for the purposes of command application |
| 03:51.49 | brlcad | for what might otherwise be three tra lines for each obj |
| 03:51.54 | starseeker | not bad |
| 03:51.55 | *** part/#brlcad stustev (n=stustev@ip72-205-246-167.ks.ks.cox.net) | |
| 03:52.35 | starseeker | sees potential for confusion though - "does registering objects create combinations? how is a combination different from a register?" |
| 03:52.54 | brlcad | even with just one object, it eliminates the modality and minimizes it to two characters (for at least 0-9 sets) |
| 03:53.04 | brlcad | so regsiter is a bad word |
| 03:53.23 | brlcad | sort of like a named 'e' set |
| 03:53.35 | starseeker | "edit sets" |
| 03:54.17 | starseeker | editset obj1.s obj2.r obj3.c |
| 03:54.24 | starseeker | editset obj1.s obj2.r obj3.c obj1 |
| 03:54.43 | starseeker | maybe enforce that an edit set name does not map to any database object name |
| 03:54.57 | brlcad | something, but the power would be in using "registers", i.e. some simple int id |
| 03:55.04 | starseeker | right |
| 03:55.25 | brlcad | otherwise if you allow arbitrary names, it is confusing/overlapping with groups |
| 03:55.30 | starseeker | true |
| 03:56.09 | brlcad | though .. I can see a case, maybe it's just a matter of defaults |
| 03:56.27 | starseeker | would that be the command line equalivent to graphically selecting several objects and then doing something with them? |
| 03:56.42 | brlcad | exactly |
| 03:56.46 | starseeker | cool |
| 03:57.05 | starseeker | could tie into the exact same functionality we will eventually use to do that graphically |
| 03:57.20 | brlcad | yep, that'd be the intent too I'd hope |
| 03:57.47 | brlcad | I'd like *all* gui actions to actually go through the scripting layer unless there's some unresolvable performance problem |
| 03:58.05 | brlcad | at least, end state actions |
| 03:58.37 | starseeker | maybe we could have a default of a "hidden" name if none is supplied, and then then commands without arguments supplied could default to that |
| 03:58.48 | starseeker | eg editset obj1.s obj2.s obj3.s |
| 03:58.52 | starseeker | tra 100 0 0 |
| 03:59.01 | starseeker | unselect |
| 03:59.03 | starseeker | or some such |
| 03:59.36 | brlcad | so, for example, rotating an object around and dragging it up/down might be thousands of gui events, but they'd amount to one command-line transaction of "apply this matrix" when you go to a different tool/action |
| 03:59.55 | starseeker | cool :-) |
| 04:00.19 | brlcad | "select" |
| 04:00.27 | brlcad | select obj1 obj2 obj3 |
| 04:00.39 | brlcad | returns an int id for that set |
| 04:01.46 | brlcad | so you could "tra [select obj1 obj2] 0 0 100" or "select -id 5 obj1 obj2" .. "tra 5 0 0 100" or something similar |
| 04:04.19 | starseeker | cool |
| 04:04.21 | brlcad | or ftw, the posix shell interface: tra `select obj1 obj2` 0 0 100 |
| 04:05.23 | starseeker | should we optionally avoid an explicit int return, to conceptually match the GUI case? I.e. "just do this on what I just selected, I don't want to care what # it is" |
| 04:05.48 | starseeker | specify an int return if we want the selection to persist beyond the next select command |
| 04:06.42 | brlcad | it still matches the gui with an int -- the gui is just hiding data keeping track of the int for you, akin to setting it to a var |
| 04:06.57 | brlcad | set id [select obj1 obj2] ; tra $id 0 0 100 |
| 04:07.37 | brlcad | the idea being that the gui would actually do exactly that or some similar technique |
| 04:07.43 | brlcad | so you could replicate what the gui is doing exactly |
| 04:07.52 | starseeker | sure |
| 04:07.54 | brlcad | and have a transaction list regardless of which you use |
| 04:08.35 | brlcad | would love to hit the "play" button on a full vehicle being constructed .. with full revision history as it was put together |
| 04:08.40 | starseeker | just wants to hide the selection of the int unless explicitly specified - under the hood all would do the same thing |
| 04:08.48 | starseeker | that would ROCK :-) |
| 04:09.19 | brlcad | rockage on so many levels |
| 04:09.31 | Ralith | then export it to a physics engine and testdrive it :> |
| 04:09.34 | brlcad | that'd probably be worth a paper somewhere |
| 04:13.46 | starseeker | doesn't want any of his revision histories played back just yet |
| 04:13.56 | starseeker | :-P |
| 04:14.50 | Ralith | hehe |
| 04:15.31 | starseeker | steady cam it ain't |
| 04:22.25 | *** join/#brlcad jonored (n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) | |
| 04:25.11 | CIA-23 | BRL-CAD: 03starseeker * r32183 10/brlcad/branches/pre-7-12-6/ (50 files in 30 dirs): re-merge up to r32062, r32120 previously - this should incorporate most of the relevant trunk changes up until that point, and seems to have completed a build on OSX - need a clean checkout to be certain. |
| 04:25.20 | starseeker | brlcad: Can I grab the new mged initialization for 7.12.6? |
| 04:51.57 | starseeker | and the new kill stuff? |
| 04:52.11 | brlcad | initilzation? |
| 04:52.34 | brlcad | I don't think you can merge killrefs without libged |
| 04:52.40 | starseeker | mrf |
| 04:52.52 | brlcad | ooh, new mged init -- yeah, that should merge easy |
| 04:52.54 | starseeker | your new mged mods that let mged start through menus/icons |
| 04:52.57 | starseeker | cool :-) |
| 04:53.16 | starseeker | that'll be a nice feature to have in the stable release |
| 04:54.10 | starseeker | looks at killrefs quick... |
| 04:56.30 | starseeker | is sorely tempted to try, but it looks like you're probably right |
| 04:56.54 | brlcad | there's always next month |
| 04:57.10 | starseeker | will libged be ready by then? |
| 04:57.19 | starseeker | WOOOOO HOOOOOOOO |
| 04:57.23 | brlcad | gotta draw the line somewhere else it can drag on indefintiely |
| 04:57.34 | brlcad | iff bob keeps up his pace, possibly |
| 04:57.44 | starseeker | gets mged to start up built from the HEAD of pre-7-12-6 |
| 04:58.01 | brlcad | maybe two months -- but it should be stabilizable within a couple weeks regardless of libged being finished |
| 04:58.20 | brlcad | if anything, can just start throwing the bugs at bob as they're found until he's done, or help him debug |
| 04:58.57 | starseeker | true |
| 04:59.17 | starseeker | does happy dance that he can now build and install with almost all the changes merged in |
| 04:59.45 | Ralith | yay! |
| 05:00.01 | starseeker | That was a big first step on the road to a release |
| 05:00.14 | Ralith | if it needs testing on other platforms, I'm happy to give it a build on FreeBSD |
| 05:00.36 | starseeker | please - check out branches/pre-7-12-6 to give it a whirl |
| 05:02.06 | starseeker | would appreciate |
| 05:03.05 | Ralith | uh |
| 05:03.13 | Ralith | I can't seem to work out how that translates to a svn checkout url :/ |
| 05:03.18 | starseeker | one sec... |
| 05:03.46 | starseeker | svn co https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/branches/pre-7-12-6 |
| 05:03.59 | Ralith | ahh, double brlcad. |
| 05:04.42 | brlcad | starseeker: ran make benchmark and make test ? |
| 05:05.09 | brlcad | have to scan the test output, it'll keep going even if it fails |
| 05:05.26 | brlcad | also be sure to do a make distcheck .. that will really show where things are pooched |
| 05:06.50 | starseeker | not yet |
| 05:07.04 | starseeker | just got done getting basics working :-) |
| 05:08.29 | brlcad | then checking both default build and --enable-all builds ;) |
| 05:09.07 | starseeker | :-) |
| 05:09.25 | starseeker | saw the release section in the HACKING file - he'll step through it |
| 05:09.39 | brlcad | then doing all those same steps for all platforms ;) |
| 05:09.48 | starseeker | this is just the first time I've had any hope at all of working ;-) |
| 05:10.01 | starseeker | will make Bob do the Windows binary :-P |
| 05:10.44 | Ralith | yawns and watchs svn scroll |
| 05:10.57 | starseeker | dreads the drive home |
| 05:11.08 | brlcad | just sent a long e-mail to the sf.net vice pres. after today's irc meeting |
| 05:11.20 | brlcad | talking about performance .. albeit web performance |
| 05:11.38 | starseeker | subversion you mean? |
| 05:11.49 | brlcad | nope, project sites |
| 05:11.56 | starseeker | ah |
| 05:11.57 | brlcad | subversion is just migration pains |
| 05:13.19 | brlcad | crap, I think I broke mged regressibility on trunk |
| 05:13.30 | starseeker | how so? |
| 05:13.55 | brlcad | the mged init changes I think, doing something odd with the scripts |
| 05:14.31 | starseeker | will hold off for the moment then (nuts) |
| 05:14.34 | brlcad | some complete, some are failing |
| 05:14.55 | starseeker | s ees it too |
| 05:15.30 | brlcad | not good, really gotta stabilize trunk |
| 05:15.37 | brlcad | this is the most instable it's been in years |
| 05:15.46 | brlcad | er, unstable |
| 05:15.52 | brlcad | uncredible |
| 05:16.10 | Ralith | web performance? |
| 05:16.17 | Ralith | it's that bad? |
| 05:16.43 | brlcad | Ralith: yes, the fact that if you go to http://sourceforge.net/projects/brlcad/ |
| 05:16.55 | brlcad | uncached, that results in approx 72 requests |
| 05:17.07 | brlcad | 23 of which are for advertisement data |
| 05:17.29 | brlcad | those 23 dominate more than 50% of the data |
| 05:18.02 | Ralith | that is a bit annoying, but is it actually a problem? |
| 05:18.17 | starseeker | adblock plus ftw |
| 05:18.58 | brlcad | about 230KB to load the page from scratch for starters .. of which abou 130KB is ad, 100KB for *everything* else |
| 05:19.15 | starseeker | yeesh |
| 05:19.15 | Ralith | 22:18:17 < starseeker> adblock plus ftw |
| 05:19.17 | Ralith | qft |
| 05:19.24 | starseeker | qft? |
| 05:19.27 | Ralith | quoted for truth |
| 05:19.33 | starseeker | heh |
| 05:19.51 | brlcad | prefers /etc/hosts |
| 05:20.04 | Ralith | /etc/hosts doesn't auto-update |
| 05:20.06 | brlcad | easier to manage, less overhead, browser agnostic |
| 05:20.24 | Ralith | adblock these days has other people blocking stuff for you |
| 05:20.28 | Ralith | which works great in practice |
| 05:20.46 | Ralith | don't remember the last time I saw an obtrusive ad |
| 05:21.15 | starseeker | isn't too picky about sf adds given how useful they are, but that's just him |
| 05:21.23 | brlcad | I don't mind some ads that are actually on-topic, low overhead, easy to ignore if I want to, etc |
| 05:21.33 | starseeker | ah |
| 05:21.46 | starseeker | edcolor is an expected unable to test in the mged regress? |
| 05:21.46 | brlcad | e.g. /.'s ads are often just fine |
| 05:22.02 | brlcad | starseeker: yeah for now |
| 05:22.06 | starseeker | k |
| 05:22.07 | Ralith | I like how /. serves microsoft ads, though |
| 05:22.12 | starseeker | make test marchs on |
| 05:22.13 | Ralith | it's funny when you see one on a ms-bashing article |
| 05:22.22 | brlcad | yep |
| 05:22.40 | Ralith | back to the point, though, sf.net has never been what I'd call terribly slow |
| 05:23.03 | Ralith | and they're providing a lot of service for a lot of people for no direct profit |
| 05:23.09 | starseeker | depends on the internet connection |
| 05:23.20 | Ralith | oh hey, my checkout finished! |
| 05:23.24 | starseeker | :-) |
| 05:23.47 | Ralith | (kind of ironic, in the context of my argument that sf has decent speeds) |
| 05:24.04 | starseeker | brlcad: 0 off by many is expected? |
| 05:24.17 | starseeker | solids.rt.pix 0 off by many |
| 05:24.51 | starseeker | if so, make test succeeded |
| 05:25.06 | starseeker | makes a note to look at the regression system's reporting |
| 05:25.27 | starseeker | wants a wtf just happened summary like the configure end of things has |
| 05:27.30 | starseeker | what a great slashdot headline: The War Against Virtual Beer Pong |
| 05:28.37 | starseeker | was sure he was losing it |
| 05:28.53 | Ralith | sets the compile going |
| 05:29.15 | brlcad | Ralith: don't get me wrong, I'm a huge sf.net supporter -- using them for nearly a decade in some fashion now |
| 05:29.37 | brlcad | that's why they even care to hear my complaint |
| 05:29.46 | brlcad | i think they do a lot of great even with the ads |
| 05:30.14 | brlcad | it's just excessive that there is actually more ad data than real content (and that a page would take 72 requests, 72 potential latency points) to load |
| 05:30.18 | Ralith | starseeker: hehe |
| 05:30.31 | starseeker | confesses to wondering if ping started the war against pong |
| 05:30.46 | Ralith | it is very frustrating when an ad site is down or something and that ruins a page's load time |
| 05:30.52 | brlcad | starseeker: yes, 0 off is good |
| 05:30.58 | starseeker | sweet |
| 05:31.04 | starseeker | is running the benchmark now |
| 05:31.10 | Ralith | but it's hard to serve ads on a site like sf.net without having lots of data-wise disproportionality |
| 05:31.13 | CIA-23 | BRL-CAD: 03homovulgaris * r32184 10/brlcad/trunk/src/libpc/ (pcConstraint.cpp pcConstraint.h): Adding a display() method to the constraint object, modification of constructor to expect va_list * instead of (...) |
| 05:31.22 | Ralith | most project relevent data is text, while the ads are generally images or even flash |
| 05:31.28 | Ralith | (dunno if sf.net does flash ads) |
| 05:31.29 | brlcad | and shaders is known to fail with 3 off by 1 on one of the 64bit platforms so you know .. but shouldn't any where else |
| 05:31.43 | brlcad | er, 3 off by many |
| 05:31.45 | Ralith | what's that a measurement off? |
| 05:31.47 | Ralith | er |
| 05:31.48 | Ralith | of? |
| 05:31.53 | starseeker | how does sf.net look in text mode links? |
| 05:32.04 | Ralith | testing in w3m |
| 05:32.15 | Ralith | a few layout issues, but generally pretty clean |
| 05:32.52 | brlcad | if you want to speed up benchmarking for testing (since it really only needs to run each frame once for testing purposes, set the TIMEOUT environment variable to 1 |
| 05:33.06 | CIA-23 | BRL-CAD: 03homovulgaris * r32185 10/brlcad/trunk/src/libpc/ (pcPCSet.cpp pcPCSet.h solver_test.cpp): addConstraint method of PCSet elaborated , modifications to the PCSet::display() method |
| 05:33.14 | brlcad | er, sorry, TIMEFRAME! |
| 05:33.28 | starseeker | :-) |
| 05:33.42 | starseeker | will let it run, it's probably about halfway already |
| 05:33.51 | brlcad | e.g. TIMEFRAME=0 make benchmark |
| 05:34.00 | brlcad | or export TIMEFRAME=0, etc |
| 05:34.11 | starseeker | holy cow, NASA's Phoenix probe found water in a sample on Mars |
| 05:34.12 | brlcad | otherwise it'll take 10 minutes every time |
| 05:35.05 | brlcad | Ralith: it's a high-level integration test of the ray tracer |
| 05:35.33 | brlcad | which in turn ends up testing nearly everything in several libraries |
| 05:36.04 | starseeker | brlcad: cool, thanks! :-) that will help quite a lot |
| 05:36.27 | brlcad | it compares the ray-trace result against a known good result, if any pixel value in the resulting image is ever different -- it will detect and report |
| 05:36.48 | Ralith | starseeker: actually confirmed, not just "oh hey that looks shiny and waterlike"? |
| 05:36.58 | starseeker | Ralith: apparently |
| 05:37.06 | brlcad | "off by 1" errors and "off by many" errors indicate the RGB for a given pixel is slightly (or not so slightly) different |
| 05:37.15 | Ralith | sounds pretty rigorous. |
| 05:37.45 | starseeker | pixcmp pixels: 262070 matching, 74 off by 1, 0 off by many |
| 05:37.47 | brlcad | it is, it'll detect subtle floating point unit issues, compiler optimization bugs, etc |
| 05:37.58 | brlcad | starseeker: for benchmarking, off by 1's are fine |
| 05:38.21 | starseeker | k |
| 05:38.24 | brlcad | those are floating point differences within tolerance |
| 05:38.45 | starseeker | now why isn't there a sphflake.pix file for comparison?? |
| 05:38.46 | brlcad | 234 54 63 vs 233 54 63 |
| 05:38.56 | brlcad | there is |
| 05:39.39 | brlcad | crew:~/brlcad sean$ ls -la pix/sphflake.pix |
| 05:39.40 | brlcad | -rw-r--r-- 1 sean sean 786432 May 10 10:36 pix/sphflake.pix |
| 05:39.44 | starseeker | I must have lost it somehow... |
| 05:40.24 | brlcad | that's not good .. it's in svn .. or should be |
| 05:42.49 | brlcad | now that we have a proper image gallery in place, should get rid of the unnecessary pix files from svn |
| 05:43.01 | brlcad | move them into the gallery at some point |
| 05:43.09 | brlcad | especially .. toilet.pix |
| 05:43.29 | starseeker | is afraid to ask |
| 05:43.40 | brlcad | check it out.. |
| 05:44.18 | Ralith | build went fine |
| 05:44.21 | Ralith | running test suite |
| 05:45.17 | starseeker | thinks a student got bored... |
| 05:45.24 | brlcad | starseeker: pix-fb -h pix/toilet.pix |
| 05:45.33 | starseeker | oh, me has it up :-) |
| 05:45.40 | brlcad | that was chris johnson |
| 05:45.43 | *** join/#brlcad Ralith (n=ralith@c-71-197-213-172.hsd1.or.comcast.net) | |
| 05:46.02 | Ralith | ugh |
| 05:46.19 | Ralith | make test popped up the mged gui while I was watching a movie fullscreen |
| 05:46.25 | Ralith | which made X freak out and die |
| 05:46.28 | brlcad | i mean neat n all, nice rounded edges, but .. heh |
| 05:46.31 | starseeker | uh oh |
| 05:46.42 | Ralith | >:| |
| 05:46.43 | brlcad | yikes |
| 05:47.03 | brlcad | starseeker: is that with the mged init code? |
| 05:48.00 | starseeker | no, it's the new mged regress test |
| 05:48.09 | *** join/#brlcad Ralith (n=ralith@c-71-197-213-172.hsd1.or.comcast.net) | |
| 05:48.11 | starseeker | I saw an mged window flash by on my screen too |
| 05:48.16 | Ralith | ok |
| 05:48.25 | Ralith | looks like we have a problem. |
| 05:48.38 | starseeker | what's that? |
| 05:48.40 | Ralith | mplayer had nothing to do with that crash; it just happened again :| |
| 05:48.47 | starseeker | uh... |
| 05:48.58 | Ralith | might that have to do with an erroneously set BRLCAD_ROOT? |
| 05:49.13 | Ralith | no, wait, I unset that the first time around |
| 05:49.21 | Ralith | so yeah, mged seems to be killing my X on startup |
| 05:49.33 | starseeker | that's not good |
| 05:49.36 | Ralith | Xorg log: |
| 05:49.37 | Ralith | Fatal server error: |
| 05:49.37 | Ralith | Caught signal 11. Server aborting |
| 05:49.37 | starseeker | how did you build? |
| 05:49.49 | Ralith | no options to configure other than --prefix |
| 05:49.51 | starseeker | wait, you mean it's STILL not starting up |
| 05:49.53 | brlcad | starseeker: ah, one of the commands is basically "open the gui" so that seems right |
| 05:50.01 | Ralith | no, X starts up again fine :P |
| 05:50.04 | brlcad | and it intentially tests all commands (except edcolor) |
| 05:50.13 | Ralith | that's the log from when it died |
| 05:50.25 | brlcad | Ralith: sounds like an X11 bug even if we're provoking it |
| 05:50.31 | Ralith | kk |
| 05:50.35 | brlcad | i suspect it's the opengl driver killing X |
| 05:50.37 | Ralith | will test running mged by hand |
| 05:50.42 | Ralith | I'm using nvidia's proprietary driver |
| 05:50.43 | starseeker | are you getting a system Tcl/Tk? |
| 05:50.44 | Ralith | so that could be at fault |
| 05:50.49 | brlcad | and mged using opengl making it go wah |
| 05:50.50 | Ralith | no, it's using built in tcl/tk |
| 05:50.58 | starseeker | hmm |
| 05:51.02 | brlcad | you built it yourself? |
| 05:51.07 | pacman87 | i'm running nvidia prop too |
| 05:51.11 | Ralith | built which? |
| 05:51.23 | brlcad | that version of mged |
| 05:51.26 | Ralith | pacman87: yeah, but weird driver issues are likely to be hard to reproduce |
| 05:51.28 | pacman87 | i had some trouble with mged taking 100% cpu |
| 05:51.32 | Ralith | brlcad: yeah, I just built starseeker's pre |
| 05:51.33 | brlcad | i suppose if you're running make test, then yes you are.. |
| 05:51.52 | Ralith | testing mged now |
| 05:51.58 | Ralith | ... |
| 05:52.01 | brlcad | test with ./configure --enable-all --without-opengl |
| 05:52.19 | Ralith | sec |
| 05:52.21 | brlcad | mged by itself should fail similarly |
| 05:52.33 | brlcad | could try mged -c |
| 05:52.34 | Ralith | we'll find out as soon as install finishes |
| 05:52.55 | brlcad | then select X or ogl for the dm |
| 05:53.06 | Ralith | my instinct is that the failure won't happen on a standard startup |
| 05:53.10 | brlcad | X should work, ogl should fail I bet |
| 05:53.24 | Ralith | hm |
| 05:53.29 | Ralith | is there a way to run a nested X session? |
| 05:53.53 | Ralith | ah well, here goes nothing. |
| 05:54.03 | brlcad | heh |
| 05:54.10 | pacman87 | i guess that didnt work |
| 05:54.14 | starseeker | ow |
| 05:54.18 | starseeker | feels bad |
| 05:54.19 | brlcad | looks like it worked to me! |
| 05:54.35 | *** join/#brlcad saltan (n=lievensa@d51530284.access.telenet.be) | |
| 05:54.39 | pacman87 | for which defination of 'work'? |
| 05:54.40 | *** join/#brlcad Ralith (n=ralith@c-71-197-213-172.hsd1.or.comcast.net) | |
| 05:54.43 | brlcad | hehe |
| 05:54.45 | Ralith | well |
| 05:54.49 | Ralith | you don't need me to tell you how that went |
| 05:54.59 | Ralith | how do I launch it with ogl disabled? |
| 05:55.00 | starseeker | what about rtwizard? |
| 05:55.08 | pacman87 | was that mged or mged -c? |
| 05:55.09 | brlcad | Ralith: mged -c |
| 05:55.32 | Ralith | er, wasn't there some way to set the renderer to something non-opengl? |
| 05:55.34 | brlcad | select X or nu |
| 05:55.40 | Ralith | oh |
| 05:55.42 | Ralith | right |
| 05:55.50 | Ralith | X works fine |
| 05:55.55 | Ralith | nu too |
| 05:56.00 | Ralith | testing rtwizard |
| 05:56.08 | brlcad | in nu, try "attach ogl" |
| 05:56.30 | brlcad | or just try ogl |
| 05:56.37 | brlcad | from the prompt |
| 05:56.39 | Ralith | % bin/rtwizard |
| 05:56.40 | Ralith | Itcl_Init ERROR: |
| 05:56.40 | Ralith | already installed: [incr Tcl] |
| 05:56.40 | Ralith | ERROR: Application initialization failed |
| 05:56.41 | Ralith | Error in startup script: couldn't load file "./lib/itk3.4/libitk3.4.a": Cannot open "./lib/itk3.4/libitk3.4.a" |
| 05:56.46 | Ralith | when launching rtwizard |
| 05:56.53 | Ralith | note that I've installed in a nonstandard location |
| 05:57.04 | Ralith | the app does open, but with a featureless square window |
| 05:57.08 | Ralith | ~square |
| 05:57.15 | brlcad | that's a different issue, rtwizard is a pita |
| 05:57.18 | Ralith | kk |
| 05:57.31 | Ralith | testing 'ogl' on mged -c prompt |
| 05:57.45 | Ralith | invalid command name "ogl" |
| 05:57.46 | Ralith | :P |
| 05:57.53 | Ralith | attaching instead. |
| 05:57.53 | brlcad | "attach ogl" |
| 05:57.59 | starseeker | ow |
| 05:58.00 | brlcad | or ogl during the Attach prompt |
| 05:58.10 | starseeker | thinks he figured it out |
| 05:58.34 | *** join/#brlcad Ralith (n=ralith@c-71-197-213-172.hsd1.or.comcast.net) | |
| 05:58.36 | brlcad | I think he's just yanking our chain |
| 05:58.41 | brlcad | there's nothing wrong with it |
| 05:58.43 | Ralith | :P |
| 05:58.55 | starseeker | wonders if that happens with 7.12.4 and/or trunk |
| 05:59.07 | brlcad | starseeker: it does, known issue |
| 05:59.09 | brlcad | in the bugs file |
| 05:59.10 | Ralith | I'm running 7.12.4 as built by freebsd ports |
| 05:59.21 | Ralith | er |
| 05:59.21 | starseeker | and that does work? |
| 05:59.23 | Ralith | that is |
| 05:59.31 | Ralith | 7.12.4 as built by freebsd ports works great |
| 05:59.32 | brlcad | it is a driver bug, different versions are less catastrophic |
| 05:59.36 | Ralith | haven't tested trunk |
| 05:59.44 | starseeker | ah |
| 05:59.49 | Ralith | shall I try trunk? Is this solvable? |
| 06:00.07 | brlcad | it's based on whether we ask/get a direct opengl rendering context from glx |
| 06:00.28 | Ralith | surely there's a way to fail more elgantly than killing X? |
| 06:00.33 | brlcad | it's actually a one-character flag in one source file that usually will take it from all going to hell and not |
| 06:01.23 | Ralith | so... fixable? |
| 06:01.23 | brlcad | Ralith: iirc, it dies the first time it tries to draw on the context |
| 06:01.29 | Ralith | ah. |
| 06:01.32 | Ralith | no way to safely validate the context? |
| 06:01.39 | brlcad | before that, everything checks out |
| 06:01.49 | starseeker | evil |
| 06:02.09 | starseeker | will have to ask ``Erik what the freebsd ports version does |
| 06:02.13 | pacman87 | trunk still goes 100% cpu on me without -c |
| 06:02.18 | brlcad | it avoids causing the crash by asking for a software rendering context |
| 06:02.28 | brlcad | which absolutely sucks for performance |
| 06:02.29 | Ralith | starseeker: I can see right off that the freebsd version doesn't patch anything |
| 06:02.37 | Ralith | that would suck. |
| 06:02.45 | Ralith | but I run glx things on here all the time |
| 06:02.58 | brlcad | hence the suggestion to use --without-opengl during configure |
| 06:02.58 | Ralith | what's brl-cad doing that they aren't? |
| 06:02.58 | brlcad | same functionality,but avois the crash |
| 06:03.09 | Ralith | wait, --without-opengl still allows acceleration? |
| 06:03.14 | brlcad | Ralith: feel free to debug it ;) |
| 06:03.19 | Ralith | no thanks :P |
| 06:03.27 | Ralith | has reset enough for one night |
| 06:03.43 | brlcad | sure, it often actually outperforms as the X calls have less overhead |
| 06:03.50 | Ralith | heh |
| 06:04.04 | Ralith | so long as the new gui doesn't have the issue. |
| 06:04.14 | Ralith | (it doesn't. Yet, anyway.) |
| 06:04.31 | brlcad | there's no loss in functionaltiy remember, this is pretty low level "what language am I talking to for this unknown generic display device thing" |
| 06:04.50 | Ralith | doesn't it lose hardware accel? |
| 06:04.51 | brlcad | new gui is entirely different architecture/design |
| 06:05.01 | starseeker | should we just trigger the without-opengl flag on BSD for now? |
| 06:05.04 | brlcad | only if X isn't accelerated |
| 06:05.12 | Ralith | ...huh. |
| 06:05.17 | brlcad | and if X isn't, you're not getting accelerated anything |
| 06:05.19 | Ralith | so why bother with GL at all when X is available? |
| 06:05.46 | brlcad | all the new stuff started happening in the X layer, it's more generalized |
| 06:05.53 | brlcad | er, s/X/ogl/ |
| 06:06.11 | brlcad | so for example, there's an experimental "shaded mode" |
| 06:06.15 | brlcad | that only works with ogl |
| 06:06.19 | Ralith | there is? O.O |
| 06:06.24 | Ralith | wants to play with that :( |
| 06:06.26 | brlcad | but it's so experimental that it's not used |
| 06:06.47 | Ralith | I wasn't aware we had the infastructure to support a shaded mode yet. |
| 06:06.54 | brlcad | there aren't any production-ready features in ogl that X doesn't do |
| 06:07.01 | Ralith | kk |
| 06:07.02 | brlcad | we do and we don't |
| 06:07.25 | brlcad | there has been a way in there for nearly a decade |
| 06:07.25 | starseeker | I gotta run guys - I've still got a 35 minute drive home |
| 06:07.25 | brlcad | it's just really expensive to evaluate .. and not robust |
| 06:07.33 | brlcad | starseeker: yowsa! |
| 06:07.44 | starseeker | yeah, I'm still at work :-/ |
| 06:07.45 | brlcad | cya |
| 06:07.46 | Ralith | what's it do, shoot a bunch of rays to test for depth and assemble a mesh? |
| 06:08.16 | brlcad | no, that could be done more robustly probably |
| 06:08.23 | brlcad | though it's still be relatively slow |
| 06:08.29 | starseeker | it was worth it though - now I have a firm foundation on which to shake out any release bugs :-) |
| 06:08.40 | Ralith | if it's not terribly hard to explain, how does it work? |
| 06:09.00 | brlcad | sure, so you have a geometry hierarchy |
| 06:09.04 | brlcad | starseeker: excellent! |
| 06:09.27 | brlcad | that hierarchy consists of nodes with boolean operations and leaf nodes that are primitives |
| 06:10.12 | brlcad | basically, it tessellates each primitive, then pairwise combines their mesh per the boolean operation all the way up the hierarchy |
| 06:10.18 | Ralith | ah. |
| 06:10.40 | Ralith | and the mesh boolean ops have a tendency to fail? |
| 06:10.50 | Ralith | (limited accuracy aside) |
| 06:11.21 | brlcad | even the primitive tessellations can fail, though I'd characterise those more as tolerance bugs that can be fixed |
| 06:11.30 | brlcad | but yeah, the mesh boolean ops can fail |
| 06:12.01 | Ralith | That strikes me as weird, despite being an issue present in every mesh boolean tool I've seen |
| 06:12.23 | brlcad | it's an np-complete problem at that point, lots of issues come into play -- floating point tolerance, numerical drift, several O(n^3) algorithms, and more |
| 06:12.30 | Ralith | ah. |
| 06:12.33 | Ralith | that's no fun at all. |
| 06:12.48 | brlcad | conceptually, it's very simple |
| 06:12.53 | brlcad | in practice, it's hell |
| 06:13.05 | Ralith | so poolio's project is basically a rehash of that done the Right Way, with no tesselation involved? |
| 06:13.21 | brlcad | especially if you try and guarantee that you end up with the same topological structure and that it's a closed solid volume (which a lot of meshers ignore) |
| 06:13.40 | brlcad | there is still tessellation, but *after* the boolean is evaluated, not before |
| 06:14.07 | brlcad | evaluating the spline surfaces against each other first, deriving evaluated spline surface results |
| 06:14.38 | brlcad | then just walking each surface and asking for a tessellation .. much more stable (and efficient) approach |
| 06:14.51 | Ralith | is it possible for a library user to get ahold of the spline data, so that one could e.g. generate a set of nice smooth vector slices appropriate for being fed into a rapid prototyper? |
| 06:14.52 | brlcad | just a bit harder to implement |
| 06:15.27 | Ralith | basically, get in before the tesselation induces imprecision? |
| 06:15.59 | brlcad | sure, conceivably with this new multirepresentation format, you can evaluate any evaluated brep object with a plane and derive a vector representation of that slice |
| 06:16.06 | Ralith | :D |
| 06:16.09 | brlcad | use that for images, for g-code generation |
| 06:16.12 | Ralith | awesome! |
| 06:16.16 | brlcad | truely |
| 06:16.48 | brlcad | for rapid prototyping, though, you can do that now discretely with ray-tracing |
| 06:17.02 | Ralith | that's good to know |
| 06:17.05 | brlcad | far far simpler to implement, should be more than sufficient to a given tolerance |
| 06:17.14 | jonored | Getting the surfaces to trace doesn't seem as straightforward with the raytracing. |
| 06:17.15 | Ralith | but for some purposes, bar extremely smart g-code generators |
| 06:17.25 | Ralith | it's much more useful to have the vectors |
| 06:17.26 | brlcad | jonored: how so? |
| 06:17.45 | Ralith | jonored: if all else fails, just boolean subtract away all but a thin slice of the object, render orthographically, rinse, repeat |
| 06:17.56 | brlcad | intersect your object (CSG intersection operation) for each layer, raytrace each layer orthogonally |
| 06:18.06 | Ralith | right, intersect. that would be easier. |
| 06:18.28 | brlcad | actually subtraction would be more efficient :) |
| 06:18.34 | Ralith | hehe |
| 06:18.44 | brlcad | but yeah, same result |
| 06:18.57 | brlcad | assuming you're on the right side ;) |
| 06:18.57 | Ralith | the great thing about the vector version, though, is machines like the reprap can accept g-code for smooth curves |
| 06:19.00 | jonored | Well, infill seems simple, but I wasn't quite seeing how to pull the outline as a curve from just raytracing. I may be being dense. |
| 06:19.17 | Ralith | which can then be printed perfectly smooth, and even at higher speed than a manyline approximation |
| 06:19.31 | Ralith | jonored: we can't, but it's no worse than what we already do. |
| 06:19.45 | brlcad | Ralith: raytrace it to a high-enough tolerance and then you can do edge reconstruction, interpolate a matching spline |
| 06:19.51 | Ralith | edge reconstruction is no fun. |
| 06:20.01 | Ralith | jonored: there's even a discussion on the reprap forums about doing a similar thing with povray. |
| 06:20.11 | brlcad | it's not, but you can sample as much as you like to find boundaries |
| 06:20.36 | Ralith | besides, there's something very satisfying about having *perfect* precision throughout the whole process |
| 06:20.39 | Ralith | barring hardware fp errors |
| 06:20.40 | jonored | ...which is why I wasn't hacking around with tcl already to get a slicer built on brl-cad. |
| 06:20.42 | brlcad | true |
| 06:21.22 | Ralith | jonored: I don't know if that would be worthwhile; brl-cad probably won't attract any serious use from the reprap guys very easily until the new gui is usable, and at that point poolio's work might be usable, too. |
| 06:21.53 | brlcad | there are several really good papers that have sprung up this year on how to efficiently evaluate surface-surface intersections, so I'm pretty hopeful/convinced we can get something working out of this |
| 06:21.54 | Ralith | brlcad: I'm the sort of guy who cares about the difference between a .01mm _| and a .01mm / |
| 06:22.06 | Ralith | great :) |
| 06:22.28 | jonored | There's a difference between using it as a modeler and using it because it has a bunch of converters in the context of writing a program. |
| 06:22.31 | Ralith | at least, in the context of application for rapidprototyping |
| 06:23.03 | Ralith | jonored: true, but you lose most of the awesomeness if you're importing non-csg data anyway. |
| 06:23.21 | brlcad | Ralith: it's actually our #1 priority project right now |
| 06:23.24 | Ralith | I'm not sure non-csg data can be very usefully imported for nonvisual purposes, anyway. |
| 06:23.31 | brlcad | followed closely behind by STEP conversion support |
| 06:23.39 | Ralith | that's really good to hear |
| 06:23.45 | brlcad | followed by new geometry engine and geometry service |
| 06:23.50 | brlcad | followed by new gui work |
| 06:23.55 | jonored | Ralith: If you use Adrian's csg-of-half-spaces interpretation for STL stuff, it seems like it imports reasonably well... |
| 06:24.11 | brlcad | they all tie in to each other though .. BREP/NURBS support is pretty foundational though |
| 06:24.16 | brlcad | hence it being top-priority |
| 06:24.35 | Ralith | jonored: csg-of-half-spaces? I'm not familiar with that. |
| 06:24.36 | brlcad | can't do good gui or conversion support without it |
| 06:25.21 | Ralith | heh |
| 06:25.23 | Ralith | here's a thought |
| 06:25.52 | brlcad | Ralith: we can import non-csg data .. ray-trace, analyze and manipulate it like any other geometry .. combine non-csg brep with csg primitives, etc |
| 06:26.10 | Ralith | I wonder if you could convert meshes to CSG fairly easily by simply generating an extruded triangule at every face, then extruding them back until they intersect another face, then unioning them all. |
| 06:26.12 | brlcad | you just have a heck of a time editing polygonal models |
| 06:26.17 | jonored | Ralith: Going and looking up the thing - if you think about it a bit, an object whose surface is made up of planar facets and one that's a CSG combination of half-spaces seem to be the same set. |
| 06:26.25 | brlcad | and there's pretty much no suport to edit spline surface models yet |
| 06:26.43 | Ralith | brlcad: I wasn't aware there was good support for boolean operations on non-csg data. that's good to hear, too. |
| 06:27.19 | brlcad | the ray trace engine will evaluate just about anything and any combination thereof |
| 06:27.29 | Ralith | neat. |
| 06:27.49 | Ralith | jonored: forgive my infamiliarity with terminology -- half spaces? |
| 06:28.16 | brlcad | it's one of the strenths of our engine, part why brl-cad exists |
| 06:28.44 | Ralith | I hope poolio's work will be as flexible. |
| 06:29.12 | jonored | Ralith: The surface is a plane, and everything on one side is in the solid, and everything on the other isn't. |
| 06:29.13 | brlcad | jonored: not sure if you're indirectly referring to it, but we have a specific primitive that is exactly that |
| 06:29.40 | brlcad | arbn .. collection of n half-spaces that form an arbitrary convex polyhedral solid |
| 06:30.11 | Ralith | no potential for nonconvex things? |
| 06:30.21 | brlcad | not using half-spaces :) |
| 06:30.28 | jonored | Ralith: Union of two of them? |
| 06:30.53 | brlcad | oh sure, you can always perform additional booleans with others |
| 06:30.56 | Ralith | jonored: I'm pretty sure they can be a bitch to cut apart computationally for that |
| 06:31.48 | brlcad | unioning two arbn's though is not the same as taking the union of all the half-spaces that those two are comprised of |
| 06:32.47 | brlcad | i.e. they're not associative |
| 06:33.47 | Ralith | arbn is an arbitrary convex solid describable by a mesh? |
| 06:34.56 | jonored | Ralith: The stuff I'm ranting about is there (admittedly without detail as to algorithm) at the bottom of http://www.reprap.org/bin/view/Main/MultipleMaterialsFiles |
| 06:35.57 | Ralith | jonored: we should add brlcad databases to the article. |
| 06:38.13 | jonored | ...You know, they do rather have all of the characteristics that we could want, don't they. Including the multiple material part. We should get a slice routine put together. That said, I am being dragged off to bed; it's 2:30 here. |
| 06:41.07 | Ralith | yeah, I've been thinking about storing material properties in region metadata for a while |
| 06:41.10 | Ralith | g'night |
| 07:05.25 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 07:16.08 | Ralith | brlcad: do you ever sleep? |
| 07:51.53 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 08:44.30 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 09:04.11 | *** join/#brlcad cad00 (n=4669146c@bz.bzflag.bz) | |
| 09:10.04 | brlcad | Ralith: why bother? |
| 09:10.47 | brlcad | and yes, arbn 'can' be fairly easily described by a mesh |
| 09:11.43 | brlcad | presuming it's a convex mesh |
| 09:11.44 | *** join/#brlcad Elperion (n=Bary@p5B14E667.dip.t-dialin.net) | |
| 09:19.41 | brlcad | unless you do what you indicated and piecewise deconstruct a concave structure into unions of convex |
| 09:20.20 | brlcad | wanders back to code |
| 09:37.23 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 09:46.10 | mafm | hallo |
| 09:49.18 | Ralith | hay |
| 10:13.12 | *** join/#brlcad thing0 (n=ric@124-169-162-93.dyn.iinet.net.au) | |
| 10:27.03 | CIA-23 | BRL-CAD: 03mafm * r32186 10/rt^3/trunk/data/g3d/RBGui/themes/ (9 files): Adding new icons for windows |
| 10:27.46 | Ralith | oo, icons! |
| 10:28.05 | Ralith | mafm: by the way, I think I can generate freebsd binary tarballs pretty easily |
| 10:29.32 | mafm | goody |
| 10:30.04 | mafm | I think that brlcad wanted binary tarballs for every platform, not "native formats" (deb, rpm, whatever) |
| 10:30.26 | mafm | I don't know if cmake has some support for it? |
| 10:31.05 | Ralith | it's moot |
| 10:31.13 | Ralith | you can make one by having cmake install to an empty dir |
| 10:31.14 | Ralith | then tarring up the dir |
| 10:31.46 | mafm | yep, that too :) |
| 10:34.30 | CIA-23 | BRL-CAD: 03mafm * r32187 10/rt^3/trunk/src/g3d/ (GuiWindowManager.cxx GuiWindowManager.h): Adding new method for getting the default theme being used (and thus be able to ask for resources like images easily) |
| 10:34.53 | Ralith | I really need to get to sleep, anyway |
| 10:34.54 | Ralith | good luck |
| 10:35.12 | Ralith | if you come up with anything you'd like to delegate to me, just let me know |
| 10:36.10 | mafm | Ralith: I think that we need to talk more deeply soon |
| 10:36.25 | Ralith | alright |
| 10:36.32 | mafm | but this weekend I'm going to a festival and wouldn't return until tuesday or so :D |
| 10:36.36 | Ralith | :| |
| 10:36.47 | mafm | I really need a break |
| 10:36.51 | Ralith | kk |
| 10:36.53 | mafm | ;) |
| 10:36.57 | Ralith | you can always just write up something and email me |
| 10:37.05 | Ralith | I'm happy to work on whatever |
| 10:37.13 | mafm | yep, maybe I even join from my parent's home too :) |
| 10:37.21 | Ralith | kk |
| 10:37.28 | mafm | as for areas ready to work in, packaging is a good candidate |
| 10:37.32 | mafm | if you like that |
| 10:37.41 | Ralith | well |
| 10:37.44 | Ralith | not much I can do for that |
| 10:37.48 | Ralith | don't have linux boxes handy |
| 10:37.56 | Ralith | and screw setting up a win32 dev environment |
| 10:38.06 | CIA-23 | BRL-CAD: 03mafm * r32188 10/rt^3/trunk/src/g3d/GuiCamera.cxx: Showing the new icons |
| 10:38.18 | mafm | do you prefer programming? |
| 10:38.19 | Ralith | I'm pretty sure I can already throw together a BSD tarball on short notice |
| 10:38.29 | Ralith | of course I prefer programming :P |
| 10:38.46 | mafm | maybe you would like to take care of the camera system? |
| 10:39.10 | Ralith | that's fairly large, and I have no past experience with ogre or rbgui, but I'd love to give it a try |
| 10:39.26 | Ralith | what you have right now *should* be plenty to learn-by-example from |
| 10:39.30 | Ralith | thanks! |
| 10:39.34 | mafm | RBGui is not involved, except for the focusing maybe that you said :) |
| 10:39.49 | Ralith | well, and there are some settings I'd like to have exposed in a guifical way |
| 10:40.06 | mafm | like zooming in and rotating? |
| 10:40.18 | Ralith | actually not coming to mind at the moment |
| 10:40.36 | mafm | the current window that I'm creating is for that |
| 10:40.37 | Ralith | probably because it's 3:40 AM where I am |
| 10:40.38 | mafm | camera control :) |
| 10:40.46 | mafm | ok, so we'll talk in another moment |
| 10:40.49 | mafm | good night! :) |
| 10:40.49 | Ralith | yeah, that sounded relevant |
| 10:41.04 | Ralith | and things like precision position display/entry seem appropriate for the console |
| 10:41.21 | Ralith | maybe a small overlay text could show current az/el/etc? |
| 10:41.53 | Ralith | discussions to be had later I suppose. |
| 10:41.54 | Ralith | g'night! |
| 10:42.06 | mafm | I guess ;) |
| 10:57.16 | mafm | brlcad: getting more minions for the WDMP |
| 11:34.41 | CIA-23 | BRL-CAD: 03davidloman * r32189 10/rt^3/trunk/src/geometryService/java/stractNet/src/ (68 files in 15 dirs): |
| 11:37.17 | CIA-23 | BRL-CAD: 03davidloman * r32190 10/rt^3/trunk/src/geometryService/java/stractNet/ (.classpath .project): |
| 11:41.42 | CIA-23 | BRL-CAD: 03davidloman * r32191 10/rt^3/trunk/src/geometryService/java/stractNet/src/stractNet/SNRoot.java: Testing commit from windows |
| 11:46.25 | CIA-23 | BRL-CAD: 03davidloman * r32192 10/rt^3/trunk/src/geometryService/java/stractNet/docs/ (5 files): |
| 12:26.58 | CIA-23 | BRL-CAD: 03davidloman * r32193 10/rt^3/trunk/src/geometryService/java/stractThread/ (15 files in 4 dirs): |
| 12:27.17 | *** join/#brlcad thing0 (n=ric@124-169-162-93.dyn.iinet.net.au) | |
| 12:28.39 | CIA-23 | BRL-CAD: 03davidloman * r32194 10/rt^3/trunk/src/geometryService/java/stractThread/docs/: |
| 12:29.41 | CIA-23 | BRL-CAD: 03davidloman * r32195 10/rt^3/trunk/src/geometryService/java/stractNet/ (4 files in 2 dirs): |
| 13:03.27 | CIA-23 | BRL-CAD: 03davidloman * r32196 10/rt^3/trunk/src/geometryService/java/stractNet/src/stractNet/messaging/ (MessageDispatcher.java MessagingSystem.java): |
| 13:13.50 | CIA-23 | BRL-CAD: 03davidloman * r32197 10/rt^3/trunk/src/geometryService/java/stractNet/docs/stractNet.eap: |
| 13:30.17 | CIA-23 | BRL-CAD: 03mafm * r32198 10/rt^3/trunk/src/g3d/ (7 files): Enhancing camera modes by adding bindings for actions in the camera control window |
| 13:31.55 | CIA-23 | BRL-CAD: 03mafm * r32199 10/rt^3/trunk/src/g3d/ (GuiCamera.cxx GuiCamera.h): Bind actions in camera control window with camera modes |
| 13:39.15 | CIA-23 | BRL-CAD: 03davidloman * r32200 10/rt^3/trunk/src/geometryService/java/stractNet/docs/ (stractNet.eap stractNet.ldb): |
| 13:56.31 | *** join/#brlcad clock_ (n=clock@77-56-85-94.dclient.hispeed.ch) | |
| 14:13.15 | mafm | I go for the weekend, to my homeland |
| 14:13.28 | mafm | to a festival, to visit my parents, friends, etc |
| 14:13.58 | mafm | so I think that I won't be back until tuesday, in the case that somebody wonders why I won't be here |
| 14:50.01 | *** join/#brlcad clock__ (n=clock@77-56-85-94.dclient.hispeed.ch) | |
| 15:01.53 | starseeker | regains consciousness |
| 16:12.31 | starseeker | brlcad: Hmm - has the mged regression test ever been run in an out-of-tree build situation before? |
| 16:14.56 | starseeker | mged appears to have built and installed successfully, but the regress script couldn't find |
| 16:15.00 | starseeker | it |
| 16:17.00 | brlcad | ~wdmp |
| 16:17.35 | *** join/#brlcad elite01_ (n=elite01@unaffiliated/elite01) | |
| 16:17.37 | brlcad | starseeker: I don't think so |
| 16:18.11 | starseeker | wdmp? |
| 16:18.14 | brlcad | rather, "maybe" but it's not really critical .. it just needs to work for 'some' configuration |
| 16:18.22 | brlcad | 06:57 < mafm> brlcad: getting more minions for the WDMP |
| 16:18.30 | starseeker | ah :-) |
| 16:19.32 | brlcad | has no idea what that means :) |
| 16:44.11 | poolio | web development marketing and promotion? |
| 16:45.07 | CIA-23 | BRL-CAD: 03starseeker * r32201 10/brlcad/trunk/ (NEWS src/proc-db/tire.1 src/proc-db/tire.c): |
| 16:45.07 | CIA-23 | BRL-CAD: Add w option to tire to allow modelers to avoid wheel/rim generation (also |
| 16:45.07 | CIA-23 | BRL-CAD: changes how air region is built accordingly) - eventually this option will also |
| 16:45.07 | CIA-23 | BRL-CAD: be used to specify different wheel types but right now the only options are on |
| 16:45.07 | CIA-23 | BRL-CAD: and off. |
| 16:45.59 | CIA-23 | BRL-CAD: 03starseeker * r32202 10/brlcad/branches/pre-7-12-6/src/proc-db/ (tire.1 tire.c): Add tire updates from trunk r32201 |
| 17:12.39 | starseeker | grr |
| 17:12.40 | starseeker | make[2]: Entering directory `/home/cyapp/cadtoplevel/brlcad/release-build/misc/pkgconfig' |
| 17:12.44 | starseeker | make[2]: *** No rule to make target `liwdb.pc.in', needed by `distdir'. Stop. |
| 17:13.07 | brlcad | sup? |
| 17:13.14 | starseeker | make distcheck failed |
| 17:13.19 | starseeker | on the above problem |
| 17:13.21 | brlcad | you want to know the fix? |
| 17:13.21 | *** join/#brlcad jonored (n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net) | |
| 17:13.26 | starseeker | twood be nice |
| 17:13.30 | brlcad | tis a one-character typo |
| 17:13.35 | brlcad | libwdb |
| 17:13.53 | starseeker | turns mildly red |
| 17:14.01 | brlcad | so there's a liwdb.pc probably listed in configure.ac |
| 17:14.07 | poolio | starseeker: :) |
| 17:14.19 | brlcad | either there or in misc/pkgconfig/Makefile.am |
| 17:14.22 | poolio | brlcad: are you at your office? |
| 17:14.51 | brlcad | poolio: no, I'm not - sup? |
| 17:15.14 | poolio | was just wondering if you could send me some schtuff. maybe the next time your in, it's on the desktop as a .zip again |
| 17:15.31 | brlcad | ah, hold on |
| 17:15.48 | poolio | *you're. My grammar is terrible on IRC :\ |
| 17:15.57 | CIA-23 | BRL-CAD: 03starseeker * r32203 10/brlcad/branches/pre-7-12-6/misc/pkgconfig/Makefile.am: Oops, thanks Sean - typo in pkgconfig Makefile.am |
| 17:15.59 | starseeker | needs to get into the office, now that his brain has booted |
| 17:16.30 | starseeker | must have introduced that himself when he removed libpc |
| 17:16.31 | starseeker | gah |
| 17:17.21 | starseeker | Oh well, at least I won't have to hear complaints about how hard it is to remove rims from a tire generated wheel :-) |
| 17:17.22 | brlcad | poolio: yeah, I gather it's off the net .. I should have it later today |
| 17:17.48 | brlcad | starseeker: nah, I think that was there and later fixed |
| 17:17.53 | poolio | alrighty. no rush, I just wanted to get some work in this weekend before I head off |
| 17:17.57 | brlcad | so you're just a couple revisions shy |
| 17:18.13 | starseeker | <snort> and after all that rev by rev updating too... |
| 17:20.39 | starseeker | /bin/sh ../pre-7-12-6/sh/cmakecheck.sh |
| 17:20.39 | starseeker | ERROR: cannot find src/libbn/CMakeLists.txt |
| 17:20.51 | starseeker | oh, cmakecheck.sh |
| 17:20.55 | starseeker | I hadn't tested it |
| 17:21.01 | starseeker | certainly not out of source |
| 17:22.07 | brlcad | yeah, it assumes pwd is a specific place |
| 17:22.23 | starseeker | notices - so make distcheck should be run only in-tree? |
| 17:22.37 | starseeker | gah, my CMakeLists are way out of sync |
| 17:26.05 | CIA-23 | BRL-CAD: 03starseeker * r32204 10/brlcad/branches/pre-7-12-6/src/ (3 files in 3 dirs): Update cmake lists to avoid MISSING errors in cmakecheck.sh, should check that they really do match source trees |
| 17:26.36 | CIA-23 | BRL-CAD: 03brlcad * r32205 10/brlcad/trunk/Makefile.am: make the cmake distcheck check work out of dir (untested) |
| 17:26.57 | starseeker | :-) |
| 17:27.11 | starseeker | can you do the mged regress script to? :-) :-) |
| 17:29.13 | brlcad | it's not the only one, most of them aren't set up for it |
| 17:29.37 | starseeker | OK, nevermind - I'll reconfigure |
| 17:31.00 | brlcad | what's the actual error? |
| 17:31.12 | brlcad | if you run "make mged" in the regress dir? |
| 17:32.21 | starseeker | I think it couldn't find mged, i'll run it as sone as autoconf shuts up... |
| 17:32.49 | starseeker | Unable to find mged, aborting |
| 17:32.49 | starseeker | make: [mged] Error 1 (ignored) |
| 17:40.58 | CIA-23 | BRL-CAD: 03brlcad * r32206 10/brlcad/trunk/regress/ (8 files): go an extra mile to find mged and set up paths properly regardless of the compile being in or out of dir -- untested and there are undoubtedly other commands, but it's one step |
| 17:44.09 | starseeker | brlcad: that dir command doesn't work in Makefile.am - tries to change to directory "ir" |
| 17:44.40 | starseeker | I think you want something like currdir="`pwd`" ; cd $(top_srcdir) && ${SH} $(top_srcdir)/sh/cmakecheck.sh ; cd $(currdir) |
| 17:45.25 | starseeker | aaah, crud |
| 17:45.41 | starseeker | messes up his out of source build by configuring for an in-source one |
| 17:46.02 | starseeker | OK, I've got to get in there - this is looking good though :-) |
| 17:46.32 | starseeker | brlcad: Didn't mean to pull you off your other stuff, I know this is supposed to by my baby right now :-/ |
| 17:52.17 | CIA-23 | BRL-CAD: 03brlcad * r32207 10/brlcad/trunk/Makefile.am: oops, it's a shell var |
| 17:52.44 | brlcad | you have to escape the $ since it's a shell var, not a makefile var |
| 18:12.29 | *** join/#brlcad thing0 (n=ric@124-169-162-93.dyn.iinet.net.au) | |
| 19:15.26 | *** join/#brlcad Ralith (n=ralith@c-71-197-213-172.hsd1.or.comcast.net) | |
| 20:02.44 | *** join/#brlcad cad75 (n=584adef1@bz.bzflag.bz) | |
| 20:26.28 | CIA-23 | BRL-CAD: 03homovulgaris * r32208 10/brlcad/trunk/src/libpc/ (TODO pcNetwork.h pcPCSet.h solver_test.cpp): code rearrangement, addition of BinaryNetwork(PCSet &) constructor skeleton. seems like BinaryNetwork needs to be de-templated as well |
| 20:31.14 | *** join/#brlcad ibot (i=ibot@pdpc/supporter/active/TimRiker/bot/apt) | |
| 20:31.14 | *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Channel logs at http://ibot.rikers.org/%23brlcad/ || BRL-CAD is participating in the 2008 Google Summer of Code! || Release 7.12.4 is posted (source-only release) | |
| 20:51.10 | CIA-23 | BRL-CAD: 03homovulgaris * r32209 10/brlcad/trunk/src/libpc/ (TODO pcNetwork.h solver_test.cpp): BinaryNetwork generation from PCSet complete.. implicit assumption that all the variables are of the same type dut to BinaryNetwork<T> |
| 21:09.26 | CIA-23 | BRL-CAD: 03homovulgaris * r32210 10/brlcad/trunk/src/libpc/ (TODO pcConstraint.cpp pcConstraint.h pcNetwork.h): renaming evaluating functor of a constraint to eval from funct, making the Variable list of constraint object private for encapsulation |
| 22:09.50 | *** join/#brlcad andrecastelo_ (n=chatzill@189.71.12.47) | |
| 22:26.47 | CIA-23 | BRL-CAD: 03starseeker * r32211 10/brlcad/branches/pre-7-12-6/ (9 files in 2 dirs): Update r32205, r32206 - steps towards out-of-tree regression testing. |
| 22:38.59 | starseeker | well, out-of-tree still doesn't seem mged but in-tree make distcheck seems to be succeeding. |
| 22:40.52 | Ralith | was a workaround going to be implemented for the driver issues I hit, or are we going to rely on ports to disable opengl at the configure stage? |
| 22:47.06 | starseeker | Probably the latter at the moment :-( |
| 22:47.49 | Ralith | nothing new as far as ports is concerned |
| 22:48.05 | Ralith | who's "erik@smluc.org"? |
| 22:48.11 | *** join/#brlcad Elperion (n=Bary@p5B14E667.dip.t-dialin.net) | |
| 22:48.26 | Ralith | (he's listed as the port maintainer) |
| 22:49.30 | Ralith | if this problem is common on nvidia/freebsd it would be bad to make a release without the workaround |
| 22:55.32 | starseeker | I believe it's ``Erik here |
| 22:55.43 | starseeker | the workaround may take weeks |
| 22:55.52 | starseeker | I have no idea how hard it would be |
| 22:56.39 | starseeker | someone with more knowledge of that part of the system might be able to track it down faster, but I don't have the expert knowledge yet :-/ |
| 22:57.03 | starseeker | would have a lot of learning to do just to get started :-( |
| 22:57.37 | Ralith | starseeker: uh, the workaround is disabling opengl :P |
| 22:57.51 | Ralith | you're thinking of the fix. |
| 22:57.55 | starseeker | Oh, gotcha |
| 22:58.05 | Ralith | ``Erik: you around? |
| 22:58.21 | starseeker | the fix is to get BSD's drivers fixed ;-) |
| 22:59.37 | Ralith | yeah, good luck convincing nvidia to do something about that. |
| 22:59.48 | starseeker | indeed :/ |
| 23:00.02 | starseeker | YAY make distcheck succeeded |
| 23:02.28 | Ralith | :D |
| 23:02.30 | starseeker | ``Erik may pop in later |
| 23:05.07 | Ralith | so long as later is before he puts up the port. |
| 23:08.35 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 23:33.59 | *** join/#brlcad andrecastelo__ (n=chatzill@189.71.23.224) | |