IRC log for #brlcad on 20090910

02:54.30 CIA-28 BRL-CAD: 03starseeker * r35874 10/brlcad/trunk/ (5 files in 3 dirs):
02:54.30 CIA-28 BRL-CAD: Add (but do not enable) code to grab all regions whose bounding boxes intersect
02:54.31 CIA-28 BRL-CAD: a sphere and place them in a group. This will at some point make a beginning
02:54.31 CIA-28 BRL-CAD: for advanced selection options in editors, but in its current form is too
02:54.31 CIA-28 BRL-CAD: limited to enable as a command.
03:32.21 *** join/#brlcad ibot (i=ibot@rikers.org)
03:32.21 *** topic/#brlcad is BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Release 7.14.8 posted (20090511) || GSoC2009 Next Step: upload your code to google, wait for shirt ;) thanks everyone! || log at http://ibot.rikers.org/#brlcad
05:37.07 *** join/#brlcad KingofCSU (n=king@222.247.155.229)
06:04.14 *** join/#brlcad puddingpimp (n=dave@118-93-244-155.dsl.dyn.ihug.co.nz)
12:00.26 *** join/#brlcad surje (n=surje@202.3.77.11)
12:54.04 CIA-28 BRL-CAD: 03brlcad * r35875 10/brlcad/trunk/NEWS:
12:54.04 CIA-28 BRL-CAD: reword so proper commit note will be associated with those lines in the summary
12:54.04 CIA-28 BRL-CAD: report. cliff added -r and -v options to the 3dm-g importer to set random
12:54.04 CIA-28 BRL-CAD: colors on objects during import and to provide better verbose processing
12:54.04 CIA-28 BRL-CAD: information during import.
15:19.03 *** join/#brlcad Elrohir (n=kvirc@p5B14CE79.dip.t-dialin.net)
16:18.33 *** join/#brlcad cpc26 (n=cpc26@72.170.156.242)
17:30.28 *** join/#brlcad samrose (n=samrose@c-71-238-71-94.hsd1.mi.comcast.net)
17:51.53 *** topic/#brlcad by louipc -> BRL-CAD Open Source Solid Modeling || http://brlcad.org || http://sf.net/projects/brlcad || Release 7.14.8 posted (20090511) || GSoC2009 Next Step: upload your code to google, wait for shirt ;) thanks everyone! || Logs at http://ibot.rikers.org/%23brlcad/
18:29.35 *** join/#brlcad samrose (n=samrose@c-71-238-71-94.hsd1.mi.comcast.net)
18:36.37 CIA-28 BRL-CAD: 03erikgreenwald * r35876 10/isst/trunk/src/Makefile.am: cope with growing c++isms in librt
18:37.02 CIA-28 BRL-CAD: 03erikgreenwald * r35877 10/brlcad/trunk/src/adrt/ (4 files in 2 dirs): more interface unification
18:37.17 CIA-28 BRL-CAD: 03erikgreenwald * r35878 10/isst/trunk/src/local_worker.c: use new init interface
19:06.19 brlcad V3ARGS() will expand a %f %f %f for you
19:06.54 brlcad assuming [0], [1], [2] indexing
19:19.37 ``Erik 'cept I have to break away from that, v3args is too "clever"
19:20.33 ``Erik (notice, blah, blah+1, blah+2, NOT blah[0], blah[1], blah[2]... references :D )
19:21.11 ``Erik if V3ARGS(&blah) did what I wanted, that'd be nifty, but it doesn't
20:40.15 brlcad parens?
20:40.15 brlcad ((&blah))?
20:40.19 brlcad maybe with a cast
20:40.33 brlcad (((float*)(&blah)))
20:46.37 ``Erik def'd as (a)[X], so'z V3ARGS(&a) resolves to (&a)[X], which blows up... can't do it with the macro
20:47.24 ``Erik it's too damn safe :D
21:03.09 brlcad ~seen Ralith
21:03.12 ibot ralith <n=ralith@69.90.48.127> was last seen on IRC in channel #brlcad, 1d 19h 57m 45s ago, saying: 'Yoshi477: yay!'.
21:03.53 brlcad ~seen jdoliner
21:03.54 ibot jdoliner <n=jdoliner@c-67-173-0-29.hsd1.il.comcast.net> was last seen on IRC in channel #brlcad, 10d 7h 29m 53s ago, saying: 'ah but fortunately, this won't be too hard to fix at all'.
21:04.16 brlcad students need to upload their code still
21:14.18 ``Erik ponders how evil "#define V3ARGSP(a) &((a)[X]), &((a)[Y]), &((a)[Z])" would be :>
21:51.08 brlcad pretty evil
23:00.25 ``Erik indeed, unrestrained thinking down that alley can turn into truely horrible abuses, that's how c++ crawled its way from the depths ;> *duck*
23:30.06 brlcad heh
23:30.16 brlcad c++ isn't *that* bad :)
23:30.20 ``Erik :D
23:30.43 ``Erik (it did begin life has a klugefest of macro's, though)
23:32.41 starseeker proposes klugefest as the code name for the next Windows release
23:33.10 ``Erik dude, not cool, don't insult the art of the kluge like that
23:33.10 ``Erik :D
23:33.40 starseeker heh
23:33.55 ``Erik windows 8 will be codenamed "fuckit, no one's using this anyways" if vista and 7 are indicators
23:34.01 starseeker ``Erik: oh, by the by - are you planning to un-weird-ify the isst user navigation?
23:34.07 ``Erik yes.
23:34.11 starseeker sweet
23:34.30 ``Erik I'm refactoring things to be clean and generic to make gui's trivial to write
23:34.54 ``Erik and then have a few versions to slap on (cocoa, gtk, sdl, tk, mebbe qt...)
23:35.12 louipc is 7 out now?
23:35.19 ``Erik libdm...
23:35.42 ``Erik windows 7 has been out for a bit now, I think
23:35.44 starseeker ogre... :-P
23:36.02 starseeker tries to ignore Windows releases...
23:36.15 ``Erik mebbe it's pre-release versions I've been hearing about
23:36.23 louipc I thought it was just beta
23:36.30 louipc or RCs
23:36.38 ``Erik hum, says oct 22 for release
23:36.45 ``Erik *shrug*
23:37.29 ``Erik doesn't quite see how ogre would be a viable interface for adrt... ogre is the engine below the interface, just like adrt... O.o
23:37.49 starseeker was thinking integrate it into the ogre+qt g3d stuff
23:38.04 starseeker nevermind - just idle humor
23:38.21 ``Erik ok, so g3d would be the frontend and adrt would be the optional ogre replacement :D
23:39.14 starseeker yeah, in that case you'd just render into ogre like we render into ogl now for a raytrace I guess (well, except working properly...)
23:39.55 ``Erik do we rasterize raytrace results into an ogl window? I thought just the plot sequences were sent down that pipeline
23:39.58 ``Erik *shrug*
23:40.22 starseeker Well, if you compile with opengl enabled, the rt window that pops up says ogl iirc
23:40.51 starseeker yeah - /dev/ogl
23:41.01 starseeker and at least on my machine it doesn't work so hot
23:41.13 starseeker (I think it's a long known issue)
23:41.27 starseeker just waiting on someone to really dig down deep and figure it out
23:41.34 ``Erik guh
23:41.38 ``Erik glDrawPixels()
23:42.28 ``Erik (historically, noticably slower than an unaccelerated X window, and stomped by decent XAA...)
23:42.40 starseeker even our X raytrace is drawing too slow - Sean and I noticed it when comparing a sphere raytrace to a nurbs sphere raytrace
23:42.53 ``Erik um, in mged, or direct?
23:43.01 starseeker direct, iirc
23:43.09 starseeker or rather, both
23:43.10 ``Erik mged uses the network framebuffer which does some r-tarded lock crap or something
23:43.26 ``Erik so on a fast multicore machine, it's hard to get a decent amount of cpu utilization
23:43.34 starseeker yeah, IMHO the whole thing needs a rethink/serious cleanup
23:43.40 ``Erik but 'rt' talks straight to the fb, so it's able to cook the cpu's pretty good
23:44.41 ``Erik thought rt was being called with like -P0 or something at first, until digging into it and spotting the ugly
23:45.31 starseeker heh
23:45.51 starseeker yeah, modern hardware exposes some interesting issues
23:47.48 starseeker it almost feels like some kind of double buffering is needed - render N lines to a buffer then update that part of the window
23:51.48 ``Erik *readreadread* looks like libpkg makes some assumptions that may no longer be valid? plus a whole lot of logic for each send (therefore each scanline)
23:52.35 ``Erik a better IPC approach might be the right thing for that
23:52.42 ``Erik if_shm.c ? :)
23:53.26 *** join/#brlcad talcite_ (n=matthew@69-165-139-121.dsl.teksavvy.com)
23:53.54 ``Erik (or unix sockets, or at least jumbo frames)

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