| 00:02.02 | mafm | lol :) |
| 00:02.04 | mafm | hi andrecastelo |
| 00:02.24 | mafm | in my case, it's because many ppl take advantage at distance learning just for fun |
| 00:02.48 | mafm | or, in the case of businessman or polititians, to get a degree as lawyers or so |
| 00:03.23 | mafm | so half of ppl is more or less young ppl as in other unis, specially for engineerings as me |
| 00:03.35 | mafm | but other ppl are of old age |
| 00:04.07 | mafm | there are even programs for inmates in prisons, and ppl working abroad in different places of Europe and America |
| 00:04.12 | mafm | it's funny :) |
| 00:09.10 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-64.sbndin.btas.verizon.net) | |
| 00:12.13 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) | |
| 00:13.50 | andrecastelo | hi brlcad, mafm :D |
| 00:15.13 | mafm | andrecastelo: applying for gsoc? |
| 00:28.40 | CIA-40 | BRL-CAD: 03Sean 07http://brlcad.org * r1318 10/wiki/Google_Summer_of_Code/Checklist: expand the checklist into four main sections, one during the application period, then before coding begins, and then while coding, then after it's all done |
| 00:30.02 | Ralith | yay! |
| 00:32.55 | andrecastelo | mafm: nope :( |
| 00:33.00 | andrecastelo | mafm: you? |
| 00:33.28 | madant | took 23:30 :| |
| 00:34.48 | mafm | andrecastelo: not sure yet, and not sure if as mentor or student... still checking project ideas and so on, and thinking about my future |
| 00:34.52 | mafm | andrecastelo: why not? |
| 00:35.19 | madant | howdy castelo ;) |
| 00:35.21 | mafm | madant: you need to drink more tea :P |
| 00:35.34 | madant | is a coffee person |
| 00:35.46 | madant | where is pacman87 :) that would make it a perfect reunion :) |
| 00:35.59 | pacman87 | right here :D |
| 00:36.12 | madant | andrecastelo: thinking about future is never easy i guess |
| 00:36.18 | mafm | madant: heretic! |
| 00:36.23 | madant | pacman87: yay :P |
| 00:36.30 | mafm | I love coffee too, too much :( |
| 00:36.50 | madant | why the sad face . coffee is life :) |
| 00:36.56 | madant | pacman87: how is school . |
| 00:37.22 | andrecastelo | madant: true, perfect reunion :) |
| 00:38.14 | brlcad | hehe |
| 00:38.14 | madant | and did something happen in the direction of the clustering discussion |
| 00:38.14 | pacman87 | madant: busy. i'm working on making tetris with a 6811, and writing a darknet F2F client |
| 00:38.14 | mafm | madant: because I can't drink as much as I would like |
| 00:38.42 | pacman87 | madant: i think the clustering discussion was more an idea-gathering than a decide-something |
| 00:39.00 | yukonbob | hello, cadheads |
| 00:39.50 | madant | pacman87: 6811 sounds kewl.. :) |
| 00:40.32 | pacman87 | 512 B ram, 512 B rom |
| 00:40.53 | madant | haha .. and a lot of tinkering around ;) |
| 00:40.53 | pacman87 | we're interfacing external eeprom using the address/data bus |
| 00:41.10 | madant | ah it is like a project or a competition ? |
| 00:41.16 | pacman87 | a bit of both |
| 00:41.22 | pacman87 | it's for class |
| 00:41.26 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |
| 00:41.30 | pacman87 | and there's a competition at the end |
| 00:41.31 | madant | whats the F2F client for |
| 00:41.40 | pacman87 | concurrent and distributed systems programming |
| 00:41.53 | pacman87 | it's a 'chose your own project' |
| 00:41.56 | brlcad | the 6811 is actually faster than the first hardware that ran brl-cad .. memory not far off too |
| 00:42.15 | brlcad | it was just bigger than a refrigerator back then |
| 00:42.19 | madant | brlcad: what was that monster :D |
| 00:42.27 | ``Erik | hrm, pdp11/70? |
| 00:43.26 | pacman87 | i want to find a graphics LCD panel that i can interface directly to the display RAM from the address/data bus |
| 00:43.34 | pacman87 | memory-mapped IO style |
| 00:43.43 | pacman87 | but i haven't found any drivers that do that yet |
| 00:44.38 | ``Erik | there'll still have to be some kinda controller in the mix to translate, pacman :/ lcd's and memory work a bit differently |
| 00:45.12 | ``Erik | probably be easier to just glue i2c components together or somethin' |
| 00:45.22 | madant | has always wondered whether higher polyomino games would be nice |
| 00:45.58 | pacman87 | ``Erik: yeah, i know; i'm looking for a controller that will let me talk to the display ram, and the controller syncs the display ram with the LCD panel |
| 00:45.59 | ``Erik | (6811 or 6812? I thought motorola discontinued 6811's in favor of 6812's a long time ago, a 6812 can run 6811 code 'and then some') |
| 00:46.38 | ``Erik | <-- did some assembly and low level C on both those chips back in college :) fun stuff |
| 00:46.47 | pacman87 | 6811. we use the 6812 for most of the stuff we do, but the point of this is to do external memory |
| 00:47.29 | ``Erik | hm, I thought you could get 6812's with no internal memory |
| 00:48.04 | ``Erik | has been tempted to figure out how to get his pics talking to old simm ram |
| 00:48.07 | pacman87 | it's also possible that UT has some big stock of 6811s from before they stopped making them |
| 00:48.39 | pacman87 | and our 6812s are on dev boards with serial monitors to program them |
| 00:51.30 | ``Erik | of course, I've also been tempted to buy a 68040 and build an old school unix box out of it, I seem to get tempted an awful lot and act an awful little ;) |
| 00:53.44 | *** join/#brlcad Lezard (n=lezardfl@189.58.209.20.dynamic.adsl.gvt.net.br) | |
| 01:02.11 | mafm | night, folks :) |
| 01:03.30 | Lezard | well i`m interested in one of the project ideas, could you guys give me more information in the MGED User Interface Improvements project? |
| 01:04.44 | brlcad | Lezard: thanks, that helps :) |
| 01:05.03 | brlcad | so our main modeler right now is called MGED |
| 01:05.42 | brlcad | it's actually probably best explained by just running it -- it's not easy to learn, not easy interface to discvoer |
| 01:06.14 | brlcad | basically, if you look at the screenshots on http://brlcad.org/gallery/ under the screenshots section, you'll see various pictures of it running |
| 01:06.37 | brlcad | meant here |
| 01:07.15 | Lezard | looking at the screenshots |
| 01:07.37 | Lezard | well... i really agree that you need a more friendly interface, at least from what i see with the screenshots |
| 01:09.27 | brlcad | the interface is being overhauled completely |
| 01:09.39 | brlcad | that has been in the works for a while and was a gsoc project last year |
| 01:09.47 | Lezard | hmm |
| 01:09.51 | brlcad | but in the meantime, mged can and should still be made easier to use |
| 01:09.51 | Lezard | did anyone apply? |
| 01:10.14 | brlcad | just one person has applied to continue that project again this year thusfar |
| 01:10.31 | Ralith | waves |
| 01:10.37 | Lezard | hello Ralith o/ |
| 01:10.41 | Ralith | hullo |
| 01:11.04 | Lezard | My main problem is that i`m not a Tcl/Tk expert... |
| 01:11.19 | Ralith | I'm sure it's not hard to learn |
| 01:11.29 | Lezard | I`m a researcher in my university in the HCI lab |
| 01:11.32 | brlcad | Lezard: mged is about 1/3rd tcl/tk and about 2/3rds C |
| 01:11.55 | Lezard | so i got kinda interested in the project, after all i could test my skills |
| 01:11.56 | brlcad | so much of what can be done to make it easier to use can be done on the C side |
| 01:12.09 | *** join/#brlcad objorn (n=safar@unaffiliated/objorn) | |
| 01:12.22 | brlcad | like better introspection, help system, cleaned up command layer, etc |
| 01:12.42 | brlcad | the gui aspects are tcl/tk though -- the new system is where that changes it up to C/C++ |
| 01:13.09 | Lezard | well i`m more interested in the gui aspects |
| 01:13.20 | brlcad | having someone with HCI experience take a hack at mged would be phenomenal -- you'd have a pretty big opportunity to make a big impact |
| 01:13.45 | brlcad | there are something on the order of 200k downloads a year, about 20k a month that would benefit from better usability ;) |
| 01:14.06 | Ralith | I'd also love to have your input on my work on the new system, if I get accepted |
| 01:14.40 | brlcad | yeah, there's the guy that has that application in for continuing last year's work thusfar ;) |
| 01:15.17 | Lezard | so you think that even if my Tcl/Tk skills aren`t very advanced, i should apply ? |
| 01:15.23 | objorn | where are the 32bit builds? |
| 01:15.26 | brlcad | starseeker: you know any word about whether weiss is working on fixing it? |
| 01:15.38 | brlcad | objorn: for binary builds, you have to go back a few releases |
| 01:15.41 | objorn | i only see 64bit http://sourceforge.net/project/showfiles.php?group_id=105292&package_id=113559 |
| 01:15.45 | objorn | okay |
| 01:15.45 | Ralith | Lezard: certainly; GSoC's all about learning. |
| 01:16.05 | brlcad | generally recommend just building the latest from source regardless if you can |
| 01:16.06 | Ralith | Lezard: of course, you might want to look over some docs on it beforehand so you have some idea what you're getting into |
| 01:16.28 | brlcad | Lezard: what languages would you say you know pretty well? |
| 01:16.59 | brlcad | tcl/tk is a frustrating blessing .. sometimes great to work with and sometimes makes you go looking for a shotgun |
| 01:17.13 | Lezard | well, i`m confident in my php and pascal, my C is about average |
| 01:17.26 | Lezard | as my python |
| 01:17.36 | brlcad | tcl's not "too" dissimilar from php |
| 01:18.12 | madant | Lezard: php and pascal , interesting combination |
| 01:18.18 | brlcad | the syntax is definitely different, check out http://www.tcl.tk/about/language.html |
| 01:18.43 | madant | Lezard: what do / did u do in pascal ? |
| 01:21.15 | *** join/#brlcad typ0 (n=coder@um-sd06-125-2.uni-mb.si) | |
| 01:22.30 | Lezard | madant: Well, last thing i did in pascal was a program to manage a store |
| 01:22.31 | brlcad | typ0: so the iges converter.. have you worked with iges before? |
| 01:22.44 | Lezard | nothing too complicated i guess... |
| 01:22.58 | brlcad | typ0: http://en.wikipedia.org/wiki/IGES has a link to the spec iirc |
| 01:23.04 | typ0 | thanks |
| 01:23.08 | typ0 | didn't work with it before |
| 01:23.28 | typ0 | but i can use the student bonding period to study the current converter source code |
| 01:23.34 | madant | Lezard: hehe.. not at all. I was just asking since pascal is a relatively uncommon language skill ;) |
| 01:23.34 | typ0 | and familiarize myself with the format |
| 01:23.42 | Lezard | sorry if i took a long time to answer, i`m doing the laundry |
| 01:23.52 | Lezard | well, yeah, i learned it in my last university... |
| 01:24.24 | Lezard | used it for some programs in class, and to code that managing program to a friend |
| 01:24.47 | brlcad | madant: actually I think it's pretty common (for some of us older folk) .. just not one many will admit to knowing/using ;) |
| 01:24.56 | brlcad | often an "intro to programming" language ;) |
| 01:25.12 | Lezard | Agreed |
| 01:25.27 | Lezard | I know other languages as well, but it has been sometime since i code... |
| 01:25.28 | madant | brlcad: :) yeah i remember a friend of mine having to deal with pascal for some algorithms which were written a decade ago :) |
| 01:25.37 | madant | er .. make it two decades ago :) |
| 01:26.03 | Lezard | But i know that at least my algorithms logic is still fine... at least was last year in the Coding Arena... |
| 01:26.06 | madant | I hear it is pretty good for mathematical stuff / |
| 01:26.08 | madant | ? |
| 01:26.08 | Lezard | were |
| 01:28.12 | *** join/#brlcad deeeffache (n=deeeffac@adsl-99-145-15-192.dsl.emhril.sbcglobal.net) | |
| 01:28.17 | madant | had an introduction to computers in LOGO |
| 01:29.05 | Lezard | Man, i should be sleeping |
| 01:29.13 | Lezard | its going to be a long night |
| 01:29.36 | madant | Lezard: gn, do come back if u need any help regarding brl-cad |
| 01:30.00 | Lezard | I`m not goint to sleep, i need to finish some stuff for my class tomorrow |
| 01:30.04 | brlcad | Lezard: a little piece of you dies every time you sleep! |
| 01:30.19 | Lezard | agreed |
| 01:30.22 | madant | agrees with this philosophy of brlcad's :P |
| 01:30.23 | brlcad | thinks that will be one of his new phrases worth repeating ad infitum |
| 01:30.48 | brlcad | hello deeeffache |
| 01:30.58 | deeeffache | hola |
| 01:31.28 | brlcad | g'dammits .. cruise control is stuck again |
| 01:32.50 | Ralith | madant: what're you applying for, again? |
| 01:33.32 | madant | Ralith: further work in libpc :) http://brlcad.org/wiki/User:Homovulgaris |
| 01:33.55 | Ralith | oo, that stuff! |
| 01:33.56 | Ralith | awesome! |
| 01:33.57 | Ralith | :D |
| 01:34.46 | madant | i think the gui will be more visually appealing not to mention awesome :) |
| 01:34.53 | Ralith | is looking forward to having that working |
| 01:35.10 | Ralith | eh, the GUI's worthless without a powerful backend |
| 01:35.33 | Ralith | it's just there to hold people's attention long enough to become comfortable with the package |
| 01:35.34 | madant | Ralith: which univ do u go to ? |
| 01:35.59 | Ralith | not actually in univ yet; turns out SoC lets you in if you've got an acceptance letter. |
| 01:36.25 | ``Erik | *readreadread* pascal pascal, or delphi? |
| 01:36.42 | Ralith | I do look forward to making a shiny and usable GUI, but the GUI is an enabler |
| 01:37.07 | Ralith | the point of BRL-CAD is, after all, not just to model things. |
| 01:37.16 | brlcad | visually appealing AND awesome |
| 01:37.22 | Ralith | hehe |
| 01:37.26 | brlcad | we could just name the binary "awesome" |
| 01:37.36 | Ralith | isn't there already a window manager called that? |
| 01:37.42 | brlcad | ah, yeah, probably ;) |
| 01:37.46 | ``Erik | teh-awesom3z.7.14.4.tar.bz2 |
| 01:38.18 | Ralith | aw3d. Reads as 'awed' |
| 01:38.29 | Lezard | brb |
| 01:38.33 | Lezard | going to cook my dinner |
| 01:38.37 | brlcad | yeah, actually 'awesome' wm has a lot of the same usability considerations as the new gui |
| 01:38.45 | Ralith | hehe |
| 01:39.02 | brlcad | similar HCI backings |
| 01:39.08 | Ralith | I guess that kind of design is just inherently awesome. |
| 01:43.33 | brlcad | has the munchies |
| 01:44.03 | brlcad | debates hitting up the bar down the street for some satisfaction |
| 01:49.03 | brlcad | non-overlapping windows, everything can be performed with a keyboard, swappable contexts/tabs/tiles, automatic default unobscured layout arrangement, .. |
| 01:49.13 | brlcad | reminding himself out loud |
| 02:00.24 | brlcad | starseeker: yeah, saw the start of that :) pretty cool |
| 02:00.34 | brlcad | starseeker: so was reading your brep notes |
| 02:00.44 | brlcad | heh, gmta |
| 02:02.44 | yukonbob | http://pastebin.ca/1377525 |
| 02:03.02 | brlcad | howdy yukonbob |
| 02:03.05 | yukonbob | :) |
| 02:03.26 | brlcad | yukonbob: er.. you're running autoconf there |
| 02:03.27 | yukonbob | Noteable for above paste: NetBSD 5_RC3, pkgsrc. |
| 02:03.31 | brlcad | that won't work |
| 02:03.38 | brlcad | needs to be the full toolchain |
| 02:03.41 | brlcad | ./autogen.sh |
| 02:03.45 | yukonbob | nods |
| 02:03.49 | yukonbob | will continue from there :) |
| 02:04.07 | brlcad | more specifically, if you want to do it manually, you're missing aclocal |
| 02:04.26 | brlcad | there's a comment in autogen.sh some ways down that describes the manual steps |
| 02:04.36 | brlcad | lists them out |
| 02:04.52 | brlcad | autoreconf should do the trick too with the right options |
| 02:05.26 | yukonbob | will poll the tools; thx for the directional hint |
| 02:06.29 | brlcad | any reason you're not running autogen.sh ? |
| 02:07.01 | yukonbob | brlcad: is wrapped in old(er) config I had for pkgsrc... need to give it some hints. |
| 02:07.29 | brlcad | hm? |
| 02:07.49 | brlcad | ah, you mean you have a pkgsrc target that is set up to run autoconf directly like that? |
| 02:07.55 | yukonbob | yup :) |
| 02:08.00 | brlcad | that shouldn't have ever worked... |
| 02:08.03 | yukonbob | I'll give it more specific hints... |
| 02:08.23 | brlcad | maybe from a source checkout after aclocal had already ran |
| 02:08.38 | brlcad | er, s/checkout/tarball/ |
| 02:08.50 | brlcad | but still.. unusual |
| 02:08.52 | yukonbob | brlcad: good guess... |
| 02:09.41 | yukonbob | I've certainly had the whole affair successfully wrapped in pkgsrc before, including ripping out all in-tree options like Tcl, ITcl, Tk, various gfx libs, etc., etc. |
| 02:10.07 | yukonbob | just working on re-implementing with "modern" co |
| 02:10.14 | brlcad | should be running either "autoreconf -i -f -I m4" or autogen.sh |
| 02:10.14 | yukonbob | s/co/checkout/ |
| 02:10.19 | yukonbob | nods |
| 02:10.36 | yukonbob | will retry l8r tonight... |
| 02:10.40 | brlcad | ideally the latter so we can control it ;) |
| 02:10.52 | yukonbob | noted |
| 02:10.59 | yukonbob | gets kicked out of cafe... |
| 02:11.06 | brlcad | oh noes! |
| 02:11.11 | yukonbob | :) |
| 02:11.12 | brlcad | ze coffeee! |
| 02:11.19 | yukonbob | chat later, brl-nerds |
| 02:11.24 | brlcad | cya geek |
| 02:16.16 | *** join/#brlcad typ0_ (n=coder@um-sd06-125-2.uni-mb.si) | |
| 02:19.20 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-64.sbndin.btas.verizon.net) | |
| 02:48.11 | objorn | brl-cad is simply 400 applications... |
| 02:49.13 | objorn | -simply |
| 02:49.17 | objorn | i did not realize this |
| 02:49.30 | objorn | now i'm looking at the wiki trying to figure out how to use it |
| 02:51.33 | objorn | ah, mged |
| 02:51.49 | objorn | brlcad/bin$ ./mged |
| 02:51.51 | objorn | ./mged: error while loading shared libraries: libtermio.so.19: cannot open shared object file: No such file or directory |
| 02:52.24 | objorn | i downloaded the packages and haven't done ./configure, make, or make install |
| 02:52.44 | objorn | but i also can't find autogen.sh using find . -name autogen.sh |
| 02:53.13 | objorn | in the brlcad folder |
| 03:04.49 | brlcad | huh, objorn where'd you get a source tarball from? |
| 03:05.37 | objorn | i'm guessing it's binary |
| 03:05.48 | objorn | i got the install instructions confuesed |
| 03:06.33 | starseeker | brlcad: here's the ascii art in the TODO.BREP taken a bit further: http://bzflag.bz/~starseeker/points.pdf |
| 03:06.38 | objorn | so putting brlcad/ in /usr will solve the problem? |
| 03:06.54 | objorn | is highly considering just downloading from source |
| 03:06.56 | brlcad | yeah |
| 03:07.12 | brlcad | if this is for gsoc, you should start from a source chekcout |
| 03:07.44 | objorn | it's for my own interest |
| 03:08.21 | objorn | i have a feeling i will being needing to use it in about a year so i should become familiar now |
| 03:09.02 | brlcad | ok, cool |
| 03:34.25 | Ralith | starseeker: what is that, and why does it make xpdf lock up? |
| 03:43.59 | brlcad | starseeker: what's missing from that art is the sample determination |
| 03:45.09 | brlcad | Ralith: something about how it's encoded.. massively eating up cpu here |
| 03:45.29 | brlcad | it's just a bunch of simple lines, but something wrong with the pdf |
| 03:45.54 | Ralith | doesn't even eat much CPU here |
| 03:45.56 | Ralith | just locks |
| 03:47.06 | pacman87 | it was taking up all of one core for me |
| 03:47.38 | pacman87 | i gave up and closed it |
| 03:49.36 | brlcad | re-encodes it |
| 03:50.16 | brlcad | http://bzflag.bz/~sean/points.pdf |
| 03:52.12 | brlcad | few cases not missing, not that it matters -- the three-case can be considered to cover all possibilities pair-wise if you treat one of them, say C, as being the test sample (just that several options become invalid samples) |
| 03:55.32 | brlcad | also not clear that the representative shape is accurate -- they end up being distance checks with a tolerance so those should be spheres of uncertainty |
| 03:55.52 | brlcad | for computational reasons as well as just not inducing an aliasing bias |
| 03:57.25 | brlcad | it'd be square/rectangular if the comparisons were done per coordinate component individually but they're not (intentionally) as it would introduce an artificial shape factor (and be more book-keeping) |
| 03:57.38 | brlcad | interesting idea, though, for certain |
| 03:57.47 | brlcad | and assuming I'm just not missing something |
| 04:02.12 | *** join/#brlcad dreeves (n=IceChat7@67.130.253.14) | |
| 04:05.49 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) | |
| 04:38.34 | starseeker | brlcad: I doubt you are |
| 04:38.34 | starseeker | I thought the comparisons would be done per component, but if not then yes it would be spheres |
| 04:38.50 | brlcad | yeah, nah -- they are point-point distances |
| 04:39.15 | starseeker | it doesn't actually matter too much - I just need to re-draw the cases with spheres |
| 04:39.22 | starseeker | might eliminate a few, not sure |
| 04:39.35 | brlcad | doing it per component is smaller, but a biased shape |
| 04:39.53 | brlcad | don't redraw, it gets the point across |
| 04:40.02 | brlcad | no pun intended |
| 04:40.05 | starseeker | heh |
| 04:40.13 | starseeker | scolds inkscape for doing such a sucky pdf |
| 04:40.28 | brlcad | looks like they use cairo |
| 04:40.34 | starseeker | yeah |
| 04:40.34 | brlcad | so might be cairos fault for the crap |
| 04:40.46 | brlcad | either way, something really wrong with it :) |
| 04:40.55 | starseeker | I wondered why it rendered so slow |
| 04:42.03 | starseeker | heh - spheres would actually mean circles, and that would (probably) make it proper Venn diagrams after all :-) |
| 04:42.20 | brlcad | so the trick with the tests are all mostly just a matter of accumulated error tracking with a given comparison tolerance |
| 04:43.17 | starseeker | well, unless we need to decide which points with overlapping error bounds to regard as the same - that's where it gets iffy |
| 04:43.42 | brlcad | another way to think of why boxes would be an issue is the effect it would cause on a point-collapse operation |
| 04:43.59 | brlcad | the direction of approach between two points would actually affect their collapse |
| 04:44.07 | brlcad | you want it direction invariant |
| 04:44.15 | starseeker | true. |
| 04:44.36 | starseeker | I was assuming we were constrained by the realities of xyz 3d point storage |
| 04:45.07 | brlcad | nah, because we do actual distance calcs between the points |
| 04:45.19 | starseeker | what did you have in mind for a collapsing algorithm? |
| 04:45.31 | starseeker | nearest point with overlapping error bounds? |
| 04:45.31 | brlcad | DIST_PT_PT() in vmath, for example |
| 04:46.00 | brlcad | well naive first implementation, yes, but that's a very dumb clustering technique that will have problems |
| 04:46.06 | starseeker | agreed |
| 04:46.21 | starseeker | my second pass was largest shared error bound volume |
| 04:46.45 | starseeker | but that also seems to have some weaknesses |
| 04:47.10 | starseeker | I was trying to find papers on techniques earlier today (should be in the scrollback, come to think of it) |
| 04:47.13 | brlcad | basically if you have two points A and B that are near each other within the distance tolerance, there's an entire ellipsoid where they are within tolerance |
| 04:47.34 | brlcad | and conceivably, any value in there would suffice as a solution |
| 04:47.53 | starseeker | for free points in space, that might do |
| 04:47.56 | brlcad | picking A or B is usually the case, but that's actually on the surface of the ellipsoid instead of some mean/average/inner point |
| 04:48.06 | starseeker | I'm worried about things like the vertex of an arb8 though |
| 04:48.20 | brlcad | picking anything *other* than A or B, though, is changing your inputs and can cause cascade failures |
| 04:48.32 | brlcad | or accumulated error |
| 04:48.37 | starseeker | what about three points with one being overlapped by the other two but the other two mutually exclusive? |
| 04:49.12 | starseeker | and so on... n points means a lot of those sorts of possibilities |
| 04:49.28 | brlcad | yeah, that's the point drift problem |
| 04:49.53 | brlcad | A and B are within tol, B and C within tol, but not A and C .. so what happens |
| 04:50.01 | starseeker | exactly |
| 04:50.11 | brlcad | you make a decision and that can cascade a failure |
| 04:50.28 | starseeker | as near as I can tell you have to pick one and say the other one is a no-go, unless you have something better <hopes> |
| 04:50.55 | brlcad | what you suggest is basically what nmg code does now |
| 04:51.02 | starseeker | winces |
| 04:51.15 | starseeker | ouch |
| 04:52.42 | starseeker | uncle - what's the better solution? |
| 04:52.45 | brlcad | it makes a decision on the first comparison A<>B and clamps B to A if within tol to maintain data integrity, then comparing C, determines it's outside bounds and rejects it |
| 04:53.07 | brlcad | or determines it's within and clamps to A as well, etc |
| 04:54.17 | starseeker | what bounds is it comparing C to? B and C shouldn't both be clamped to A, correct? |
| 04:54.38 | brlcad | okay, so there are a couple things that we can try, but not making promises that we'll actually solve it for all conditions .. garbage in will result in garbabe out |
| 04:54.57 | brlcad | it really depends on what the algorithm is attempting to accomplish |
| 04:55.29 | brlcad | it was comparing C to the same distance tolerance, A<>C |
| 04:55.58 | starseeker | so B and C WOULD end up the same point after clamping? |
| 04:56.16 | brlcad | all three at A or C rejected |
| 04:56.32 | brlcad | that's just explaining basically what it presently does |
| 04:56.40 | brlcad | oversimplified |
| 04:56.47 | starseeker | nods |
| 04:57.08 | brlcad | where it really fails, though, is that it doesn't know it clamped B to A |
| 04:57.19 | starseeker | blinks |
| 04:57.43 | starseeker | yeah, that could be a problem |
| 04:57.43 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) | |
| 04:57.48 | brlcad | topologically, it may have been the actual case that B<>C was the right two to combine and A was just something close by |
| 04:58.02 | brlcad | and had the order of operations even changed, it would have worked out correct |
| 04:59.07 | brlcad | jeez, eva mendes is smokin' |
| 04:59.25 | brlcad | anyways |
| 04:59.35 | brlcad | so the idea is that we have to track the decision |
| 04:59.45 | objorn | i want to enable opengl support, yes? |
| 04:59.55 | brlcad | objorn: no, not necessary |
| 05:00.11 | objorn | what's the benefit of using it? |
| 05:00.12 | brlcad | doesn't affect anything to disable/enable it -- it'll use X11 routines |
| 05:00.26 | starseeker | archer needs ogl, I think that's about it |
| 05:00.29 | brlcad | it's just what underlying protocol does it speak, doesn't actually change what features are provided |
| 05:00.35 | brlcad | doesn't give you shaded displays, for example |
| 05:00.56 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 05:00.59 | starseeker | actually, at present archer doesn't seem to display anything without ogl... |
| 05:01.05 | objorn | how do you enable it through configure? ./configure USE=opengl |
| 05:01.08 | objorn | :P |
| 05:01.18 | objorn | seriously though, i'm not sure |
| 05:01.23 | starseeker | ./configure --help |
| 05:01.27 | objorn | thanks |
| 05:02.24 | starseeker | brlcad: is tracking the decision O(n^2) or worse? |
| 05:02.53 | brlcad | starseeker: so to track the decision, the simplest way is to simply take the average of the two points and track the error volume |
| 05:04.36 | objorn | ./configure --enable-OpenGL[=yes] |
| 05:04.38 | objorn | ? |
| 05:05.13 | starseeker | --with-ogl |
| 05:05.31 | objorn | thank you starseeker |
| 05:05.47 | brlcad | so with A<>B, it determines they're within tol, giving a resulting AB point (call it D) and the maximal error of that point (which after the first comparison is just the tolerance) .. then compares D using that error against C with the starting tolerance, resulting in a DC point, call it E |
| 05:06.23 | starseeker | ok |
| 05:06.46 | brlcad | E's error is possibly going to be bigger than D's, error is accumulating as more points are combined |
| 05:06.51 | starseeker | do we then check B and C for distance from E? |
| 05:07.16 | brlcad | so if you had a string of points within tolerance, they can actually all collapse with a resulting large error bounds |
| 05:07.22 | starseeker | right |
| 05:07.41 | starseeker | in the worst case, we go from a long line of points to one point with a huge error bound? |
| 05:07.45 | brlcad | but it's kept track of that error and theoretically, nothing will be left out |
| 05:07.50 | brlcad | just possibly too much brought in |
| 05:08.11 | brlcad | right, that should be the worst case I *think* |
| 05:08.24 | brlcad | not realistic, but conceivable |
| 05:09.39 | starseeker | so if a ray passes within the error bound of the point, is it a hit? |
| 05:10.01 | brlcad | now the trick is when we run into a future operation that results in topologically invalid geometry (non-manifold for example), we can actually back out a decision and try to find one that will result in valid geometry |
| 05:11.05 | brlcad | if we were to get really fancy, each decision becomes a new graph in a decision tree and we have a parametric decision tree |
| 05:11.15 | brlcad | but that's fugly and expensive |
| 05:11.22 | starseeker | nods |
| 05:12.57 | starseeker | bemusedly wonders if we can use metaballs to keep track of the error bound :-) |
| 05:13.58 | starseeker | alright, I should get some sleep here :-P |
| 05:14.26 | starseeker | back after regaining consciousness |
| 05:15.15 | brlcad | there's actually a good argument for maintaining a fixed error |
| 05:15.38 | brlcad | and rejecting C if it's not within that D average point within error |
| 05:15.51 | brlcad | not accumulating error |
| 05:16.16 | brlcad | basically clamping error to some fixed magic tolerance slightly larger than the distance tolerance |
| 05:23.38 | brlcad | (like sqrt(distance tolerance)) |
| 05:24.07 | brlcad | for fractional tolerances of course |
| 05:28.56 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) | |
| 05:32.08 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) | |
| 05:33.38 | brlcad | the bigger issue is generally going to be that there are at least two main tolerances.. there's our absolute calculation tolerance for presumably what the hardware can handle, and a model tolerance, which is generally many orders of magnitude larger |
| 06:41.12 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 07:17.06 | *** join/#brlcad _sushi_ (n=_sushi_@84-72-93-63.dclient.hispeed.ch) | |
| 07:40.18 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) | |
| 08:14.49 | *** join/#brlcad PrezKennedyJR (i=Matthew@whitecalf.net) | |
| 08:25.40 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 08:31.51 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 09:31.32 | *** join/#brlcad Lez (n=lezardfl@189.58.209.254.dynamic.adsl.gvt.net.br) | |
| 10:12.03 | *** join/#brlcad madant (n=d@117.196.142.112) | |
| 12:02.23 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) | |
| 12:49.59 | brlcad | yawns |
| 13:10.40 | *** join/#brlcad madant (n=madant@117.196.140.132) | |
| 13:25.00 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) | |
| 13:25.32 | madant | loves waking up at 4 pm :) |
| 13:25.36 | *** join/#brlcad Don_ (n=Don@c-68-62-76-34.hsd1.mi.comcast.net) | |
| 13:42.59 | brlcad | madant: heh, fantastic :) |
| 14:05.15 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 14:49.56 | *** join/#brlcad ``Erik (n=erik@ftp.brlcad.org) | |
| 15:33.37 | *** join/#brlcad dreeves (n=IceChat7@67.130.253.14) | |
| 15:49.01 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net) | |
| 15:53.56 | ``Erik | hrm, *ponder* I have 4 photographs of an object with different lighting angles, it'd be really gnarley if we had an app that attempted to generate a 3d .g file from those images (random thought) |
| 15:54.22 | brlcad | ``Erik: put in for a dri :) |
| 15:54.36 | ``Erik | http://www.math.ubc.ca/~cass/Euclid/ybc/ybc.html are the images in question |
| 15:54.39 | brlcad | that's not far off from what I proposed a few years gack |
| 15:56.27 | ``Erik | babylonion geometric theory, pheer |
| 16:11.46 | *** join/#brlcad Lez (n=lezardfl@189.58.209.254) | |
| 16:13.01 | *** join/#brlcad madant (n=madant@117.196.131.88) | |
| 16:24.03 | brlcad | waves to madant |
| 16:44.59 | madant | waves back |
| 16:45.10 | ``Erik | does the wave, too |
| 16:46.18 | madant | all we need is a little resonance for an IRC disaster :) |
| 16:48.14 | madant | brlcad: did u have a look at the draft ? |
| 16:48.47 | brlcad | madant: briefly, reading in more detail later today |
| 16:49.17 | brlcad | er, no -- yours was to the list, yes I did read that |
| 16:49.50 | madant | will be back after dinner :) |
| 16:53.03 | brlcad | resounding comment to offer would be that I'd like you to emphasize achieving some actual user-visible integration/impact this summer, even if it means leaving some portions not quite resolved (like the grammar, or even portions of the solving framework) |
| 16:59.46 | CIA-40 | BRL-CAD: 03brlcad * r34123 10/brlcad/trunk/TODO: |
| 16:59.46 | CIA-40 | BRL-CAD: annotate intent to add material objects, shader objects, and image objects to v5 |
| 16:59.46 | CIA-40 | BRL-CAD: as has been discussed and mused over the years. really need material objects |
| 16:59.46 | CIA-40 | BRL-CAD: soon, which implies having shader objects even sooner. image objects can wait, |
| 16:59.46 | CIA-40 | BRL-CAD: though. |
| 17:01.05 | ``Erik | is kinda wishing he had a glidepad on his desktop :/ |
| 17:03.57 | madant | brlcad: true, i'd like for some visible integration myself :) Nothing helps further progress like a basic working system. |
| 17:04.17 | madant | and the actual issues will come up only when things are user-visible |
| 17:05.08 | madant | I think i could spend less time on the "perfect solver" and devote that time to user-interfacing |
| 17:05.43 | madant | ``Erik, glidepad ? |
| 17:07.18 | ``Erik | um, touchpad |
| 17:07.44 | ``Erik | the macbook is spoiling me with that bigassed glass beast |
| 17:08.05 | ``Erik | having to actually push a mouse button down sucks :D |
| 17:08.08 | ``Erik | </whine> |
| 17:09.27 | madant | ``Erik, :P don't be too lazy :D |
| 17:09.54 | madant | doesnt like the mouse at all |
| 17:10.51 | madant | though engineering-wise pretty neat for its time :) |
| 17:11.00 | ``Erik | well, having to click a small 'next' button 68 times is a bitch, the mouse tends to want to move, on my lappie, I'd just tap and not think about the location of the pointer, making it a soft 'next' button of its own |
| 17:11.10 | ``Erik | its time? you mean like '62? :D |
| 17:11.58 | ``Erik | 68, rather |
| 17:12.14 | madant | was just now checking that |
| 17:12.30 | ``Erik | doug engelbart, though the trackball was '52 |
| 17:12.52 | madant | wow 52 .. :D must have looked like a monster :) |
| 17:13.30 | ``Erik | picture doesn't make it look too bad, canadian 5-pin ball (which is about the size of a modern 'good' trackball) |
| 17:13.37 | ``Erik | there's a pic on the wikipedia article for meeces |
| 17:14.37 | madant | ah well looks straight out of a science fiction b/w movie |
| 17:15.27 | madant | "cutting edge" has progressed a lot in 50 years :) |
| 17:30.22 | *** join/#brlcad Lezard (n=lezardfl@189.58.209.254) | |
| 17:40.32 | brlcad | madant: yeah, I think that'd be *really* good to focus on -- pick one user-visible goal for the project and then organize your activities around making that happen on the backend, only exactly what's needed for that feature |
| 17:41.56 | brlcad | like you could make a 'validate' tool that calls the prep/constraint validation checks for a few primitives |
| 17:42.45 | brlcad | or the ability inside mged to create a parametric equation object that talks to other objects and will evaluate |
| 17:42.56 | brlcad | something succint and visible |
| 17:45.14 | ``Erik | wonders if dwaynes g_qa gui would be a good soc project? |
| 17:45.17 | madant | sounds logical , and very rigorously measurable too in terms of progress :) |
| 17:46.12 | brlcad | ``Erik: yeah, absolutely |
| 17:46.26 | brlcad | or better yet, a plugin in the new gui |
| 17:46.34 | brlcad | if said plugin underpinnings was in place |
| 17:48.20 | madant | g_qa gui ? |
| 17:50.03 | brlcad | yeah |
| 17:50.42 | ``Erik | http://sourceforge.net/tracker/?func=detail&aid=2717388&group_id=105292&atid=640805 |
| 17:51.32 | madant | ``Erik, was reading that ;) |
| 17:52.13 | ``Erik | of course, there's been discussion about that in person between a few different people that isn't reflected in the tracker yet :) |
| 17:53.04 | ``Erik | like storing plot files in the .g for easy resource mgmt/transfer. whether it's a seperate app, part of mged (or archer or whatever), or all of the above |
| 17:53.08 | ``Erik | etc |
| 17:53.47 | madant | brlcad: plugin underpinnings ? |
| 17:57.38 | brlcad | madant: the thin-client gui is supposed to be a heavily plugin-based architecture (on the front-end and back-end) |
| 17:58.18 | brlcad | hm, that reminds m e |
| 17:59.44 | madant | aha, an extensible gui :) nice.. seems like brl-cad is going to look quite different in the coming days ;) |
| 18:00.59 | brlcad | madant: that is all part of the plan, yes |
| 18:01.21 | brlcad | all in line with things spelled out here: http://brlcad.org/BRL-CAD_Priorities.png |
| 18:01.31 | brlcad | just more of the details on how |
| 18:05.33 | CIA-40 | BRL-CAD: 03brlcad * r34124 10/brlcad/trunk/src/external/Makefile.am: aha, fix distcheck for when Cubit isn't being built |
| 18:10.38 | *** join/#brlcad Malyce (n=iamtanma@wlanaccess-ext.jacobs-university.de) | |
| 18:12.09 | Malyce | hi ? |
| 18:12.32 | Malyce | I am new to IRC :P |
| 18:13.39 | Malyce | I had a couple of questions about the idea of implementing an API for BRL-CAD |
| 18:14.30 | ``Erik | ok? |
| 18:15.05 | Malyce | oh |
| 18:15.15 | Malyce | are you the admin ? |
| 18:15.34 | ``Erik | I think I'm tagged as one of them O.o just ask your questions, they'll get answered (eventually) |
| 18:15.59 | Malyce | I was wondering whether there was some work already done in the direction. |
| 18:16.15 | Malyce | ALso, what part of the code should I try to read, to get an understanding |
| 18:16.20 | Malyce | ? |
| 18:18.17 | Malyce | I would think that creating an API would involve knowing the core aspects of the geometry engine of BRL |
| 18:20.04 | Malyce | Is the Doxy of the code unavailable ? It seems so from the website |
| 18:20.59 | Malyce | I had done some research on BRL last year. I was unable to find documentation for the code. Is it just me, or is documentation played down in the open source industry ? |
| 18:27.50 | madant | Malyce: Doxy is there but not very updated, depends on the part of brl-cad code you were looking up. |
| 18:28.04 | madant | did u check out the svn and try building the doxygen output ? |
| 18:28.34 | madant | :) I am a last year gsoc participant and found brl-cad's code pretty well commented ;) |
| 18:34.22 | Malyce | I am trying it out now |
| 18:34.38 | Malyce | Ok, but I wanted to look at a sort of overview, if you know what I mean |
| 18:34.46 | Malyce | doxy is so nice |
| 18:47.48 | Malyce | Can you point me to the Doxy config file ? |
| 18:57.24 | ``Erik | misc/Doxyfile |
| 19:10.00 | brlcad | howdy Malyce |
| 19:23.49 | Malyce | hiya |
| 19:26.47 | brlcad | Malyce: there is actually a lot of documentation, it's just not neatly organized and in lots of places |
| 19:27.56 | brlcad | the code is pretty well commented throughout, but there is also this |
| 19:27.56 | brlcad | http://brlcad.sourceforge.net/doxygen/index.html |
| 19:28.30 | brlcad | was last ran a couple years ago -- but the api of the libs hasn't really changed in a drastic way since then |
| 19:28.37 | Malyce | thanks |
| 19:28.42 | Malyce | makes my life easier |
| 19:28.49 | brlcad | someone(tm) should get the doxygen system updating automatically on brlcad.org of course... :) |
| 19:32.30 | Malyce | I have some API experience |
| 19:33.12 | Malyce | in that, I have been working as an RA to formalize Solidworks. I used the VBA API for SW |
| 19:33.48 | Malyce | But, I have never developed an API. I do have C/C++ exp, 6 yrs plus of Uni and high school |
| 19:34.02 | Malyce | so, I was wondering whether I was qualified for the job. |
| 19:34.40 | Malyce | I don't really know where I would start, to design an API. Reading a lot of wikipedia right now. |
| 19:36.11 | Malyce | But I assume, the basic premise is that the API is linked to the Geometry engine for the output to user, and for the input from the user, it feeds it back. |
| 19:36.45 | Malyce | So, I should take a close look at the how the GUI interfaces with BRL, because that is the same interface that the API would use ? |
| 19:37.30 | Malyce | Any pointers, where this would be ? |
| 19:39.30 | Malyce | So, one of the GUIs is MGED. |
| 19:43.40 | Malyce | The GUI seems to be primitive. Is there a way to use BRL-CAD, command line ? |
| 19:46.11 | CIA-40 | BRL-CAD: 03erikgreenwald * r34125 10/brlcad/trunk/src/adrt/librender/cut.c: pointer wrangling. |
| 19:58.16 | Malyce | Found the cmd line in MGED. Is there a brief explanation of the BRL code structure somewhere. I can understand the doxygen, but I can't seem to get the overally structure of BRL. Am I being retarded ? |
| 20:01.01 | Malyce | Am I missing something obvious ? |
| 20:01.03 | *** join/#brlcad andax (n=andax__@d213-102-40-177.cust.tele2.ch) | |
| 20:05.45 | *** join/#brlcad madant (n=madant@117.196.130.75) | |
| 20:13.19 | Malyce | For example , where is the GUI initialisation done ? |
| 20:13.35 | Malyce | in Libdm ? |
| 20:18.03 | *** join/#brlcad dreeves (n=c752f34a@bz.bzflag.bz) | |
| 20:32.56 | CIA-40 | BRL-CAD: 03r_weiss * r34126 10/brlcad/trunk/ (3 files in 2 dirs): updates to rtarea adding center computations |
| 20:37.47 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-198.sbndin.btas.verizon.net) | |
| 21:02.27 | *** join/#brlcad madant (n=madant@117.196.129.253) | |
| 21:11.09 | brlcad | Malyce: sorry for the delays, busy day :) |
| 21:11.17 | brlcad | gimme a sec and I"ll answer all the ?'s |
| 21:11.33 | Malyce | np |
| 21:15.00 | ``Erik | didn't know that poking a smoke detector with a measuring tape constituted 'busy' :D *duck* |
| 21:16.17 | alex_joni | ``Erik: flaming measuring tape? |
| 21:22.43 | ``Erik | measuring tapes wearing mesh shirts and cutoffs? O.o |
| 21:25.48 | CIA-40 | BRL-CAD: 03r_weiss * r34127 10/brlcad/trunk/ (doc/docbook/system/man1/en/rtarea.xml src/rt/rtarea.1): updates to rtarea documentation |
| 21:30.14 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) | |
| 21:44.03 | mafm | hi there |
| 21:44.51 | *** join/#brlcad madant (n=madant@117.196.129.255) | |
| 21:54.04 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 22:15.17 | *** join/#brlcad ``Erik_ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) | |
| 22:26.51 | brlcad | howdy mafm |
| 22:27.01 | Ralith | hullo mafm |
| 22:27.44 | brlcad | Malyce: an RA? revenue assurance? |
| 22:28.18 | mafm | - Cubit/g-sat.cxx |
| 22:28.20 | mafm | + Cubit/g-sat.cpp |
| 22:28.34 | mafm | ``Erik was ranting about cpp a few days ago.. :D |
| 22:28.52 | brlcad | he rants about a lot of things |
| 22:29.30 | *** join/#brlcad madant (n=madant@117.196.129.154) | |
| 22:30.30 | brlcad | Malyce: as for overall structure, read volume I under docs on the website (the first doc link) for some basic philosophy, as well as HACKING file (near the middle is a description of the various dirs), and perhaps src/README for a little more detail |
| 22:31.12 | *** join/#brlcad ``Erik__ (i=erik@c-76-111-12-116.hsd1.md.comcast.net) | |
| 22:31.31 | brlcad | Malyce: depending on which API you're referring to, it actually has very little to do with the GUI -- more to do with the geometry engine |
| 22:31.51 | brlcad | there's a project to build up a geometry API similar to the acis/granite/etc engines |
| 22:33.14 | Malyce | Research Assistant |
| 22:33.18 | brlcad | if you want to work on the gui, there are a couple specific projects possible in that regard |
| 22:33.18 | Malyce | sorry for the confusion |
| 22:33.25 | brlcad | ahh, okay |
| 22:33.50 | Malyce | not really |
| 22:33.57 | Malyce | I wanted to work on the API |
| 22:34.07 | Malyce | I thought it would be interesting |
| 22:34.10 | brlcad | 'the API' .. what does that mean to you? |
| 22:34.21 | brlcad | there are many APIs in BRL-CAD |
| 22:34.26 | brlcad | there are a dozen libraries |
| 22:34.27 | objorn | what is the benchmark suite? |
| 22:35.07 | brlcad | objorn: the benchmark suite is a toolchain that will evaluate your system performance and report a performance metric that very closely represents your expected computation capacity |
| 22:35.50 | objorn | interesting |
| 22:36.00 | brlcad | reports a statistical measurement (similar to GFLOPS but unrelated) of your performance that traces back through a couple decades of computing |
| 22:36.00 | Ralith | also, verify render results with known-good images |
| 22:36.07 | Malyce | OOP Geometry API |
| 22:36.26 | objorn | this is useful for? |
| 22:36.33 | brlcad | yeah, it's also a verification / test suite |
| 22:36.57 | Malyce | Does it mean, that I will be summarizing the existing interfaces into a bigger interface, which will be more standardized |
| 22:36.57 | brlcad | objorn: to know how fast a machine is under real-world use |
| 22:37.12 | brlcad | Malyce: an, no -- not for the OOP Geometry API |
| 22:37.29 | brlcad | the OOP geometry api is basically developing something like the ACIS engine for BRL-CAD |
| 22:37.31 | objorn | ah, so if there's a deadline, you'll have a good idea of how much more computer power you need or when to start |
| 22:37.57 | ``Erik | *rantrantrant* :D |
| 22:38.31 | brlcad | we presently have the extensive LIBRT library API which provides most geometry services but it's not very clean/organized, not OO, and lacking some features |
| 22:38.38 | Malyce | Does it mean, that I will be summarizing the existing interfaces into a bigger interface, which will be more standardized ? |
| 22:38.43 | brlcad | objorn: one possible use, sure |
| 22:38.55 | brlcad | objorn: also very useful when buying new hardware |
| 22:39.01 | Malyce | so, the new API interface will just provide a nicer interface ? |
| 22:39.18 | Malyce | to an existing set of interfaces |
| 22:39.55 | brlcad | new computer vender comes out with a new system, claims it'll be 5x faster than the previous version... this gives a very accurate unbiased measurement that makes it really easy to compare one machine to another under controllable conditions |
| 22:40.07 | brlcad | Malyce: on top of the existing set of interfaces, yet |
| 22:40.10 | brlcad | s/yet/yes |
| 22:40.48 | starseeker | makes note to self to look at reorganizing the header files in include to be in subdirectories pertaining to individul libraries |
| 22:40.53 | brlcad | Malyce: have you ever worked with granite or acis? |
| 22:41.04 | Malyce | I have worked with the SW API only |
| 22:41.06 | starseeker | checks if that is in the TODO... |
| 22:42.06 | Malyce | SW: Solidworks |
| 22:42.34 | brlcad | very similar |
| 22:42.59 | brlcad | there is a project already under way related to this api in the rt^3 module |
| 22:43.10 | Malyce | the API you want to implement should be similar to that used by Solidworks ? |
| 22:43.34 | Malyce | If there is a project already underway, is it still possible for me to apply with this idea ? |
| 22:44.07 | brlcad | http://brlcad.svn.sourceforge.net/svnroot/brlcad/rt^3/trunk/src/ |
| 22:44.17 | CIA-40 | BRL-CAD: 03starseeker * r34128 10/brlcad/trunk/TODO: Add a note to look into reorganizing the headers so it is clearer which .h files pertain to individual libraries. |
| 22:44.22 | brlcad | Malyce: of course, just means you won't be working in isolation |
| 22:44.28 | brlcad | you have to coordinate with the other developers |
| 22:44.49 | Malyce | So, the specs have already been decided, and the structure has been set ? |
| 22:44.51 | brlcad | doable, just have to work on the API and be involved in a lot of discussions |
| 22:45.03 | brlcad | none of the gsoc projects are meant to be done by students alone :) |
| 22:45.22 | brlcad | some of the structure is set, most is a work in progress that will continue to evolve |
| 22:45.31 | Malyce | And any new programmer, just has to follow the pattern already established. i.e, the programming method implemented so far ? |
| 22:45.34 | Malyce | I see |
| 22:45.39 | brlcad | the engine has to take into accout, for example, what our existing libraries already do |
| 22:45.47 | brlcad | so that you can leverage those facilities |
| 22:45.51 | brlcad | and not reinvent the wheel |
| 22:46.07 | brlcad | we don't want you to reimplement what has already been done |
| 22:46.30 | brlcad | it's more about making a clean API that can be grown and tested that we will want to use in our own tools |
| 22:46.49 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 22:47.01 | brlcad | coreInterface and GeometryEngine are the two main efforts thusfar -- those two need to merge at some point |
| 22:47.28 | Malyce | Would it be possible for me to get the specs so far ? |
| 22:47.47 | brlcad | most of what is available is on the wiki or on the website |
| 22:47.57 | Malyce | I will read through it |
| 22:48.12 | brlcad | http://brlcad.org/wiki/Developer_Documents |
| 22:48.22 | brlcad | "BRL-CAD's core C++ interface" is one |
| 22:48.56 | brlcad | "Geometry Service" is another, closely related, but more focusing on something a layer above the C++ API |
| 22:49.35 | brlcad | and finally, more at http://brlcad.org/wiki/IBME_GeometryEngine |
| 22:49.56 | brlcad | that core interface effort and the ibme ge work are the two that need to merge |
| 22:52.12 | *** join/#brlcad cad85 (n=d4c92c1e@bz.bzflag.bz) | |
| 22:52.32 | cad85 | hello tanmay! |
| 22:52.54 | cad85 | we know you are hereeee!! |
| 22:53.22 | Ralith | O.o |
| 22:53.32 | Malyce | 0.o |
| 22:53.53 | brlcad | cad85: who is tanmay? |
| 22:53.59 | cad85 | if you are wondering what i am saying i am just greeting my friend |
| 22:55.38 | cad85 | bye |
| 22:55.41 | *** part/#brlcad cad85 (n=d4c92c1e@bz.bzflag.bz) | |
| 22:55.58 | Ralith | that was odd. |
| 22:56.07 | brlcad | yep |
| 22:56.42 | Malyce | uh please ignore them |
| 22:56.48 | ``Erik | hm, if'n ya GSOCers haven't put your proposal up on the goog site yet, do it soon |
| 22:56.49 | Malyce | friends playing a prank |
| 22:57.07 | ``Erik | they're trying to get estimates for how many proposals there will be (I believe you can edit them once you put them up) |
| 22:57.30 | Ralith | has done so. |
| 22:57.37 | ``Erik | ralith++ |
| 22:57.37 | brlcad | ~ralith++ |
| 22:57.42 | brlcad | fail! |
| 22:57.45 | Ralith | :D |
| 22:57.49 | mafm | ERIK FAIL |
| 22:57.59 | brlcad | heh |
| 22:58.03 | ``Erik | has no interest in manipulating that steaming pile of bot |
| 22:58.11 | ``Erik | just making a general statement :) |
| 22:59.06 | Ralith | is there a list of who's mentoring somewhere? |
| 22:59.54 | ``Erik | yeah |
| 23:02.35 | *** join/#brlcad kanzure (i=bryan@66.112.232.233) | |
| 23:05.17 | CIA-40 | BRL-CAD: 03Sean 07http://brlcad.org * r1319 10/wiki/Google_Summer_of_Code/Project_Ideas: /* Mentors */ update list for the 2009 folks |
| 23:06.43 | Ralith | hehe |
| 23:07.38 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1177680193.dsl.bell.ca) | |
| 23:08.52 | Malyce | With regards to Geometry Services, why would you need a layer above C++ API ? |
| 23:11.23 | brlcad | it's a distributed network service interface |
| 23:11.47 | brlcad | a way to bridge communication with other applications what want to remain loosely coupled |
| 23:12.45 | brlcad | e.g., a java application that wanted to access brl-cad geometry, get display lists, shoot rays, but not have to maintain a JNI wrapper or be tied to binary distribution issues |
| 23:13.43 | brlcad | or even in our own tool so that we can have a service talk to other geometry servers, allow distributed shared access to geometry, etc |
| 23:16.44 | ``Erik | so is v6 going to keep the 'flat' namespace or move to an fs like heirarchal one? |
| 23:19.20 | brlcad | it'll be more like svn -- you talk over a protocol and something happens on the backend |
| 23:19.55 | Malyce | Will the Geometry API be expected to perform such tasks as well ? |
| 23:20.03 | brlcad | Malyce: not at all |
| 23:22.55 | Malyce | Thanks a lot for your help. Goodnight. |
| 23:28.23 | *** join/#brlcad ``Erik (i=erik@c-76-111-12-116.hsd1.md.comcast.net) | |
| 23:44.33 | ``Erik | we don't take kindly to folk who don't take kindly 'round here |
