IRC log for #brlcad on 20090416

00:00.51 starseeker dreeves: here's the other screenshot with the uncommented code: http://bzflag.bz/~starseeker/d2_270_0_2.png
00:02.10 Ralith also nice!
00:18.55 CIA-28 BRL-CAD: 03indianlarry * r34234 10/brlcad/trunk/src/conv/asc2g.c: renamed getline() to gettclblock()
00:24.48 starseeker these are somewhat interesting: http://bzflag.bz/~starseeker/dented_sphere.png
00:24.58 starseeker http://bzflag.bz/~starseeker/dented_sph_surf_norm.png
00:27.29 Ralith that doesn't look dented so much as holed
00:27.54 louipc blind hole
00:28.11 louipc needs isometric view
00:28.14 starseeker It does appear to represent a removal rather than a surface distortion
00:31.51 starseeker the surface normal coloring, however, should be fairly unambiguous
00:32.27 starseeker if it were an outward distortion, I would expect the color gradient to run in the same general direction as that of the main sphere
00:38.09 starseeker is beginning to think it might be useful to have the option to draw more complete wireframes for the nurb primitives, corresponding to their structure
00:38.37 starseeker relating a raytrace to the underlying surfaces, edges, etc just by numbers may be a bit tricky
00:42.38 brlcad starseeker: can you create two spheres that match the dented sphere perfectly?
00:42.59 starseeker I can try
00:43.04 starseeker one second
00:44.03 brlcad would be interesting to run pixdiff/pixcmp on the results if the original radii and position values are derivable
00:44.13 starseeker hmm
00:44.24 starseeker not easily, at least from the l output
00:45.05 brlcad can't believe he owes so much this year
00:45.20 starseeker winces
00:45.30 starseeker doing the late night post office thing? ;-)
00:45.46 brlcad oh hell no, stopped that 5/6 years ago
00:45.56 starseeker online then?
00:45.59 brlcad e-file
00:46.02 brlcad yeah
00:46.03 starseeker nods
00:46.10 starseeker that's how I did it too, except for VA
00:46.23 brlcad used to do it all by hand, an all-day event, many forms, all the instructions and subforms
00:46.54 starseeker yuck
00:47.00 brlcad until one year it got so bad that I worked on them for about 20 hours non-stop (and I knew what I was doing!) and was still running up against the deadline
00:47.15 starseeker dreeves: fwiw, I can confirm that the rebuilt sphere is manifesting as holes
00:47.30 brlcad I had about two-hours till midnight (blen burnie office was open till midnight), went on-line
00:47.40 brlcad did the whole thing in less than half an hour
00:47.47 Ralith odamn
00:47.54 Ralith that must have been a little frustrating.
00:48.08 brlcad it was more amazing
00:48.09 Ralith after 20 hours of work
00:48.39 brlcad I was dubious that it'd be at all right with all the various forms I had (self-employed, depreciation tables, multiple sources of income, etc)
00:49.30 brlcad since it asked more in a wizard-style interface, asking lots of questions
00:50.08 brlcad I was already 95% done on paper, so I actually had everything in front of me to verify and it all matched up nicely
00:50.16 brlcad so never again after that
00:50.40 brlcad this year was hell though, even on-line ... for many reasons
00:51.18 brlcad worst. tax-year. ever. (for me)
00:52.44 brlcad orders some comfort food
00:57.17 starseeker figures new house made things nice and complex...
00:57.28 brlcad it did
00:57.41 brlcad insanely so
00:57.53 brlcad especially purchasing near the end of the year
00:58.00 starseeker ow
00:58.08 yukonbob what about the cocaine and hookers from your rockstar lifestyle as a BRL-CAD developer?
00:58.17 ``Erik hehehe
00:58.38 starseeker would hire a CPA or something rather than deal with the headache of truly complex taxes...
00:58.46 brlcad yukonbob: they're paid under the table, *shhh*
00:58.52 yukonbob heh
00:58.53 ``Erik yes, we take private jets when we go out for lunch and all that, and wear leather pants
00:59.05 yukonbob LOL leather pants
00:59.10 yukonbob hawt
00:59.11 yukonbob !
00:59.17 ``Erik yes, they are, a lot of chaffing
00:59.36 starseeker scowls at rebuilt sphere
01:00.35 starseeker gonna need some way to know what we're raytracing within the nurb and how close it is to any edges/verticies/etc
01:02.34 ``Erik hm, since opennurbs has a container for a straight up brep surface, ya think the utah teapot might be a good geometry to experiment with?
01:02.52 starseeker could be
01:03.01 ``Erik iirc, it's just 16 control points
01:03.51 brlcad teapot isn't solid geometry
01:04.04 ``Erik wait, no, 28 patches in the original
01:04.14 brlcad handling non-solid ON_Brep objects hasn't been looked into
01:04.40 ``Erik ah, okie, I figured it might be magically handled in the guts of opennurbs :) *shrug*
01:05.52 starseeker this is probably informative once it can be related to the nurbs surfaces: http://bzflag.bz/~starseeker/rebuilt_sphere_270_0.png
01:05.59 brlcad same surface intersection and trimming logic, but that all has to be handled up in the shot() routine
01:07.51 hippieindamakin8 silently observes.
01:08.08 starseeker it's almost as if the surfaces are being rendered up to some maximum absolute x, y or z and then nothing
01:08.08 brlcad not so silent :)
01:08.16 hippieindamakin8 :P
01:09.15 starseeker will have to take a hard look at how the line renderings are done and see if edges can be incorporated as an option
01:09.53 starseeker if those it would be helpful to be able to see the makeup of the surfaces
01:11.00 starseeker suppose it can be compared with the complete sphere...
01:11.09 starseeker alright, I'm getting out of here :-)
01:11.12 starseeker bbl
01:29.42 *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net)
01:37.36 dreeves starseeker yes I confirmed last night it was holes. BTW it is entirely possible to see dark spots with out the slow change in color. I have seen cases where were on the edge of a surfaces and it calculates a normal perpendicular to the ray. In order to confirm it wasn't that I checked every normal and when one was near perpendicular I reset to reverse the ray direction which will make the pixel light up they didn't
01:39.34 dreeves so obviously it was a hole which really surprised me because I wasn't getting errors for odd number of hit points. If it missed on the front it should have hit on the other side and reported errors. I isn't which means it isn't only missing the front but also the surface behind it
01:41.23 dreeves that is what drove me to rt from different ae when I noticed everything went to hell in a hand basket pdq. Was some what encouraging though believe it or not because at least it isn't wasn't a tolerance problem. Just dealing with something wrong.
01:44.59 dreeves I don't think it is anything real serious because obviously we are able to calculate intersection and appear to that we somewhat understand the trim geometry. BTW I can turn off trimming and still see the problem so this isn't trimming doing this.
01:47.35 dreeves The front side it is scary because it looks like an edge but I don't think it is because when I shot from the other angle a lot more was missing than an edge. IMO something is going on with interpretation of the geometry that is causing the problem
01:48.03 brlcad dreeves: note that the phong shader will automatically flip a backward-facing normal
01:48.37 brlcad should see "shade_inputs(object) flip N ..." messages if it does
01:50.33 dreeves yeah I new that was the case but if it is near perpendicular and not perpendicular or more I was thinking it might not be flipping that
01:50.59 dreeves either was it is definitely a hole
01:51.15 brlcad yeah, if it's just "nearly" perpendicular, it'll come back
01:51.37 dreeves are you saying it will flip it?
01:51.39 brlcad BN_VECT_ARE_PERP() is using the default tolerance
01:51.53 brlcad if it's nearly perpendicular, it won't
01:52.03 dreeves right that was my thinking
01:53.15 dreeves The delay in me working this isn't because I'm struggling I just got busy on the day job. I'm actually pretty confident we can fix this pdq
01:53.47 dreeves I was worried when I thought it was a tolerance issue but now that I know it isn't I feel better
01:54.48 *** join/#brlcad dtidrow (n=Don@c-68-62-76-34.hsd1.mi.comcast.net)
01:55.37 brlcad nods
01:55.50 brlcad there are plenty of tolerance issues remaining, no worries there ;)
01:58.58 dreeves nods :)
02:36.56 *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net)
02:53.33 *** join/#brlcad AlexandreGuedes (n=chatzill@189-92-165-117.3g.claro.net.br)
03:30.36 *** join/#brlcad madant_ (n=madant@117.196.128.248)
03:39.04 PrezKennedy wtf
03:46.37 *** join/#brlcad _pseudony (n=irchon@wireless-128-62-173-79.public.utexas.edu)
03:48.17 _pseudony /nick _pseudonym
03:48.59 pacman87 hmm, seems to be some bugs/omissions in the ipod touch irc client i'm trying
03:50.16 *** join/#brlcad AlexandreGuedes_ (n=chatzill@189-92-165-117.3g.claro.net.br)
03:52.25 *** join/#brlcad _pseudony (n=irchon@wireless-128-62-173-79.public.utexas.edu)
03:54.41 *** join/#brlcad _pseudony (n=irchon@wireless-128-62-173-79.public.utexas.edu)
03:56.02 *** join/#brlcad _pseudony (n=irchon@wireless-128-62-173-79.public.utexas.edu)
03:57.07 *** join/#brlcad _pseudony (n=irchon@wireless-128-62-173-79.public.utexas.edu)
03:57.53 *** join/#brlcad _pseudony (n=irchon@wireless-128-62-173-79.public.utexas.edu)
03:58.04 pacman87 sorry about the join/part spam :(
04:00.00 *** join/#brlcad _pseudony (n=irchon@wireless-128-62-173-79.public.utexas.edu)
04:01.52 *** join/#brlcad pacman_87 (n=irchon@wireless-128-62-173-79.public.utexas.edu)
04:03.58 *** join/#brlcad poolio (i=poolio@LEAF.RES.CMU.EDU)
04:04.08 poolio Err, did bzflag get klined?
04:22.22 *** join/#brlcad madant (n=madant@117.196.128.248)
04:28.44 PrezKennedy looks like it
04:28.52 PrezKennedy whole bunch of you guys got dumped at once
04:38.10 *** join/#brlcad AlexandreGuedes_ (n=chatzill@189-92-165-117.3g.claro.net.br)
05:07.02 *** join/#brlcad elena (n=opera@92.86.0.28)
05:31.51 *** join/#brlcad elite01 (n=omg@unaffiliated/elite01)
05:38.01 *** join/#brlcad madant (n=d@117.196.148.46)
06:15.20 *** part/#brlcad elena (n=opera@92.86.0.28)
06:41.59 dreeves so I'm having compile problems in librt can't find mirror.c??
06:59.07 *** join/#brlcad AlexandreGuedes_ (n=chatzill@189-92-165-117.3g.claro.net.br)
07:19.25 *** join/#brlcad poolio (i=poolio@LEAF.RES.CMU.EDU)
07:29.23 *** join/#brlcad _clock_ (n=_sushi_@77-58-147-167.dclient.hispeed.ch)
07:31.00 *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net)
07:40.01 *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net)
07:47.01 *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net)
08:01.28 *** join/#brlcad madant (n=d@117.196.129.235)
08:22.41 *** join/#brlcad AlexandreGuedes (n=chatzill@189-92-165-117.3g.claro.net.br)
08:22.45 *** join/#brlcad elite01 (n=omg@unaffiliated/elite01)
08:45.25 *** join/#brlcad AlexandreGuedes_ (n=chatzill@189-92-165-117.3g.claro.net.br)
09:03.10 *** join/#brlcad AlexandreGuedes (n=chatzill@189-92-165-117.3g.claro.net.br)
09:35.39 *** join/#brlcad elite01_ (n=omg@unaffiliated/elite01)
09:50.33 *** join/#brlcad madant (n=d@117.196.135.125)
10:10.02 *** join/#brlcad AlexandreGuedes_ (n=chatzill@189-92-165-117.3g.claro.net.br)
10:20.43 *** join/#brlcad MinuteElectron (n=MinuteEl@unaffiliated/minuteelectron)
11:01.12 *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net)
11:13.43 *** join/#brlcad d-lo (n=claymore@bz.bzflag.bz)
11:13.53 d-lo mernin all!
11:19.30 *** join/#brlcad brlcad (n=sean@bz.bzflag.bz)
11:19.46 *** mode/#brlcad [+o brlcad] by ChanServ
11:20.10 d-lo howdy there brlcad!
11:20.21 brlcad hellos
11:21.17 *** join/#brlcad elena (n=opera@92.86.0.28)
11:21.45 *** part/#brlcad elena (n=opera@92.86.0.28)
11:22.33 *** join/#brlcad elena (n=opera@92.86.0.28)
11:32.14 *** part/#brlcad elena (n=opera@92.86.0.28)
11:34.09 *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net)
11:34.22 mafm hi
11:34.55 d-lo hai mafm!
11:35.03 brlcad d-lo: nice work commenting on the apps
11:35.20 d-lo puffs out chest.
11:35.21 d-lo thanks!
11:35.35 brlcad if any jumped out at you over the one that you're assigned to, mentors can still be swapped around
11:35.55 brlcad technical mentoring is still group-based, but the mentor assigned does much of the logistic tracking
11:36.42 d-lo I was actually thinking about the GUI project.... might be a better fit for me. If starseeker doesn't care of course.
11:37.16 brlcad everyone wants the gui :)
11:37.46 d-lo I don't think i could provide the proper level of mentoring for libpc, revolve/sweep, or BREP.
11:39.27 brlcad remember that it's not so much the technical side, it's just being able to keep track of how much they've done
11:39.31 brlcad how active they've been
11:39.42 d-lo Importers, sure, but the hardcore math stuff I am not so strong with.
11:39.48 brlcad how much of what they said they were going to do did they actually finish
11:40.12 d-lo okay, thats as much as i figured. Its the 'technical questions' that are sure to pop up ;)
11:40.26 brlcad technical questions belong to the whole team
11:40.37 brlcad they should intentionally be out in the open
11:40.43 d-lo but i suppose there is a decent support network in place.
11:41.22 brlcad for example, there should be no private discussions -- no PMs on IRC to talk technical issues
11:41.29 d-lo pffft. look at this. 'we can still swap mentors around' but when i take him up on the offer, its 'Noooooooooooooo sir!' ;)
11:41.36 brlcad should all be on this channel or on the wiki or on the devel mailing list
11:41.37 d-lo j/k
11:42.06 brlcad nah, that's possible -- have to talk to cliff
11:42.33 brlcad libged connection is why you were added to the one you're on
11:42.46 brlcad since that relates to the GS a bit
11:42.52 d-lo its all good. I am happy where I am at.
11:42.53 brlcad but the gui has a similar connection
11:43.11 d-lo can't shy away from new things *too* much
11:43.13 brlcad and more importantly, gui should be using GS directly
11:43.39 brlcad just I don't expect it'll actually get that far over the summer
11:43.54 d-lo well now, i just might have to crack the whip a bit ;)
11:43.58 brlcad would rather see the gui get to a solid framework state with no/little backend support
11:44.07 brlcad have it look good
11:44.12 d-lo 'what the 'ell is Google payin ya for boy?!' :)
11:44.34 d-lo agreed
11:45.42 d-lo is there anyway to make Saunders wire in the gui to the existing build system vice cmake ?
11:46.57 brlcad how so?
11:47.15 brlcad it alread is using cmake
11:47.24 d-lo haven't looked at it in a while, but doesn't the the new gui, g3d, or whatever its called use cmake?
11:47.39 mafm yes, it is
11:47.52 d-lo points to mafm. There he is!
11:47.56 brlcad it works similar to the gs -- you build and install brl-cad, then it builds against the brl-cad libs in cmake
11:48.30 d-lo just wondering if it would be cleaner to keep the build systems uniform, thats all. pros/cons?
11:48.38 brlcad he actually updated it to use our pkg-config files too, so it finds the deps to link against nicely
11:48.48 mafm I just didn't understand the Saunders, wire and vice words in your phrase :D
11:49.17 brlcad d-lo: lemme know when you're done converting all of the main module build to cmake and we can talk about integration :)
11:49.54 brlcad otherwise it could be an autotools based project, but we'd picked cmake because it's generally better for new code
11:50.52 d-lo ah, kk. So would it be 'better' to make rt^3 build via cmake since its techically all 'newer' code?
11:51.09 brlcad yeah
11:51.43 d-lo strokes his chin. Hrm....
11:51.58 mafm isn't it yet?
11:52.11 brlcad rt^3's build predates cmake being useful so it was mirrored off the main module
11:52.23 mafm ops :)
11:52.24 brlcad mafm: not yet
11:52.54 d-lo wonders if a convert to cmake, now, would be better, rather than waiting till rt^3 gets more complex and cluttered...
11:53.28 brlcad it would
11:53.54 brlcad further it goes, the more entrenched and less beneficial a move
11:53.57 mafm coreInterface is small, shouldn't be much of a problem I guess, if not already
11:54.28 d-lo grumbles about just getting this blasted Work computer working with autotools...
11:54.44 mafm ogre & co. in src/other are using their own build systems (but called from cmake IIRC), I produced cmake for RBGui and Mocha that will be gone
11:55.08 brlcad like the main module -- the cost vs benefit just isnt there for us to convert the build to cmake because it's so well developed, complete, with lots of tuned behavior and options that would be very time-consuming to replicate and retest in cmake
11:55.37 d-lo nods at brlcad.
11:55.37 *** join/#brlcad elite01 (n=omg@unaffiliated/elite01)
11:55.48 brlcad so autoconf isn't going away anytime soon :)
11:56.05 brlcad we'll just have two
11:56.30 d-lo two? build systems?
11:56.34 brlcad actually still works rather nicely to have distinctly separate barrier between the lib layers
11:57.13 brlcad yeah, two build systems -- the core (brlcad) and then an overlay (rt^3)
11:57.33 d-lo kk, just making sure I understood what you typed =D
12:00.21 d-lo as for rt^3/src/ director structure, i am thinking of doing some re-organizing. It kinda bugs me that there are several aspects of the project going on at the same time with little to no communications and people are putting things wherever they want (myself included)
12:01.45 d-lo and if the rt^3 dividing lines (GUI, GS, GE) are acceptable, I am thinking of re-org'ing the dirs a bit to represent that.
12:01.45 d-lo especially if we end up with multiple GUIs
12:03.03 mafm ok for me, svn preserves history and everything, so no big disadvantages
12:03.59 d-lo I think daniel is the only other major worker bee in the rt3 module, so I might email him/use the devel mailing list.
12:04.15 d-lo of course, i might just re-org now and as permission later ;)
12:04.46 brlcad yeah, those should definitely be three distinct "products" by themselves with GS dependent on GE, GUI dependent on GS, all three dependent on core
12:04.48 d-lo and thats just cause I dont know what is 'politically correct' in the OS world yet :)
12:05.12 d-lo core == common stuff
12:05.14 brlcad re-org would be great, but it should be communicated
12:05.15 d-lo -or-
12:05.22 d-lo core == brlcad module
12:05.25 d-lo ?
12:05.25 brlcad brlcad module
12:05.26 d-lo kk
12:05.58 brlcad they may have some common code, classes that are shared -- but I wouldn't plan for them having shared sublibs just yet
12:06.33 brlcad as that common code probably just belongs down with GE if it is common
12:08.03 brlcad should e-mail daniel (or any dev) directly on dev matters, the mailing list communicates that openly much better
12:08.15 brlcad it's a pretty small list, not like the discussion wanders off-topic into arguments
12:08.33 d-lo heh, 'down with GE'.... 80's rap song about General Electric...
12:09.41 brlcad how about proposing the overall reorg structure to the list, then work towards that structure incrementally
12:11.19 d-lo brlcad: working on an email right now. I do not think that it will cause much of a 'wave in the water' to reorg src/ into src/guis/ src/gs/ src/ge src/common and src/other
12:11.31 brlcad or at least making the changes incrementally so that if an issue comes up, it's not mixed in with 100 other reorg changes
12:11.52 d-lo nods. Understood
12:12.24 brlcad heh, I wouldn't plan on multiple guis until we have a distinct need
12:12.28 d-lo plus it will give a good history and allow people to make fun of me when i do something stupid =D
12:12.36 brlcad have enough work ahead to get one working well
12:12.49 brlcad what is src/common?
12:13.25 d-lo place to put code common to guis/ gs/ and ge/ (if it actually exists)
12:14.13 brlcad bikeshed difference, but src/GUI, src/GS, src/GE (caps) would reflect their c++ nature well :)
12:14.23 d-lo i only thought that src/common might be useful since the guis may not want to include the entire libge
12:14.29 brlcad ah, that was my point earlier -- if it's actually common, it probably belongs in GE
12:15.56 d-lo yeah, i was thinking about that point, and i can't come up with anything that the GUIs would need that would be in GE... but I suppose we can work that issue when it arises
12:16.13 d-lo 'if' it comes up at all.
12:16.19 brlcad yeah
12:16.25 brlcad leave it out until needed
12:16.37 d-lo you minimalist you.
12:16.55 hippieindamakin8 giggles
12:17.10 brlcad the various lib dirs in src/lib* were organized that same way you're suggesting before GE came on the scene
12:17.25 brlcad those libs collectively were the start of a GE themselves
12:17.44 brlcad geometry, image, network, numeric, raytrace, and utility (common) services
12:17.50 d-lo well then, sounds like an easy mv command or two!
12:18.01 d-lo ;)
12:18.28 brlcad most everything daniel's done to date fits under that geometry category
12:18.53 brlcad GS picked up that network category
12:19.08 brlcad (so ge longer has it)
12:26.01 d-lo your words speak true. I had felt a disturbance in the rt3 module for some time, but couldn't put my finger on what it was....
12:26.03 brlcad it shouldn't be too hard to get a consensus on the basic layout -- more just an issue of merging the right things together without losing any of the invested effort on the old or various new codes that have since kicked off
12:27.36 brlcad there's actually not much duplication as it is, just four people that have ignored what the previous coder left in place :)
12:28.02 d-lo are you refering to lib* dirs?
12:28.42 brlcad for the first guy, yeah
12:28.56 brlcad then the next guy ignored the lib dirs and what the second guy added
12:29.15 brlcad then the next guy ignored the lib dirs, what the second guy added, and the third guy, ... :)
12:29.22 brlcad kinda funny, but classic
12:29.31 brlcad mostly because it's a sandbox
12:29.52 brlcad wasn't a pressing need to hardline the organization until recently
12:30.11 brlcad so time to refactor!
12:32.07 brlcad plus the switch in build systems made it even more tricky to merge them half-way through
12:32.17 brlcad and is really the brunt of the work even now
12:32.54 brlcad the org itself isn't complicated or riddled with pitfalls (unless code is deleted)
12:33.03 brlcad it's wiring up the build
13:17.02 CIA-28 BRL-CAD: 03d_rossberg * r34235 10/rt^3/trunk/include/brlcad/common.h:
13:17.03 CIA-28 BRL-CAD: an exception with an error message similar to bu_bomb
13:17.03 CIA-28 BRL-CAD: The implementation/return value of std::exception::what() depends on the
13:17.03 CIA-28 BRL-CAD: compiler (it is not in the standard). That's why there is now a
13:17.03 CIA-28 BRL-CAD: BRLCAD::bad_alloc derived from std::bad_alloc which carries a hopefully useful
13:17.05 CIA-28 BRL-CAD: message.
13:20.39 CIA-28 BRL-CAD: 03d_rossberg * r34236 10/rt^3/trunk/ (20 files in 2 dirs): the core interface now compiles under Linux too
14:06.32 *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc)
14:09.46 CIA-28 BRL-CAD: 03davidloman * r34237 10/rt^3/trunk/src/iBME/Makefile.am: Cleanup: removed a few straggling references to Boost libs
14:13.43 *** join/#brlcad madant (n=d@117.196.150.228)
14:21.28 CIA-28 BRL-CAD: 03davidloman * r34238 10/rt^3/trunk/src/other/Makefile.am: Cleanup: removed Makefile.am that referred to outdated/removed 3rd party libs
14:22.07 *** join/#brlcad madant_ (n=d@117.196.137.213)
14:28.30 CIA-28 BRL-CAD: 03davidloman * r34239 10/rt^3/trunk/ (configure.ac src/other/uuid/ src/uuid/): moved src/uuid to src/other/uuid
14:31.22 CIA-28 BRL-CAD: 03davidloman * r34240 10/rt^3/trunk/src/ (GUI/ GUIs/): Refactored GUI to GUIs
14:31.54 *** join/#brlcad elite01 (n=omg@unaffiliated/elite01)
14:51.17 *** join/#brlcad elena (n=opera@92.86.0.28)
15:08.08 *** part/#brlcad elena (n=opera@92.86.0.28)
15:08.45 *** join/#brlcad samrose (n=samrose@adsl-76-226-71-255.dsl.sfldmi.sbcglobal.net)
15:09.00 *** join/#brlcad elena (n=opera@92.86.0.28)
15:09.52 brlcad waves to elena
15:12.05 *** part/#brlcad elena (n=opera@92.86.0.28)
15:14.42 *** join/#brlcad FAMULUS (n=mark@dsl081-135-036.nyc1.dsl.speakeasy.net)
15:16.21 *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net)
15:17.23 PrezKennedy waves to brlcad
15:17.31 brlcad howdy
15:17.35 brlcad digest all that meat yet?
15:17.38 PrezKennedy yeah!
15:17.43 PrezKennedy finally
15:27.03 ``Erik uh, way tmi
16:29.51 *** join/#brlcad jdoliner (n=jdoliner@c-68-51-76-57.hsd1.il.comcast.net)
16:31.40 jdoliner have selections been announced publicly somewhere?
16:39.04 pacman87 jdoliner: official announcement is still the 20th, i believe
16:40.19 pacman87 although the topic disagrees with me
17:01.04 jdoliner yeah, this is what led to my confusion as well
17:01.09 jdoliner how many slots did yu guys get?
17:01.44 brlcad 5
17:02.15 brlcad ah right, topic .. the selections are pretty near final on the 15th, but we cannot announce until the 20th
17:03.09 *** topic/#brlcad by brlcad -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Release 7.14.6 posted (20090403) || GSoC2009 Next Step: selections are made, they will be announced (by Google) on the 20th
17:19.39 *** join/#brlcad poolio (i=poolio@LEAF.RES.CMU.EDU)
17:20.20 brlcad howdy poolio
17:20.37 poolio ahoy!
17:21.11 *** join/#brlcad elena (n=ebautu@89.136.118.141)
17:21.40 hippieindamakin8 hey brlcad , pacman87
17:21.51 brlcad poolio: how goes the semester?
17:21.58 brlcad howdy hippieindamakin8
17:22.08 poolio I just was catching up on e-mail... are the mentor-student assignments all worked out?
17:22.16 brlcad yeah
17:22.32 brlcad unless you want an assignment, you're welcome to one
17:22.42 brlcad really shouldn't be assigned, for example
17:22.53 poolio brlcad: it's been good, but insanely busy. working two jobs and 7 classes :)
17:24.46 poolio hmm, well it looks like the only project I could possibly be helpful on is the BREP on BREP one, and it looks like there's already someone who is not you on that. I'll definitely be idling around here over the summer and try to provide as much help as I can, maybe even finish up on some of that CSG -> BREP stuff now that I get it
17:26.16 *** join/#brlcad poolio (i=poolio@LEAF.RES.CMU.EDU)
17:26.19 brlcad poolio: the assigned mentors are more for logistic tracking, not technical guidance -- technical is group-shared so you can help out with that one regardless
17:26.39 brlcad also, selections aren't announced, so hush on the projects :)
17:26.43 brlcad bah
17:26.47 *** join/#brlcad poolio (n=poolio@bz.bzflag.bz)
17:27.01 poolio will do
17:27.19 brlcad also, selections aren't announced, so hush on the projects .. :)
17:29.31 poolio oopsy daisy. sorry bout that... what I meant to say was if such a project were accepted into GSOC then ...
17:29.46 brlcad heh
17:30.35 brlcad it's okay, if folks were closely paying attention, it's pretty clear who at least 4 of the 5 are
17:31.13 brlcad at least .. "in all likelihood"
17:31.39 elena ;)
17:34.18 brlcad hm, I suppose our project priorities ( http://brlcad.org/BRL-CAD_Priorities.png ) conceivably narrows in a little too
17:34.27 brlcad though there are a couple outliers, hm, maybe not
17:35.42 *** join/#brlcad AlexandreGuedes (n=chatzill@189-92-135-182.3g.claro.net.br)
18:36.21 *** join/#brlcad FAMULUS (n=mark@dsl081-135-036.nyc1.dsl.speakeasy.net)
18:36.51 *** join/#brlcad samrose (n=samrose@ip-207-145-38-45.iad.megapath.net)
18:42.25 *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38)
19:06.03 dreeves brlcad and starseeker shoot the dented sphere from the side with trimming definitely not dented
19:06.35 dreeves So maybe there still is some issues with trimming
19:30.08 *** join/#brlcad _sushi_ (n=_sushi_@77-58-243-9.dclient.hispeed.ch)
19:49.33 *** join/#brlcad jonored_ (n=jonored@LAZARUS2.WIFI.WPI.EDU)
19:53.51 *** join/#brlcad BigATo1 (n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net)
20:03.11 *** join/#brlcad andax (n=andax__@d213-102-40-135.cust.tele2.ch)
20:05.35 CIA-28 BRL-CAD: 03bob1961 * r34241 10/brlcad/trunk/src/ (3 files in 2 dirs): Updates related to Archer's view-only mode.
20:16.07 *** part/#brlcad elena (n=ebautu@89.136.118.141)
20:47.23 jonored_ ...Well, I can get the principal curvatures for a point on a nurbs surface, but not the associated direction yet...
21:04.38 *** join/#brlcad Don_ (n=Don@c-68-62-76-34.hsd1.mi.comcast.net)
21:15.07 *** join/#brlcad elena (n=ebautu@89.136.118.141)
22:28.44 *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-146.sbndin.btas.verizon.net)
22:32.47 *** join/#brlcad typ0 (n=coder@um-sd06-125-2.uni-mb.si)
23:23.43 *** join/#brlcad Don__ (n=Don@c-68-62-76-34.hsd1.mi.comcast.net)
23:55.24 *** join/#brlcad Elrohir (n=kvirc@p5B14FF0E.dip.t-dialin.net)

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.