| 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) |