| 00:45.11 | *** join/#brlcad CIA-4 (n=CIA@208.69.182.149) |
| 01:22.23 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177593139.dsl.bell.ca) |
| 01:23.45 | IriX64 | http://rafb.net/p/js9SlQ72.html <---- runtime, dunno what this is all about |
| 03:19.14 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177593139.dsl.bell.ca) |
| 03:19.49 | IriX64 | http://rafb.net/p/MtYMIK52.html <---- works guys :) |
| 03:22.17 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/black.png <--- heres what that shot produced |
| 04:13.13 | Toba | helicopter! |
| 04:28.53 | *** join/#brlcad CIA-4 (n=CIA@208.69.182.149) |
| 04:41.11 | brlcad | woot, yukonbob |
| 04:56.59 | dtidrow | evening, brlcad |
| 05:09.27 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/include/config_win.h: don't need HAVE_MATHERR |
| 05:10.14 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/mged/anal.c: remove the old acos() hack to quell implementation errors by overriding matherr() |
| 05:18.07 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/src/librt/ (Makefile.am sqrt.gould.s sqrt.vax.s): |
| 05:18.07 | CIA-4 | BRL-CAD: remove the unused assembler sqrt() implementations for the gould and vax. |
| 05:18.07 | CIA-4 | BRL-CAD: relinquish to the bowels of revision history until there is (ever) a need to |
| 05:18.07 | CIA-4 | BRL-CAD: properly reintegrate into the build (where they probably belong in libbn) |
| 05:23.39 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: libtool on mac chokes on the -bind_at_load, get rid of it |
| 05:38.25 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/include/config_win.h: no longer need HAVE_TMPFILE_S, no longer using tmpfile_s() |
| 05:40.02 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: no longer using tmpfile_s(), don't check for it |
| 05:43.09 | CIA-4 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: we don't use ftime() |
| 05:46.01 | yukonbob | evening, cadheads |
| 05:51.49 | dtidrow | okay, so what's the program for displaying .pix images? |
| 05:52.30 | yukonbob | pix-png, favourite .png viewer. |
| 05:52.55 | dtidrow | pix-png converts them to png's? |
| 05:53.07 | yukonbob | heh -- truth in advertising. |
| 05:53.55 | dtidrow | thought there was a viewer for pix in brl-cad somewhere... |
| 05:55.39 | dtidrow | you would think there would be one, since .pix isn't a standard format |
| 05:56.28 | yukonbob | well, there are converters |
| 05:57.58 | dtidrow | there's probably a way to run the fb app and load a pix into that, I just don't know enough about brl-cad yet to do that |
| 05:58.19 | yukonbob | oh sure -- pix-fb |
| 05:58.29 | dtidrow | though "pix-png moss.pix > moss.png" works |
| 05:59.04 | dtidrow | well, I tried that first (pix-fb) - do you need an existing fb running? |
| 05:59.18 | dtidrow | wild guesses here ;-) |
| 05:59.40 | dtidrow | I'll just convert them to png's... |
| 06:05.42 | brlcad | pix-fb |
| 06:06.37 | brlcad | if you're pre 7.10.4, it's pix-fb -F/dev/Xl file.pix |
| 06:06.48 | brlcad | 7.10.4 and later, it's just pix-fb file.pix |
| 06:07.06 | brlcad | I made lingering default |
| 06:07.18 | dtidrow | ah - still have 7.10.0 |
| 06:07.53 | brlcad | you can run your own framebuffer server via fbserv, but that's mostly if you want to do multiple processing steps and/or read/write pixels instead of just display them |
| 06:08.25 | dtidrow | /dev/Xl? |
| 06:08.47 | brlcad | yeah |
| 06:09.12 | brlcad | that means use the "X framebuffer device" with the "l" linger option |
| 06:09.22 | brlcad | (nothing to do with the /dev filesystem) |
| 06:09.56 | brlcad | fun "fbhelp" and it'll describe what framebuffer devices you have available |
| 06:10.12 | dtidrow | ah - that's more like it |
| 06:10.41 | yukonbob | brlcad: do you think that syntax (/dev/Xl) is worth visiting, for it's confusion w/ /dev/ filesystems on *nix boxes, or would it be too big a deal wrt backward compat.? |
| 06:10.55 | brlcad | pix files are "raw" so if it's not the default 512x512, you have to specify dimensions |
| 06:11.25 | brlcad | yukonbob: backwards compat is the primary reason it's not changed |
| 06:11.27 | dtidrow | I just wanted to look at the results of the benchmark runs |
| 06:12.18 | dtidrow | yukonbob: yep, that's what I was thinking - didn't see 'Xl' in /dev anywhere... |
| 06:12.40 | brlcad | yukonbob: otherwise it would have likely changed a long time ago, and it's been a really minor point -- after you learn once and then you pretty much know |
| 06:13.08 | dtidrow | it's there to confuse n00bs.... |
| 06:13.10 | dtidrow | ;-) |
| 06:13.17 | brlcad | yeah, it's one of about a dozen of the FAQ newbie questions and areas of confusion that would be good to get rid of for 8.0 |
| 06:13.20 | yukonbob | brlcad: /me notes that Tcl has a "Tcl 9 wishlist" where wishes that will break backward compatibility are entertained -- perhaps something like that for BRLCAD 8? |
| 06:13.41 | brlcad | already have that wishlist, it's in the todo |
| 06:13.53 | brlcad | at least for the "important" ones |
| 06:15.29 | dtidrow | brlcad: 'rt' is the main raytracer executable, right? |
| 06:15.38 | brlcad | yukonbob: also plan to get started on some of those backwards-breaking topics on a branch after the move to svn |
| 06:15.42 | brlcad | dtidrow: yep |
| 06:17.11 | brlcad | lingering framebuffer windows was another FAQ newbie item that has been requested for about two decades... but I figured out a way to implement it and retain backwards compatibility, so it made the minor update |
| 06:18.25 | yukonbob | brlcad: /me was re-introduced to the "chromium" project again today -- you aware of it? |
| 06:21.05 | dtidrow | brlcad: http://www.yafray.org/ - any knowledge of this? |
| 06:23.42 | brlcad | yukonbob: hm, not intimately, but I was reading about them about a week or two ago |
| 06:24.00 | brlcad | dtidrow: quite familiar with yafray |
| 06:24.19 | brlcad | he's usually at siggraph |
| 06:24.19 | dtidrow | opinion/comments? |
| 06:25.20 | brlcad | it's a pretty decent optical renderer, really decent global illumination modes |
| 06:25.58 | brlcad | performance is a bit teh suck and it doesn't deal with solid geometry, but it does the trick for visualization purposes pretty slickly |
| 06:26.33 | brlcad | blender shelved their (horrible) ray-tracer for yafray a couple years ago |
| 06:26.38 | yukonbob | "doesn't deal w/ solid geom." -- you mean shooting rays and getting xrays, or collision detection? |
| 06:27.28 | brlcad | full shotline, proper inside/outside detection all the way along the ray -- for non-optical purposes |
| 06:28.12 | yukonbob | but it's an option for visually rendering, esp if one wants more than 16 light sources, correct? |
| 06:28.36 | brlcad | it's a great option for visual rendering |
| 06:29.27 | brlcad | for the new solid modeler interface, I'm hoping to sort out the interface so that different ray-tracers can be used -- yafray and povray would be near top of my list of the first to hook in |
| 06:29.41 | yukonbob | nice |
| 06:30.10 | dtidrow | what year did brl-cad get open-sourced, anyway? |
| 06:30.14 | yukonbob | would that be a batch-oriented .tmp files and call-out to the respective tracers, or linking them in as libs? |
| 06:31.19 | brlcad | dtidrow: we're about a week away from the three years anniversary |
| 06:31.53 | dtidrow | '04? hmmm, thought it was earlier than that |
| 06:32.06 | dtidrow | memory gets fuzzy with age... :-\ |
| 06:32.33 | brlcad | yukonbo: probably batch oriented with some sort of compiled plugin-in frontend that would have knowledge how to prepare/convert data into their format |
| 06:33.30 | yukonbob | brlcad: that was my first instinctual idea... |
| 06:33.36 | brlcad | as a lib would be possible, but probably a LOT more work |
| 06:33.45 | yukonbob | <PROTECTED> |
| 06:33.59 | yukonbob | povray == weird license because it's soo old. |
| 06:34.10 | brlcad | yeah, povray's a problem that way |
| 06:34.27 | yukonbob | batching makes sense for a few reasons, though... |
| 06:34.40 | brlcad | that may be a non-starter for povray, but that would be something to look into down the road |
| 06:35.49 | yukonbob | a g-pov, g-yafray, etc., etc. could potentially do the trick, and then let a person setup their own cameras/perspectives, no? |
| 06:37.07 | brlcad | yep |
| 06:38.09 | yukonbob | mmm... maybe my lex/yacc studies will lead to assiting on this... |
| 06:38.17 | brlcad | you can fake pipe's with other cylinders and torii |
| 06:38.21 | yukonbob | *assisting |
| 06:38.34 | brlcad | cool |
| 06:38.46 | yukonbob | brlcad: re: cylinders + torii, I guess that's where the heavy lifting occurs ;) |
| 06:40.34 | brlcad | povray's actually one of the closest matches to us |
| 06:40.57 | brlcad | since they do have many of the same implicits and actually do a lot of the same implicit evaluation |
| 06:41.11 | brlcad | they have a few we don't have, we have a few they don't have |
| 06:43.05 | yukonbob | pipe is esp vexing though, considering bending + radiuses (radii?), and growing/shrinking internal/external radiuses along the length of the pipe... |
| 06:44.04 | brlcad | the internal is really just a CSG subtracted inner-pipe |
| 06:44.18 | brlcad | so if you implement one, you have the same logic for the inside |
| 06:45.33 | yukonbob | right, but the differences between the transitions are nice + smooth, and still perhaps occurring around a bend, which would be like wrapping a truncated cone inside a bent cylinder/torus in povray.... |
| 06:46.23 | brlcad | povray has a tgc too iirc |
| 06:46.29 | yukonbob | how tough would it be to take the extrude 3d and make a lathe-like function for brlcad, a la povray? |
| 06:46.59 | yukonbob | re: tgc, but around a bend? |
| 06:47.09 | brlcad | bends are torus |
| 06:47.45 | brlcad | that's internally how our pipe does it -- tgc and torii segments |
| 06:48.25 | yukonbob | ok -- so can the inside dia. of a pipe change while it's bending a curve? |
| 06:48.41 | yukonbob | or outside, for that matter... makes no difference. |
| 06:49.15 | brlcad | I believe it can, but I frankly don't recall |
| 06:49.37 | brlcad | basically a more generalized torus form |
| 06:52.34 | brlcad | i know what you mean, it'd be a matter of seeing 1) if we allow the torus to "pinch" or not and if we do, how it's implemented and then 2) what that most closely translates to in pov |
| 06:53.21 | brlcad | for the most part, that would be very much an "edge" case that you could just check and say "oops, can't handle this" .. pipes with bend radius changes on the bend are not the common case |
| 06:53.34 | yukonbob | ... the whole idea (of various converters) sounds _really_ cool -- a good way to visit all the elems of BRLCAD, and see how other people are doing things, maybe refactor, etc., etc. |
| 06:54.31 | brlcad | yeah, one of my "big-idea" projects that I've been working towards is making a "universal converter" library given we support more formats than almost anyone except the commercial engines |
| 06:54.48 | yukonbob | librosetta |
| 06:55.08 | yukonbob | ^--- probably used by everybody else that thinks they're great translators ;) |
| 06:55.11 | brlcad | hah |
| 06:55.21 | brlcad | i have a stickie on my desktop with various names for the library |
| 06:55.21 | yukonbob | lol |
| 06:55.30 | brlcad | librosetta is one of them :) |
| 06:56.01 | brlcad | libbgc libgconv libg2g |
| 06:56.09 | yukonbob | heh -- we'll have to think of some more interesting obscure reference -- maybe one degree of seperation -- libdeadsea |
| 06:56.47 | yukonbob | ^--- add to stickies |
| 06:57.31 | brlcad | the only confusion with rosetta is the Mac OS X binary conversion layer of the same name |
| 06:58.07 | yukonbob | libdeadc, libdedc... |
| 06:58.30 | yukonbob | libdedc -- a bacronym -- DEcode Do Conversion |
| 07:05.06 | *** join/#brlcad louipc (n=louipc@bas8-toronto63-1088753883.dsl.bell.ca) |
| 07:08.17 | brlcad | TRCPY\|STRCSPN\|STRERROR\|STRPBRK\|STRRCHR\|STRSPN\|STRSTR\|STRTOK\)' |
| 07:12.03 | brlcad | (speeding up configure by eliminating tests we can (hopefully) now avoid) |
| 07:15.01 | brlcad | not one in use, sweet |
| 07:17.44 | brlcad | ahh, take that back .. culled too much |
| 07:30.26 | brlcad | nah, they're not expensive .. just c89 function calls that configure checks for which it doesn't need to for most of them |
| 07:30.34 | brlcad | the calls are just standard library calls |
| 07:37.52 | louipc | mornin |
| 07:54.42 | brlcad | howdy louipc |
| 08:02.47 | louipc | how are the plans for moving brl-cad to svn? |
| 08:19.54 | *** join/#brlcad Z80-Boy (i=clock@77-56-93-24.dclient.hispeed.ch) |
| 08:28.13 | yukonbob | nn #brlcad |
| 08:28.27 | louipc | bye |
| 08:32.55 | brlcad | louipc: erm, unchanged .. still going to happen |
| 08:34.22 | Axman6 | brlcad: isn't it supposed to be pretty easy? |
| 08:34.56 | louipc | hey have you guys ever used git? |
| 08:35.28 | Axman6 | git sounds... interesting |
| 08:35.40 | louipc | it's awesome |
| 08:36.04 | Axman6 | sounds like a nice idea, but not an idea that sits well in my brain |
| 08:36.14 | louipc | why's that? |
| 08:38.19 | louipc | git can kind of work with svn as well |
| 08:40.16 | Axman6 | i watched the google tech talk about it with linus. he's a nutjob |
| 08:40.37 | louipc | oh yeah haha |
| 08:43.26 | louipc | I like how you can go totally nuts with your local copy in git and commit, and merge branches, and it's OK nobody sees all that insanity from you if they don't want to |
| 08:45.30 | brlcad | Axman6: it's usually fairly easy, but certainly not turn-key .. especially for a repository as extensive as brl-cad's |
| 08:46.02 | brlcad | louipc: yes, and you've mentioned it .. like four times now? :P |
| 08:46.42 | louipc | i have? I must have mistaken this for another channel then doh |
| 08:47.36 | brlcad | git or not, distributed works well for some things and horrible for others |
| 08:48.03 | brlcad | it's far from a panacea |
| 08:48.12 | louipc | or I just have an odd memory |
| 08:48.32 | louipc | yeah true |
| 08:49.47 | brlcad | you could just as well argue that seeing that hiding that "insanity", as you put it, is very much a bad thing |
| 08:50.19 | brlcad | particularly if you're collaborating among few and keeping consensus on development directions |
| 08:51.03 | brlcad | you often *want* to see the steps taken to get to a given result, regardless of the method and num of intermediate steps |
| 08:51.05 | louipc | well what you should end up after the insanity is a clean straight-forward set of patches |
| 08:51.52 | brlcad | you end up with that end-result distributed or not -- the point is the desirability for seeing the steps that got you there too |
| 08:52.16 | brlcad | centralized encourages that transparency, distributed lets you hide it (or not) -- it's a tradeoff |
| 08:52.34 | louipc | yeah if there are only a few devs then they're probably going to want to see it anyways |
| 08:53.47 | brlcad | yep, very dependendent on the dev structure, number of devs, visibility and collaboration prefs, user-community expectations, etc |
| 08:55.06 | louipc | git doesn't work too well when the lead guy is too busy with other things and doesn't pull anything, when everyone else is hacking like crazy |
| 08:55.19 | brlcad | distributed really starts to pay off when the centralized structure becomes a bottleneck administratively (which usually happens after you have hundreds of devs) |
| 08:55.46 | Axman6 | like the kernel |
| 08:55.52 | brlcad | yeah, you can set up git in just as brain-dead development-hindering ways as a centralized repo :) |
| 09:19.34 | *** join/#brlcad CIA-29 (n=CIA@208.69.182.149) |
| 10:08.03 | *** join/#brlcad Elperion (n=Bary@p54876A3C.dip.t-dialin.net) |
| 14:31.28 | *** join/#brlcad CIA-29 (n=CIA@208.69.182.149) [NETSPLIT VICTIM] |
| 14:31.28 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) [NETSPLIT VICTIM] |
| 14:32.22 | *** join/#brlcad curious (n=curious@gjv234.internetdsl.tpnet.pl) [NETSPLIT VICTIM] |
| 14:32.22 | *** join/#brlcad alex_joni (n=juve@emc/board-of-directors/alexjoni) [NETSPLIT VICTIM] |
| 14:45.23 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 15:48.30 | *** join/#brlcad digitalfredy (n=digitalf@200.71.62.161) |
| 15:58.42 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-077-224.pools.arcor-ip.net) |
| 16:23.32 | *** join/#brlcad Z80-Boy (i=clock@77-56-75-155.dclient.hispeed.ch) |
| 16:57.48 | *** join/#brlcad docelic (n=docelic@212.15.184.167) |
| 17:21.03 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/src/libbu/parallel.c: raise() works on windows and is c89, so bye bye |
| 17:35.19 | *** join/#brlcad Elperion (n=Bary@p54876A3C.dip.t-dialin.net) |
| 17:56.58 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-093-241.pools.arcor-ip.net) |
| 18:02.38 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: raise() works on windows and is c89, so bye bye |
| 18:04.06 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: strdup and strsep don't seem to be c89 |
| 20:14.39 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/ (configure.ac src/libpkg/pkg.c): get rid of our single use of strerror_r, minimize checks |
| 20:30.13 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: |
| 20:30.15 | CIA-29 | BRL-CAD: remove a whole bunch of function checks that can be taken for granted since c89 |
| 20:30.17 | CIA-29 | BRL-CAD: provides for them. all of these functions are apparently not even used (any |
| 20:30.19 | CIA-29 | BRL-CAD: more) via HAVE_ decls regardless. removing the checks reduces configure time |
| 20:30.21 | CIA-29 | BRL-CAD: signficantly. function checks removed include atexit, fabs, floor, memchr, |
| 20:30.25 | CIA-29 | BRL-CAD: memmove, modf, pow, setlocale, sqrt, strcpy, strcspn, strpbrk, strrchr, strspn, |
| 20:30.27 | CIA-29 | BRL-CAD: strstr, strtol, strtoul, strtoull |
| 20:45.30 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: comment consistency |
| 21:10.20 | CIA-29 | BRL-CAD: 03brlcad * 10brlcad/configure.ac: list the POSIX.1 headers too for good measure |
| 21:18.46 | CIA-29 | BRL-CAD: 03bharder * 10brlcad/doc/book/VolumeIV.xml: Working with new processing to facilitate img handling, re-worked <link> and <xref>, minor formatting. |
| 21:30.00 | CIA-29 | BRL-CAD: 03bharder * 10brlcad/doc/book/VolumeIV.xml: Previous commit also re-worked the placement of authorship from <title> to <bookinfo> and the dedication from <prolog> to <dedication> -- not sure about the <author> change... will need to keep eye on this. |
| 21:32.32 | brlcad | woot |
| 21:37.16 | brlcad | if we get a hundred active devs, I'd be much more fond of it ;) |
| 21:38.21 | yukonbob | does Bob do his development on Windows, though? |
| 21:38.27 | brlcad | yep |
| 21:38.56 | yukonbob | so he'd have to use NFS, or FTP (or whatever) files to/from a POSIX box to use git. |
| 21:39.11 | brlcad | as do a couple devs in germany and netherlands |
| 21:39.44 | brlcad | daniel and wim |
| 21:54.28 | b0ef | how about bazaar? |
| 21:54.49 | yukonbob | isn't that deprecated, in favour of arch? |
| 21:54.58 | b0ef | heh, no |
| 21:55.03 | b0ef | bazaar-ng |
| 21:55.22 | b0ef | http://bazaar-vcs.org/ |
| 21:55.35 | louipc | ooer darn windows! |
| 21:59.17 | louipc | yeah I heard good things about mercurial too |
| 21:59.21 | *** join/#brlcad illethal (n=oden@c-69-137-199-63.hsd1.fl.comcast.net) |
| 21:59.24 | louipc | never used it though |
| 21:59.38 | illethal | Good evening everyone |
| 21:59.42 | brlcad | hello illethal |
| 22:00.04 | yukonbob | it's pretty simple... I use it instead of RCS for my local disk |
| 22:01.11 | yukonbob | hg init; hg add thisfile thatfile; [edit files]; hg commit |
| 22:01.44 | louipc | oh yeah I've heard syntax is similar to git |
| 22:02.15 | b0ef | that's how you do it in bzr, too |
| 22:02.15 | yukonbob | iirc, git uses lots of binaries to get it's job done... |
| 22:02.32 | b0ef | ya'll haven't watched the git video by linus? |
| 22:02.56 | yukonbob | where he calls the svn devs from google braindead? |
| 22:03.40 | b0ef | yeah;) |
| 22:03.40 | yukonbob | classy |
| 22:03.40 | b0ef | hehe |
| 22:03.40 | b0ef | <PROTECTED> |
| 22:16.41 | yukonbob | heh --- /me reads a mozilla developer blog where they were testing what vc to move to (from CVS) and importing the CVS tree->bzr took more than a *month* of running time... |
| 22:21.06 | louipc | ouch |
| 22:21.17 | louipc | they're moving to mercurial yeah? |
| 22:21.58 | yukonbob | are on it apparently, with plan to revisit the decision in 9-12 months (from March, I guess, when they moved). |
| 22:24.41 | brlcad | illethal: what brings you around? |
| 22:31.38 | illethal | Got interested in BRL Cad. |
| 22:31.39 | illethal | =) |
| 22:31.44 | illethal | I'm a 3D graphic artist though |
| 22:31.51 | illethal | BRL is a massive learning curve. |
| 22:32.12 | yukonbob | illethal: you have examples of your work online? |
| 22:33.12 | yukonbob | hrm... apparently FreeBSD is mercurial too... |
| 22:33.38 | illethal | Yeah. |
| 22:33.50 | illethal | http://micah.noobgrinder.com/3d/oden.jpg |
| 22:34.39 | b0ef | illethal: that looks excellent;) |
| 22:36.51 | b0ef | I'm a spline modeler, but since I went free software fanatic, there just aren't any free spline tools, so waiting for brl-cad;) |
| 22:37.26 | *** join/#brlcad Axman6_ (n=Axman6@210-9-138-35.netspeed.com.au) |
| 22:37.26 | illethal | Thanks |
| 22:37.27 | illethal | ! |
| 23:00.35 | *** join/#brlcad CIA-29 (n=CIA@208.69.182.149) |
