| 01:00.37 | *** join/#brlcad Mac- (TC430HX@bwv38.neoplus.adsl.tpnet.pl) | |
| 01:00.37 | Mac- | hi there |
| 01:00.37 | Mac- | i going to change my AutoCAD to BRL-CAD |
| 01:00.44 | Mac- | but under Linux Slackware |
| 01:01.22 | Twingy | cool |
| 01:03.09 | Mac- | but i have some questions |
| 01:03.20 | Mac- | i working on AMD K6-2 450MHz is it enough for BRL-CAD ? |
| 01:03.29 | Mac- | 256MB of RAM |
| 01:05.08 | Twingy | yes |
| 01:05.17 | Twingy | but you won't be able to work with anything significantly large |
| 01:05.41 | Twingy | you'll want 2GB to work on a vehicle that has complexity down to the nut and bolt |
| 01:05.58 | Mac- | 2GB of RAM ???? |
| 01:06.07 | Twingy | yes, that's standard where I work |
| 01:06.17 | Twingy | I just ordered a pair of machines with 8GB of ram 2 weeks ago |
| 01:06.29 | Mac- | no, i`m only student of mechanical engeenering division |
| 01:06.46 | Twingy | I'd seriously recommend spending $200 to upgrade to something faster |
| 01:06.55 | Mac- | on univeristy of minig and metallurgy in poland (Cracow) |
| 01:06.55 | Twingy | like a 1.5ghz walmart pc with 512MB |
| 01:07.40 | Mac- | now i working on 2D only |
| 01:07.42 | Twingy | then you might be able to work on some moderately complex geometry |
| 01:07.46 | Twingy | okie |
| 01:08.04 | Twingy | dinner time, bbl |
| 01:08.12 | Mac- | and what about hardware acceleration of graphic card ? |
| 01:08.16 | Mac- | is there any ? |
| 01:09.58 | Mac- | now i have S3 Savage4 AGP, but wish change to Matrox G200 AGP |
| 01:17.07 | brlcad | Mac-: that should be enough for very complex models regardless |
| 01:17.34 | Mac- | what does it mean 'very complex' ? |
| 01:17.42 | brlcad | 256MB that is .. like he said, to do an _entire_ vehicle down to the nut, bolt, and wire |
| 01:18.27 | Mac- | but is there hardware acceleration for some graphic cards ??? |
| 01:18.33 | brlcad | you should be able to deal with models that are at least 100 MB in size |
| 01:19.03 | brlcad | it is opengl accelerated by default, but perhaps not in the manner you're thinking |
| 01:19.29 | brlcad | it won't matter a whole lot what your video card is as (again by default), it's a wireframe display in mged |
| 01:19.47 | brlcad | your limits will be ray-trace time |
| 01:19.52 | Mac- | my models in AutoCAD had about less that 1MB :) |
| 01:20.02 | brlcad | yeah, those are "tiny" :) |
| 01:20.31 | brlcad | have you used mged at all? |
| 01:20.46 | Mac- | no |
| 01:21.03 | brlcad | autocad is mostly geared towards drafting whereas mged is geared towards csg-based solid modeling |
| 01:21.41 | brlcad | there is a sketch primitive type which will be very familiar to an autocad sketch, but mged's drafting capabilities are admitedly limited |
| 01:21.54 | brlcad | if you rebuild those models using csg, you'll be much better off |
| 01:22.10 | brlcad | should shrink the size of your models too |
| 01:22.21 | ctjctj | Mac, brlcad generates it's results on a pixel by pixel basis for the most part. So the raytracing part (making great images) requires very little in the way of a video card. The first time I used brlcad for image generation, my machine had 5MBs of memory, ran at just over 16Mhz and generated pretty dang good images. Oh the video card had less than 512Kbytes of ram. |
| 01:22.33 | Mac- | but for now i have been use of AutoCAD only in 2D |
| 01:24.15 | brlcad | brl-cad's mged is not well-suited for 2D-only ;) |
| 01:24.15 | brlcad | for 2D only, you might want to consider qcad |
| 01:24.15 | Mac- | BRL-CAD isn`t for flat drawing ? |
| 01:24.15 | brlcad | that said, I'd recommend trying out the mged tutorial provided on the website |
| 01:24.32 | brlcad | brl-cad/mged isn't a drafting tool, though it can do some limited drafting via the sketch primitive |
| 01:26.05 | brlcad | autocad is actually a "CADD" |
| 01:26.21 | brlcad | depending on whom you talk to at least ;) |
| 01:27.02 | Mac- | brl-cad is something like Inventor ??? |
| 01:28.40 | Mac- | ok, thx for your help |
| 01:28.42 | brlcad | yeah, that's a little bit closer comparison, though still not quite the same |
| 01:28.47 | Mac- | bye for now |
| 01:29.04 | brlcad | better would be pro/e and unigraphics |
| 01:29.08 | brlcad | cya |
| 01:29.26 | ctjctj | You are welcome, please feel free to come back or just to try BRL-CAD and see what it can do for you. |
| 01:29.51 | Mac- | i will try, promise :) |
| 01:30.07 | Mac- | bye |
| 01:30.32 | brlcad | ctjctj: surprisingly enough, CAM/NC milling is one of the active open-source interests that quickly sprung up :) |
| 01:31.08 | brlcad | there are several people interested in writing a g-gcode converter and other tools to add cam-capabilities |
| 01:32.19 | ctjctj | The thing I wanted to do with DB5 was to add some parametric capabilities to our databases. |
| 01:32.19 | brlcad | oh god yeah |
| 01:32.19 | brlcad | parametrics and constraints |
| 01:32.42 | ctjctj | I had my "joint" stuff working with XML for about 30 seconds before somebody foobared it again. :-( |
| 01:32.58 | brlcad | somebody foobared it? |
| 01:33.30 | brlcad | joint stuff hasn't changed in cvs in quite a while.. :) |
| 01:33.32 | ctjctj | Yeah, release cycle and an argument with somebody over which XML parser we should use. |
| 01:33.40 | brlcad | heh, somebody |
| 01:35.53 | brlcad | i haven't played with a joint db in a couple years |
| 01:36.07 | brlcad | dwayne gave a quick demo back then |
| 01:36.10 | ctjctj | I don't know if it ever worked while you have been on the project. |
| 01:36.20 | brlcad | it worked then |
| 01:36.45 | ctjctj | Well, It doesn't work in the 6.* and later 5.* releases. |
| 01:37.16 | brlcad | hrm |
| 01:37.38 | ctjctj | But with our modern machines, it should dang well fly. The iteritive solver I wrote didn't dare do an update per itteration, but today, with our desk top machines, it should be able to do smooth mged motion. |
| 01:37.39 | brlcad | the 'demo' was 6.x .. we did find a few bugs, but simple articulation worked |
| 01:38.22 | brlcad | maybe :) |
| 01:39.05 | ctjctj | It was nice to be able to send a single DB out with a joint file attached to reconfigure the model... |
| 01:39.27 | brlcad | I very recently tried a simple animation (sans joints, just simple camera rotation) only to find very very wacky things going on -- seemed like a bug in the tabinterp and other table tools |
| 01:39.37 | Twingy | o.O |
| 01:40.07 | brlcad | hmm.. would be trivial to embed the joint file into the .g as a binary object now |
| 01:41.18 | brlcad | I don't doubt it did work.. but I don't think it does right now -- I tried reproducing the exact steps in a published report only to get very different behavior |
| 01:41.31 | ctjctj | Hello Twingy, I'm Chris. |
| 01:41.35 | *** join/#brlcad louipc (~louipc@Toronto-ppp221609.sympatico.ca) | |
| 01:41.40 | louipc | hi there |
| 01:41.44 | brlcad | I believe it has a lot to do with the fact that quaternions are not dumped out in the saveview scripts instead of transformation matrices |
| 01:41.50 | brlcad | howdy louipc |
| 01:42.06 | brlcad | s/not dumped/now dumped/ |
| 01:42.23 | louipc | I've been looking for some decent CAD software for linux :D |
| 01:42.25 | ctjctj | Tabinterp doesn't care. It just does table interpulation. |
| 01:43.32 | louipc | well right now I'm just doing 2D but eventually I'll be drawing 3D solid models to use in CAM applications |
| 01:44.05 | ctjctj | brlcad, when we were using tabinterp, we'd dump a few keyframes, write a few scripts to extract the eye_pt and orientation, then plug those together in to a table which tabinterp would read. |
| 01:44.35 | brlcad | that's what I was doing |
| 01:45.18 | ctjctj | louipc, have you read any of the BRL-CAD documentation? I'm not sure it will do what you want it to do. |
| 01:45.36 | brlcad | like I said, I was following a set of published steps in a report -- it 'almost' would interp correctly, but it gave a slew of anamolies |
| 01:45.49 | louipc | I haven't read much |
| 01:46.32 | brlcad | like going berserk around 180 and 360 and fairly randomly jumping to a different Z elevation for lengths at a time |
| 01:47.11 | brlcad | louipc: there are tutorials and other documentation available at http://brlcad.org if you're interested |
| 01:47.15 | Twingy | ah, hi, am working on a circuit right now |
| 01:47.22 | ctjctj | louipc, BRLCAD is a solid modling system. It uses CSG to create complex objects. Since there is no explict surface representation, many standard algorithms for analysing models are not applicatlb.e |
| 01:47.57 | ctjctj | brlcad, what you describe sounds like euler angles going bonkers. |
| 01:48.09 | louipc | hmm I'll have to read more about it for sure |
| 01:48.38 | ctjctj | louipc, we'll be glad to help you, but we'd rather you be happy then upset if our software doesn't match your needs. |
| 01:49.20 | louipc | *grin* thanks I understand, I'm a pretty laid back guy so no worries |
| 01:51.07 | brlcad | several very good papers came out at this year's international shapes and solids conference |
| 01:51.26 | ctjctj | Cool. Who is current team leader? |
| 01:51.42 | brlcad | ... |
| 01:52.04 | brlcad | well, as far as I know it's unchanged for the near future |
| 01:52.31 | brlcad | though I'm the only one actually dedicated with a full man-year of time explicitly to brl-cad afaik |
| 01:52.47 | brlcad | yep |
| 01:55.56 | brlcad | getting the package open sourced was specifically for the purposes of keeping it alive regardless of the various personal and 'corporate' politics that might/could have otherwise killed it |
| 01:55.56 | louipc | # sing An Appropriate Skimmer |
| 01:55.56 | brlcad | at least now, I could quit and keep working on the package indefinitely ;) |
| 01:55.58 | louipc | oops sorry |
| 01:56.06 | louipc | ;) |
| 01:56.14 | brlcad | ~dict skimmer |
| 01:56.52 | louipc | I was looking up coolant skimmers for the CNC machine in the shop *Grin* |
| 01:56.56 | ctjctj | I figured as much. I tried to sign off on my stuff but the requirement to get it notarized slowed me down, then I was told it wasn't needed. I'm glad it was released in spite of my fumble. |
| 01:58.27 | brlcad | it only took what.. 4 or 5 years? that was a lot of continual pressing and meetings and e-mails and persistence ;) |
| 01:59.43 | brlcad | I think the package can really 'take off', it's very well poised for it |
| 01:59.49 | ctjctj | I think that something like 99% of my code was either public domain or given to the Army. So those should have been "ok". The other stuff had copyright requirements to announce my authorship when in verbose mode. |
| 01:59.50 | brlcad | mged's user interface is probably the largest detriment, windows support is probably the second (as much as I dislike and don't care about that platform) |
| 02:01.56 | brlcad | wrapper libraries :) |
| 02:01.56 | brlcad | like tk |
| 02:01.56 | brlcad | but not so fugly |
| 02:01.56 | ctjctj | This was using "glut" and it still was contaminated. |
| 02:02.42 | brlcad | mm, modern glut is interesting, but still not practical for large apps -- no threading and different event loop supports |
| 02:03.14 | ctjctj | Oh I understand that. Just found the fact that they used glut to only be about 50% of the solution. |
| 02:04.11 | brlcad | sdl, clanlib, and maybe gtk or qt are the few big packages I'd consider if starting over (unless the language was constrained to non-C/C++) |
| 02:06.03 | brlcad | the biggest decision is what to do about widgets -- go with a wrapper lib like sdl and qt provide using native widgets, draw your own and stick to just opengl, something else |
| 02:06.10 | ctjctj | I've not used SDL yet. I don't like QT but that's because I'm addicted to gnome. |
| 02:06.11 | brlcad | gtk is nice, though it's the least cross-platform of the bunch (at least in terms of even just supporting windows, linux, and mac) |
| 02:06.59 | brlcad | it'd work, but you have to wait for the gtk guys to fix/support the other platforms (which they seem to be _very_ slow at doing sometimes) .. like os x aqua support |
| 02:07.25 | brlcad | course one does have the source, so if it really was a problem.. |
| 02:07.34 | brlcad | but then the motivation for using any lib is to avoid that |
| 02:07.41 | ctjctj | Have you tried to fix anything in GTK? |
| 02:07.47 | brlcad | nah |
| 02:08.01 | brlcad | it's a large codebase, I try to avoid that ;) |
| 02:09.33 | ctjctj | Everything is three and four places removed from where I expect it to be. |
| 02:10.10 | louipc | hey... I don't know much about these things but is wxWigets something like these libraries you're mentioning? |
| 02:10.35 | ctjctj | Yes, it is louipc. |
| 02:10.52 | louipc | ah, is that one any good? |
| 02:11.33 | ctjctj | But, IMHO it goes in the wrong direction. It is more for moving windows apps to linux/unix than for moving in the other direction. And I believe ithas a license that isn't "wonderful". |
| 02:14.40 | louipc | ooh |
| 02:14.40 | brlcad | louipc, there's also the issue of context creation (the windows) and then there's widgets (buttons, dialogs, knobs, etc) -- wxwindows is poor on the prior, aimed mostly at the latter |
| 02:14.40 | brlcad | it also does a 'meh' job at the widgets themselves imo |
| 02:14.40 | ctjctj | For any windowing system, you have a couple of major components. "The event loop", "window control", and "objects/widgets" |
| 02:14.40 | ctjctj | The event loop is often the easiest to deal with. It normally has pretty direct translations, mouse buttons, mouse movements, key presses, and things like that. |
| 02:19.14 | louipc | hehe I did that in Java ages ago, "addMouseListener()" :P |
| 02:19.14 | ctjctj | The window creation is usually the hardest. It is so closely tied to the window system that it is easy for OS or window specific things to leak in to your generic window creation system. |
| 02:19.14 | ctjctj | I.e. "Hand the window creation function the X visual you want" or "use the hPallet when creating a window" |
| 02:19.14 | brlcad | my current "biased choice" or preference is to only rely on a framework for the window and opengl context creation -- then do everything else internally (draw one's own widgets) |
| 02:19.14 | brlcad | i.e. basically treat it like a game interface |
| 02:19.14 | ctjctj | Then you have the widgets. They define your programming paradime(sp). In addition, widgets ARE your look and feel, and if they aren't beautiful, people hate them. |
| 02:19.15 | louipc | that's a lot more work eh? |
| 02:19.15 | brlcad | gui/widgets are often the most time-intensive aspects |
| 02:19.15 | ctjctj | For example, MOTIF was the only game in town for high quality widgets for X Windows for many years. But because they were for pay, people left them behind till open-motif. But motif themes/widgets look boring and fugly by todays standards. |
| 02:19.15 | louipc | yeah for sure |
| 02:24.44 | brlcad | wooo.. damn that looks nice |
| 02:24.44 | brlcad | Twingy: the photon map rendering of moss completed :) |
| 02:24.44 | ctjctj | One of Mike's project's was the "Bump project" A virtual file system using tape backing. Mike had all the code done, kernel mods, userland mods. He built a generic set of scripts for the UI and tossed it over the fence. |
| 02:24.44 | ctjctj | Cray Research picked it up, put a new gui on it, broke the user land stuff, then sold it for lots and lots and then sold 1000s of systems just to do "file migration" |
| 02:24.44 | louipc | horrible |
| 02:24.45 | Twingy | heh |
| 02:25.35 | louipc | who |
| 02:25.42 | ctjctj | what? |
| 02:30.18 | brlcad | ctjctj: nice ;) |
| 02:31.55 | ctjctj | Max gave me a G5 with 0.5 terrabyte to work with. And a fibre channel interface. Seems he expects me to add a few more terrabytes to the system in the next few months... :-) |
| 02:36.59 | brlcad | we're supposed to meet with max "rsn" |
| 02:40.06 | brlcad | Twingy: http://ftp.brlcad.org/tmp/moss_pm.png |
| 02:40.06 | ctjctj | Good. I'll try to see if I can show up at the same time. |
| 02:40.06 | Twingy | a littler better |
| 02:40.06 | brlcad | heh |
| 02:40.06 | Twingy | you save the photon map this time? |
| 02:40.06 | Twingy | oh |
| 02:40.06 | Twingy | you said it didn't work |
| 02:40.06 | Twingy | *shrug* |
| 02:40.06 | brlcad | i did save it just in case |
| 02:40.06 | Twingy | the irradiance gathering on the other side of the box is bad |
| 02:40.06 | brlcad | that's supposedly a million photons |
| 02:40.06 | Twingy | near the corner |
| 02:40.06 | brlcad | i noticed |
| 02:40.06 | Twingy | that's part of the 'T' degeneracy |
| 02:40.06 | brlcad | the splotch up the side of the torus is wierd |
| 02:40.08 | brlcad | dunno if that's a reflection of the cone's top or something |
| 02:40.23 | brlcad | the color bleeding all turned out quite nicely, though |
| 02:40.48 | brlcad | that's a lot of shadow rays I threw at it |
| 02:41.15 | brlcad | you know.. that corner of the box shouldn't have anything to do with irradiance gathering |
| 02:42.15 | brlcad | or do you mean the boxes actual side facing away? |
| 02:44.16 | brlcad | Twingy, took 13 hours to fire those million global photons, 256 irradiance rays (most of the time processing the irradiance cache progress) |
| 02:45.23 | Twingy | rt.cx/~justin/images/moss_pm.png |
| 02:46.19 | brlcad | heh |
| 02:46.28 | brlcad | no? |
| 02:46.52 | brlcad | i'd expect you'd get photons reflecting between the box and the surface several times |
| 02:46.55 | Twingy | no, it's gathering past the box |
| 02:47.08 | Twingy | the box wasn't acting as a boundary for the irradiance gathering |
| 02:47.16 | Twingy | as it should be |
| 02:47.58 | Twingy | main reason why I dislike photon mappin |
| 02:48.00 | Twingy | g |
| 02:48.51 | Twingy | I mean |
| 02:48.58 | Twingy | it's better than ambient phong |
| 02:51.34 | Twingy | but it's still far from path tracing |
| 02:51.34 | brlcad | that it is |
| 02:51.34 | Twingy | if you're looking for something in between it's just fine |
| 02:51.34 | brlcad | should shove moss into rise and see what 13 hours can do |
| 02:51.34 | Twingy | 1 box or cluster? |
| 02:51.34 | Twingy | I have a utility now |
| 02:51.34 | brlcad | wopr |
| 02:51.34 | Twingy | g-adrt |
| 02:51.34 | brlcad | i noticed |
| 02:51.34 | Twingy | oh, give it 1 hour |
| 02:51.34 | Twingy | and you'd have almost perfect rendering |
| 02:51.34 | brlcad | g-adrt does a tesselation pass? |
| 02:51.34 | Twingy | no |
| 02:51.34 | Twingy | it expects bots |
| 02:51.34 | Twingy | I'd like to add auto tesselation into it at some point |
| 02:51.35 | Twingy | but it creats the adrt project framework |
| 02:51.36 | Twingy | you just need to be sure to position your camera and put a light source in the scene |
| 02:51.36 | Twingy | I don't have g-adrt pulling light source info from shaders |
| 02:51.36 | brlcad | moss's open-air wouldn't be an issue for the path tracer? |
| 02:51.36 | Twingy | just color |
| 02:51.40 | Twingy | nope |
| 02:51.42 | Twingy | no issue at all |
| 02:51.44 | brlcad | good |
| 02:51.51 | brlcad | i'll have to try it post-release sometime |
| 02:51.57 | Twingy | yep |
| 02:52.09 | brlcad | maybe whip up a quick tutorial |
| 02:52.26 | Twingy | after july 12 I can focus on making it a little less expert-friendly |
| 02:53.03 | brlcad | after july 12, it'll be siggraph prep time |
| 02:53.31 | brlcad | I should plan out some sort of schedule for the BoF |
| 02:53.41 | Twingy | yah |
| 02:54.11 | Twingy | how long is the bof? |
| 02:55.59 | brlcad | an hour |
| 03:02.19 | brlcad | ctjctj: for what it's worth, there's a BRL-CAD BoF at Siggraph this year "BRL-CAD: Open Source Solid Modeling" .. interesting to see what kind of response/interest there is |
| 03:02.19 | louipc | actually I think BRL-CAD is pretty much what I've been looking for, it has some features that I don't need but that's ok |
| 03:03.33 | louipc | I'd like to try adding some CAM extention to it |
| 03:04.00 | brlcad | ~seen clock |
| 03:04.00 | ibot | brlcad: i haven't seen 'clock' |
| 03:04.02 | brlcad | ~seen clock_ |
| 03:04.02 | ibot | brlcad: i haven't seen 'clock_' |
| 03:04.06 | brlcad | hrm |
| 03:04.26 | brlcad | louipc: that would be very cool |
| 03:05.08 | ctjctj | brlcad, I wish I was going to SIGGRAPH. Every year I put it in the budget and every year something comes up. |
| 03:05.19 | brlcad | louipc: most interesting would probably be either mged extensions and/or a new tool for converting geometry to machining code |
| 03:06.11 | ctjctj | It would be interesting to see if using NMGs to get a surface representation which could then be used to feed a CNC... |
| 03:06.17 | louipc | yeah that would be the first step |
| 03:07.33 | ctjctj | Part of the fun will be adding the "tweeks" needed to convert a virtual object to a real object. Such as the fact that pro/e, by default, slightly slopes sides for "better mold release" and other things like that. |
| 03:10.49 | brlcad | bah, let'em turn the cnc upside down and shake it ;) |
| 03:11.13 | brlcad | then put "crane required for proper operation" in the docs |
| 03:12.49 | ctjctj | I attended a pro/e demo a couple of years ago. Most of the stuff they had was about turning pretty math into ugly reality. Things like describing the radius of the "line" where a cylendar joined a plate. In math terms, that's a right angle, but in cnc terms, there is a little rounding that happens there. On purpose. To keep the strength of the join up. |
| 03:12.58 | ctjctj | Otherwise things break at the joint... :-( |
| 03:14.31 | ctjctj | think of dropping a RCC against a ARB8. Then drop a torus around the RCC such that the center of the major axis was at the surface of the arb8 and the major radius was equal to the major radius of the RCC. |
| 03:14.47 | brlcad | yep |
| 03:15.31 | brlcad | that's interesting .. hard to intuit |
| 03:15.36 | ctjctj | Except that there is a limit on the size of the torus, otherwise the angle is to steep, so they actully make the torus a little smaller and bury it a little deeper. And pro/e has 100s or 1000s of these sorts of rules. |
| 03:16.40 | brlcad | there's a new primitive that I've been dying to add ever since I got started on the super ellipsoid |
| 03:16.48 | brlcad | a sweep primitive |
| 03:17.04 | brlcad | that would solve the curvature on curvature problem we currently have |
| 03:17.34 | ctjctj | Then you add the external analysis program to do things like "fluid flow under pressure" to allow them to verify that the thing just created can be created by injection molding or hot metal or what ever. It was impressive. |
| 03:18.04 | brlcad | e.g. take your RCC against and ARB8 example and make it RCC against RCC .. we can't model a blend on that seam continuously |
| 03:18.11 | brlcad | we could with a sweep primitive |
| 03:19.07 | ctjctj | The down side? Pro/e had a hard time displaying anything much bigger than a widget. I think they were using an O2 and wouldn't show us a complete cylender head, much less a complete engine or vehicle. |
| 03:19.38 | brlcad | yeah.. a sweep primitive would give springs too |
| 03:19.55 | ctjctj | I'm still impressed with P.T.'s math for the particle solids. |
| 03:19.56 | brlcad | heh, pro/e's a dog still on large models |
| 03:20.44 | ctjctj | Did you hear I did a brlcad movie a couple of years ago? Had about 3 billion solids in the database. |
| 03:21.36 | brlcad | the missile fly through? |
| 03:22.09 | brlcad | i did see a missile movie, but maybe not the finished |
| 03:22.25 | ctjctj | Nope, it was a helo fly through of fort AP Hill. Near the drop zone. sound track was "low rider" and "danger zone". |
| 03:22.36 | brlcad | ahh, don't think so |
| 03:22.45 | brlcad | releasable? :) |
| 03:23.23 | ctjctj | Started with the helo at altitude of about 2000 meters, did a slow slant into a near target indicator, then did nape of the ground (1-2 meters) till egress. |
| 03:23.44 | brlcad | using tabinterp? :) |
| 03:24.40 | ctjctj | I don't remember the size of the terrain, but I had 1/2 million trees planted correctly. |
| 03:25.58 | *** join/#brlcad Pimpi (~frank@p54818D69.dip0.t-ipconnect.de) | |
| 03:26.05 | ctjctj | Is there anybody else that's real in this channel? |
| 03:26.26 | brlcad | yep, only three aren't real |
| 03:26.46 | ctjctj | ibot, archivist and CIA-5? |
| 03:26.48 | brlcad | though we all idle differently |
| 03:26.58 | brlcad | sorry, 4 |
| 03:27.12 | brlcad | ChanServ, CIA-5, ibot, TheLastSpartan (usually known as guu) |
| 03:27.41 | brlcad | several timezones represented |
| 03:27.57 | ctjctj | I can see that. |
| 03:28.20 | ctjctj | I've been missing Mike and the CAD team a lot these last few weeks. |
| 03:48.40 | brlcad | here's the list if you happen to know where any of the folks under "To Be Filed" fall |
| 03:48.43 | brlcad | http://cvs.sourceforge.net/viewcvs.py/brlcad/brlcad/AUTHORS?rev=HEAD |
| 03:49.59 | brlcad | they're "at least" special thanks .. main question is whether they submitted code, whether it was substantial, etc |
| 03:50.09 | brlcad | to be filed is at the end |
| 03:50.10 | ctjctj | correction: CTJ: Paladin Software with out an "inc" and before JRMTech, please. |
| 03:50.44 | ctjctj | And Cray Research, Inc before Geometric Solutions, inc. |
| 03:51.25 | ctjctj | Reed, Jr., Harry was the head of the BRL, NOT a member of Geometric solutions. |
| 03:53.10 | ctjctj | And the special thanks Reed, Harry needs a JR. |
| 03:53.36 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: add cray research and reorder affiliations for johnson |
| 03:53.36 | ctjctj | Adam Dray from geometric solutions, inc. He is also a code contributor. More than special thanks. |
| 03:53.49 | brlcad | hrm, I swear someone corrected me differently re reed |
| 03:54.02 | ctjctj | John Ousterhout is the author of TCL/Tk. |
| 03:54.26 | ctjctj | Harry Reed, Jr is the ELDER of the two and was the head of the BRL. |
| 03:54.34 | brlcad | yeah, though tcl/tk isn't an affiliation :) |
| 03:55.04 | ctjctj | Harry Reed NO JR, is the younger and contributed both as a member of BRL and Geometric Solutions. |
| 03:56.02 | ctjctj | John K. Ousterhout is founder and CEO of Electric Cloud, Inc. |
| 03:56.28 | brlcad | if I'm not mistaken, though -- his 'contribution' was not through that affiliation, he was self-consulted |
| 03:56.39 | brlcad | s/consulted/consulting/ |
| 03:57.07 | brlcad | where does dray fall in the timeline? |
| 03:57.16 | brlcad | names are listed cronologically |
| 03:57.18 | ctjctj | Adam worked for me at GSI. |
| 03:57.44 | ctjctj | John Ousterhout did tcl/tk at U.C. Berkeley. |
| 03:57.47 | brlcad | we have all the gsi modifications now, btw |
| 03:58.00 | ctjctj | Great! |
| 03:58.24 | ctjctj | I know david becker. I think he was Cray Research. |
| 03:58.25 | brlcad | and a few of the pretty models.. which the air force is being a pain about |
| 03:58.47 | ctjctj | The air force should be a pain about some of those models. |
| 03:59.36 | brlcad | some of them, but not one in particular |
| 03:59.50 | brlcad | trying to get release authority approval for it, still pending |
| 03:59.50 | ctjctj | Bob Miles is one of the original bunch of people Mike gathered in the lab in 394. He was famous for "It compiles,ship it" and then going on vacation. |
| 04:00.04 | brlcad | hehe |
| 04:00.24 | ctjctj | MMDF was one of the places Bob worked on. |
| 04:00.53 | ctjctj | Musgrave worked with us through Max. So that would be about the time Lee was going back to school. |
| 04:01.17 | ctjctj | Sorry, Let me see, years fly by so fast when you are having fun. |
| 04:01.24 | brlcad | before reschley? |
| 04:02.01 | ctjctj | Adam Draw was post Sue Muuss and long after Reschley. Remember that Reschley was also part of the 2nd group in to the 394 lab. And stayed on in part till very near the end. |
| 04:02.30 | ctjctj | I'd guess that adam was around 1995 time frame. And only there for a year or so. |
| 04:03.14 | brlcad | hmm.. perhaps before laut then |
| 04:03.18 | ctjctj | I know George E Toth but didn't meet him in person. Is Dave Rodgers in that list? |
| 04:03.48 | ctjctj | Wolff was part of the original team then went off to head up the NSF Internet. |
| 04:04.13 | brlcad | no rodgers listed |
| 04:05.14 | ctjctj | He needs to be added under mathmaticl help and is attributed as US Navel Acadamy |
| 04:05.29 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: swap the harry reeds (yet again?), dray was with gsi and contributed significant amounts of code |
| 04:05.46 | brlcad | wolff or rodgers? |
| 04:05.58 | ctjctj | Dave Rodgers is math from USNA |
| 04:06.33 | brlcad | before darisson? |
| 04:06.38 | brlcad | er, davisson |
| 04:07.29 | ctjctj | I meet Dave Rodgers in the early 90's and he'd been working with Mike for years at that point. Dave Rodgers wrote a book with a title simular to "Math for computer graphics" |
| 04:07.48 | ctjctj | I'd put Dave Rodgers after Ed Davisson. |
| 04:08.22 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: added david rodgers of usna for providing mathematical support |
| 04:08.31 | brlcad | Ed's pretty cool to work out math problems with |
| 04:08.46 | ctjctj | One of David Rodger's books has an image that Mike rendered for a cover. |
| 04:08.53 | brlcad | I go to him whenever I get stuck on some math formulation |
| 04:08.58 | brlcad | which seems to happen a lot |
| 04:09.21 | brlcad | oh, that's neat |
| 04:09.27 | brlcad | that'd make for a good plug |
| 04:09.29 | ctjctj | Yep, I like Ed. One of the shitty things about being "the expert" for my team is that I don't have the math back up I need. |
| 04:12.23 | ctjctj | I can't find George E. Toth on google. :-( |
| 04:14.29 | brlcad | where does miles fit in the special thanks list? |
| 04:14.48 | brlcad | before jill? |
| 04:14.58 | ctjctj | Yes, long before Jill. |
| 04:15.28 | ctjctj | Jill Smith came in as team leader around 1988-1989. Bob Miles left BRL before then. |
| 04:16.13 | ctjctj | that's a bad date for Jill's first interactions with BRLCAD |
| 04:16.44 | ctjctj | Let me see, Weaver, Dietz and Mike were the first ones. |
| 04:16.52 | brlcad | jill, zumbrunnen, monk, and all of cecom where shoe-horned in "somewhere" |
| 04:17.17 | ctjctj | Zum Brunnen was GSI time frame. Same time as Adam Dray. |
| 04:17.56 | brlcad | cept they're in different lists |
| 04:18.55 | ctjctj | Sean, I'm sorry, in my head they go "Jill showed up before I left cray. Adam and Zum Brunnen were after I divorced Gwen." but I don't have any dates to put to those events. :-( |
| 04:20.52 | brlcad | hehe |
| 04:22.50 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: miles sneaks onto the special thanks list, becker was reportedly with cray research |
| 04:24.27 | brlcad | 18 left to be filed, not too shabby |
| 04:25.08 | ctjctj | I'm trying to remeber if Terry Slattery was contributing to BRLCAD or just Bump. |
| 04:27.47 | ctjctj | I think that George E. Toth was a BRL person. |
| 04:29.03 | brlcad | i know a lot of the remaining, if not most all of them are just special thanks -- folks he talked to or that worked with someone on the team |
| 04:29.12 | brlcad | or managerial support of some sort |
| 04:30.51 | brlcad | when the new website comes on-line, i'd like to give a little more historic detail about the key contributors somewhere on it |
| 04:31.19 | brlcad | the 4 bins don't do some of those names justic |
| 04:31.23 | ctjctj | I'll do what I can do to help. |
| 04:36.39 | brlcad | I'm planning on writing a technical paper on the history of brl-cad here at some point (maybe while I'm at siggraph if I can) |
| 04:36.59 | brlcad | from inception to open source |
| 04:37.34 | Twingy | sean, when you back at work? |
| 04:37.38 | Twingy | I was gonna call judy |
| 04:37.47 | brlcad | probably would appreciate some degree of input/contribution for it |
| 04:38.07 | brlcad | if you'd be willing, that is |
| 04:38.08 | ctjctj | I'll try to hang here a bit more, if that will help. |
| 04:38.31 | brlcad | Twingy: judge judy? |
| 04:38.36 | brlcad | oh, office lady |
| 04:38.53 | brlcad | Twingy: I'm there now, but won't/shouldn't be tomorrow |
| 04:39.51 | brlcad | ctjctj: that would definitely help (on many levels) ;) |
| 04:41.21 | brlcad | oh, speaking of open source brl-cad adoptions.. this is one of the more recent and very neat projects: http://ronja.twibright.com/ |
| 04:42.24 | brlcad | he provides drawings, instructions schematics for making those point to point optical datalink connections, made .g's http://ronja.twibright.com/3d/ |
| 04:42.58 | brlcad | those are brl-cad renderings too, btw |
| 04:43.57 | brlcad | if clock ever shows up, he's always happy to talk about it in detail :) |
| 04:46.13 | ctjctj | Looks neat. |
| 04:48.08 | brlcad | currently at 96 sites around the world (albeit most are in czech repulic and most somewhere in europe) |
| 04:49.15 | ctjctj | I would have loved something like that a few years ago. How do you get 10mbit/sec across a road? |
| 04:51.45 | Twingy | pringles can |
| 05:02.40 | ctjctj | What is surprising Pimpi? |
| 05:03.44 | Pimpi | [5:28] * brlcad pokes Pimpi to wake u p |
| 05:04.52 | Pimpi | ouch |
| 05:05.11 | ctjctj | Well, I'm going to head off to bed. Night all. |
| 05:05.14 | brlcad | ahh, i guess that was a bit early for you ;) |
| 05:05.16 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/ged.c: dang it, nfds is off by one -- check our own pipe fd ya dolt. |
| 05:05.18 | brlcad | cya ctjctj |
| 05:08.04 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/src/mged/ged.c: cull the blocking read now that select is selectively selecting appropriately |
| 05:09.25 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/TODO: fixed mged backgrounding when parent quickly fails |
| 06:08.59 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/AUTHORS: toth was possibly BRL |
| 11:00.49 | *** join/#brlcad phcoder (~phcoder@pcp0011642003pcs.aberdn01.md.comcast.net) | |
| 11:06.39 | *** join/#brlcad archivist__ (~archivist@host217-35-76-52.in-addr.btopenworld.com) | |
| 13:14.26 | *** join/#brlcad clock- (clock@twin.jikos.cz) | |
| 15:06.05 | CIA-5 | BRL-CAD: 03twingy * 10brlcad/src/adrt/libtie/tie.c: experimenting with more efficient BSP building methods. |
| 15:10.42 | *** join/#brlcad Twingy_ (~justin@pcp0011647505pcs.aberdn01.md.comcast.net) | |
| 16:06.27 | *** join/#brlcad archivist_ (~archivist@host217-35-76-52.in-addr.btopenworld.com) | |
| 16:29.51 | ctjctj | Hey, do we have a document describing the changes made to the directory structure from before the src's were in the src subdirectoryl. |
| 16:48.06 | learner | hmm, some of the directory structure is covered in the HACKING file |
| 16:49.44 | learner | for the most part, the directories simply moved to src/ if they contained source or src/other/ if it was not our code |
| 16:50.44 | learner | h/ was renamed to include/ |
| 16:51.11 | learner | other than that, all the directories should pretty much be intact |
| 16:51.43 | learner | there was no combining/splitting as part of the process |
| 16:59.33 | CIA-5 | BRL-CAD: 03brlcad * 10brlcad/HACKING: mr. jackson of gov computer news has requested to be updated on new releases of BRL-CAD |
| 17:00.29 | ctjctj | Thanks. I'm going to take a look at what it takes to drop the new g_bot.c into the code. |
| 17:02.27 | learner | ahh, that much I know fairly well having been the last person to add a new primitive |
| 17:24.13 | learner | here's a quick summary http://ftp.brlcad.org/~sean/superell.html |
| 17:27.44 | *** join/#brlcad ctjctj (~ctj@192.55.203.132) | |
| 21:39.34 | CIA-5 | BRL-CAD: 03twingy * 10brlcad/src/conv/g-adrt.c: adding region map support. |
| 21:53.39 | *** join/#brlcad EricWilhelm (~ewilhelm@pool-71-111-56-148.ptldor.dsl-w.verizon.net) | |
| 23:00.47 | *** join/#brlcad cad427 (~d91bb843@bz.bzflag.bz) | |
