| 00:08.05 | CIA-65 | BRL-CAD: 03brlcad * r33524 10/brlcad/trunk/TODO: getting incrTcl subconfigure to work would be kind of a waste of time given how much it's radically changed for the pending 4.0 release that has a drastically changed build system. |
| 01:45.50 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 02:32.12 | yukonbob | hey cadheads |
| 02:35.55 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-205.sbndin.btas.verizon.net) |
| 02:38.20 | bjork_ | such a word exists? |
| 02:43.48 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1178014879.dsl.bell.ca) |
| 02:54.13 | brlcad | apparently ;) |
| 03:48.44 | brlcad | struggles to find a way to make incrTcl work with system tcl/tk |
| 04:10.54 | Ralith | suggests bribery |
| 04:15.15 | brlcad | has a plot developing |
| 04:36.48 | Twingy | PEANUT BUTTAH JELLY TIME!@! |
| 05:00.55 | brlcad | peanut buttah jelly with a baseball bat! |
| 05:02.20 | poolio | Heh, I have a friend who dressed up in a banana suit and went around singing that for halloween :) |
| 05:02.44 | brlcad | hehe |
| 05:15.30 | Twingy | polishes up gcam for release tomorrow |
| 05:18.28 | DanielFalck | hey Twingy, what's new in gcam? |
| 05:18.53 | Twingy | DanielFalck: hi |
| 05:19.37 | DanielFalck | Twingy: does it run under Mac OS X? |
| 05:20.24 | Twingy | no more cut/paste/move prev move next, replaced with drag and drop in treeview, object picking in 3D window, material origin selection, improved pocketing code, several bug fixes, flip direction, and adding helical tool paths in sketches atm |
| 05:20.39 | Twingy | DanielFalck: yea, if you have gtk + gtkglext + opengl |
| 05:20.59 | DanielFalck | ok, I might be able to get them installed here |
| 05:21.18 | Twingy | after I get ubuntu .deb package done I need to talk to emc guys to get it onto live CD |
| 05:21.24 | Twingy | after that I need to update the manual |
| 05:22.20 | DanielFalck | I have gtkglext1 in fink, cool |
| 05:22.39 | Twingy | after that I am extending the Y axis on my mill an extra 4 inches, machining out a new bedway and rails |
| 05:23.00 | Twingy | I need to be able to cut 9" diameter for a vacuum chamber I'm working on |
| 05:23.27 | DanielFalck | 9" diameter what? |
| 05:23.34 | Twingy | circle |
| 05:24.44 | DanielFalck | in aluminum? |
| 05:25.04 | Twingy | acrylic, the bed way is T-6061 aluminum, the rails are T-306 stainless |
| 05:25.45 | Twingy | then I am junking the 1/4 HP AC motor for a 3-phase brushless |
| 05:25.54 | Twingy | much smaller and more efficient |
| 05:26.05 | Twingy | and I can wire speed controller into the xylotex for digital control |
| 05:27.43 | Twingy | I've had about 20 orders come to the house in the last month |
| 05:29.33 | DanielFalck | you make vacuum chambers commercially? |
| 05:30.40 | Twingy | no no, this is for a flywheel project I'm doing |
| 05:30.48 | DanielFalck | oh, ok... |
| 05:32.50 | Twingy | hopefully another 9 months doesn't go by before the next release |
| 05:33.49 | DanielFalck | do you have dxf import in gcam? |
| 05:34.31 | Twingy | that's next ver |
| 05:34.45 | Twingy | I've got all the contouring algorithms done when I did the RS274X code |
| 05:34.53 | Twingy | so it should be fairly painless |
| 05:35.23 | Twingy | I just don't want to get bogged down in writing too much software in one stint |
| 05:35.39 | DanielFalck | do you do offset contour pocketing? |
| 05:35.39 | Twingy | gcam is second to my projects |
| 05:35.58 | Twingy | the contour pocketing is in the same boat, the algorithms are there I just haven't tied them into the sketches yet |
| 05:36.33 | Twingy | there's a ton of low hanging fruit in gcam right now, just limited amount of time to do stuff |
| 05:36.37 | DanielFalck | I've been told that the algorithms for pocketing are pretty hard |
| 05:36.57 | DanielFalck | I might be wrong... |
| 05:38.47 | Twingy | well zig zag is trivial, it's just horizontal lines with a finish pass |
| 05:39.06 | Twingy | there are papers on the contouring, but honestly it's not as complicated as people make it out to be |
| 05:39.08 | DanielFalck | how about offset contour with islans? |
| 05:39.16 | DanielFalck | islands- |
| 05:39.28 | Twingy | exactly, so I have an algorithm that does line/line line/arc arc/arc intersections |
| 05:39.29 | DanielFalck | that's the one everyone seems to avoid |
| 05:39.44 | Twingy | and I can set a negative offset and perform the intersections |
| 05:40.02 | Twingy | once the offset gets to a point where 0 area exists then it's done |
| 05:40.37 | Twingy | so it's basically just a for loop calling this function over and over decreasing the offset by the radius of the end mill |
| 05:40.58 | Twingy | and the islands just form as a result of the intersections |
| 05:41.30 | Twingy | all that intersection code was kind of a headache to write, but it has so much application |
| 05:41.47 | DanielFalck | I hope you get that one going. Nobody else seems to be working on it in the OS world |
| 05:42.19 | Twingy | I put in a formal application to GNU community for GNU approval |
| 05:42.32 | Twingy | I think it has enough critical mass to be looked at seriously |
| 05:43.06 | Twingy | and I think once the contour pocketing and STL/DXF is done it's going to put a number of those less $100 software packages out of business |
| 05:43.09 | DanielFalck | what does the GNU approval do for the project? |
| 05:43.22 | Twingy | it means that if you log into the gnu ftp site you'll see gcam there |
| 05:43.27 | DanielFalck | ok |
| 05:43.34 | DanielFalck | just like gcc |
| 05:43.37 | Twingy | right |
| 05:43.43 | Twingy | it'll probably be real close to gcc :) |
| 05:44.20 | Twingy | they advocate using guile for the development environment but we'll see about that :) |
| 05:44.22 | DanielFalck | yes |
| 05:45.01 | Twingy | I just keep chipping away at it |
| 05:45.24 | Twingy | I worked on large software project before this called Nurbana, but I am now convinced I lost interest because I didn't use it in my projects |
| 05:45.34 | Twingy | I am using GCAM on a weekly, some times daily basis |
| 05:45.40 | Twingy | it's the perfect synergy |
| 05:48.27 | DanielFalck | fink didn't have gtk+2.10 , so I'm downloading something from the Gtk+ site for os X now |
| 05:48.30 | DanielFalck | 2.14 |
| 05:50.07 | Twingy | ah |
| 05:50.16 | Twingy | what did it have? |
| 05:50.22 | DanielFalck | 2.6.10 |
| 05:50.31 | Twingy | oh wow, that is ancient |
| 05:50.37 | Twingy | that is like 5 years old |
| 05:50.45 | DanielFalck | yeah, fink is really old in the tooth |
| 05:51.06 | Twingy | that came out long before dapper drake |
| 05:51.14 | DanielFalck | it's been several years since I've used a mac at home and Linux is much nicer for source code |
| 05:51.27 | Twingy | I jut got a black berry with blue tooth modem tethering |
| 05:51.28 | DanielFalck | I'm using Ubuntu 8.04 on this box |
| 05:51.32 | Twingy | I set it up on my mac in like 30 seconds |
| 05:51.44 | Twingy | I can surf the net at about 1Mb now anywhere |
| 05:52.08 | Twingy | works from ubuntu as well |
| 05:52.14 | Twingy | I love it |
| 05:52.52 | Twingy | I got a little USB thing http://www.cirago.com/images/bluetooth/Cirago_BTA3210_2.jpg |
| 05:53.00 | Twingy | I can plug it into desktop computers and they can surf the net too |
| 05:53.54 | Ralith | Twingy: oo, you're the gcam guy? |
| 05:54.02 | Twingy | Ralith: yes! |
| 05:54.17 | Ralith | how hard do you think it would be to add fused deposition modelling support? |
| 05:54.34 | Twingy | you just need a command to turn the head on and off right? |
| 05:54.50 | Twingy | and it's an additive process instead of subtractive |
| 05:54.51 | Ralith | as far as tool control? yeah |
| 05:55.03 | Twingy | right? |
| 05:55.06 | Ralith | yes |
| 05:55.10 | Twingy | should be trivial |
| 05:55.12 | Ralith | that's the bit I'd expect to cause probl-- |
| 05:55.14 | Ralith | awesome! |
| 05:55.33 | Twingy | in terms of rendering the final object I just invert the bit on the voxels |
| 05:55.38 | Twingy | so they appear instead of dissapear |
| 05:55.52 | Ralith | what sort of files can gcam take? |
| 05:56.06 | Twingy | Ralith: only gerber files for circuit boards, next version will have DXF/STL stuff |
| 05:56.15 | Twingy | version after that I plan on support 4D and 5D mills |
| 05:56.31 | Ralith | er, you have (and have had for a long time) screenshots w/ 3D stuff |
| 05:56.53 | Twingy | there will be a few minor releases in bewtween the next two major releases |
| 05:57.07 | Twingy | to improve performance and 3D rendering I think |
| 05:57.15 | Ralith | so 3D is not actually currently supported? |
| 05:57.19 | Twingy | it is |
| 05:57.27 | Ralith | how, if all you can take is gerber? |
| 05:57.27 | Twingy | wire frame and voxel view |
| 05:57.42 | Twingy | the rendering is done based on the tool paths and a hunk of material in gcam |
| 05:57.50 | Twingy | it mills away material |
| 05:57.55 | Twingy | you click render and you see the final part |
| 05:58.00 | Ralith | er, doesn't gcam generate the toolpaths? |
| 05:58.02 | Twingy | yes |
| 05:58.10 | Twingy | but you can preview what your part will look like |
| 05:58.14 | Ralith | what does it generate the toolpaths from? |
| 05:58.24 | Twingy | it's coarse, but it's a good way of checking before you cut it out |
| 05:58.33 | Twingy | the tool paths come from my libgcode |
| 05:58.39 | Twingy | it's thousands of lines of code |
| 05:58.45 | Ralith | where does it get the information with which to generate the toolpaths |
| 05:58.49 | Ralith | it's not telepathic |
| 05:59.07 | Twingy | the GUI, you create sketches, bolt holes, drill holes, etc |
| 05:59.17 | Twingy | you see it in wire frame |
| 05:59.26 | Ralith | so it can't import models at all? |
| 05:59.35 | Twingy | only gerber right now |
| 05:59.41 | Ralith | gerber doesn't do models |
| 05:59.41 | Twingy | next version will be dxf/stl |
| 05:59.42 | Ralith | it does PCBs |
| 05:59.45 | Twingy | correct |
| 05:59.51 | Ralith | so it can't import models. |
| 05:59.57 | Ralith | damn. |
| 06:00.16 | Twingy | it's already in bugzilla as a feature request |
| 06:00.27 | Ralith | no plans for including BRL-CAD databases in the list of supported formats in the near future? |
| 06:00.42 | Twingy | supporting brl-cad would be quirky |
| 06:00.54 | Twingy | you would be better off exporting dxf/stl from brl-cad |
| 06:01.13 | Twingy | assuming brl-cad dxf/stl is working now |
| 06:02.39 | Twingy | just to give you an arbitrary date, let's say beginning of summer for dxf/stl support |
| 06:05.33 | Ralith | exporting STL is lossy |
| 06:05.45 | Ralith | you can't represent anything smooth |
| 06:08.09 | Twingy | right, but keep in mind gcode natively only supports lines and arcs |
| 06:08.57 | Twingy | some of the objects in brl-cad could be turned into piece wise arcs, but for the most part it will have to be tesselated anyway to get into arcs or lines |
| 06:09.04 | Ralith | stl doesn't support arcs. |
| 06:09.14 | Twingy | exactly |
| 06:09.20 | Twingy | so if brl-cad has a nurbs surface |
| 06:09.33 | Ralith | it can be much more closely approximated with arcs than with lines. |
| 06:09.46 | Twingy | the spline will have to undergo decomposition into bezier curves, then into bernstein polynomials, then into arcs |
| 06:09.52 | Ralith | or, at worst, approximated with similar accuracy with much less data. |
| 06:10.36 | Twingy | it would be a great deal of code to recognize the 20 or 30 primitives in brl-cad and figure out how to decompose those into arcs properly |
| 06:10.56 | Twingy | especially with boolean operations |
| 06:11.19 | Twingy | brl-cad ray traces the CSG to get the final result |
| 06:11.29 | Ralith | and you could take advantage of that raytracing. |
| 06:11.38 | Twingy | and ray tracing is tesselating |
| 06:11.40 | Ralith | you don't have to reinvent the wheel. |
| 06:11.53 | Twingy | how is ray tracing different from tesselating? |
| 06:12.06 | Ralith | uh, it's a different thing |
| 06:12.13 | Twingy | think about it... |
| 06:12.14 | Ralith | how is solving a formula different from taking a square root? |
| 06:12.26 | Twingy | so with ray tracing you have a grid of rays |
| 06:12.35 | Twingy | and the result is a collection of intersection points |
| 06:12.44 | Twingy | the intersection points form a point cloud or mesh |
| 06:12.48 | Ralith | there's significantly more to it than that :P |
| 06:12.54 | Ralith | not only that, who said anything about a grid? |
| 06:12.54 | Twingy | the mesh is a tesselated representation of the implicit geometry |
| 06:13.14 | Ralith | BRL-CAD gives you a lot more than a point when you get a rayhit. |
| 06:13.19 | Twingy | Ralith: because you are not beam tracing, a ray is infinitely thin |
| 06:13.32 | Ralith | more than enough to accurately place circular arcs, in fact. |
| 06:14.01 | Twingy | I disagree, because you can end up resulting in moire and aliasing artificacts |
| 06:14.31 | Twingy | you have to choose the density of your grid of rays |
| 06:14.40 | Twingy | if it is not high enough you lose detail |
| 06:15.36 | Twingy | now, you could "interpolate" the results returned from the ray intersections, but you are still not exactly representing the implicit geometry |
| 06:15.46 | Twingy | because ray tracing is a form tessellating |
| 06:16.32 | Twingy | as the grid density approaches infinity the point cloud approaches and implicit representation |
| 06:18.24 | Twingy | I think you can clearly see this as an Inductive Proof |
| 06:19.29 | Twingy | DanielFalck: did gtk compile? |
| 06:32.29 | DanielFalck | I got it to build, but I misconfigured it - I have gtk libs for the old fink build along with the new one |
| 06:32.48 | DanielFalck | I'm not even sure how to clean it up and get things linked right |
| 06:33.15 | DanielFalck | I just went through this with the latest version of tcl/tk and got things sorted out |
| 06:33.23 | DanielFalck | but it takes me a while |
| 06:34.10 | DanielFalck | Twingy: visit #cam if you feel like it. there are some of us working on/playing with other os cam systems |
| 06:34.22 | Twingy | k |
| 06:34.42 | DanielFalck | Dan Heeks has some interesting stuff as does crotchet |
| 07:02.46 | Twingy | looks like he is making progress |
| 07:02.54 | Twingy | how long has he been at it? |
| 07:03.03 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1178014879.dsl.bell.ca) |
| 07:14.28 | DanielFalck | I'm not sure |
| 07:14.45 | DanielFalck | he programs cam for a living |
| 07:23.35 | Twingy | so if I put him out of business that would be bad for him |
| 07:24.13 | Twingy | isn't he kind of hurting himself by giving stuff away for free if he is trying to make money off of it to survive? |
| 07:24.38 | DanielFalck | I'm not sure of the motivation. You'll have to ask hime |
| 07:24.40 | DanielFalck | him |
| 07:30.18 | DanielFalck | I'm just glad he's willing to share |
| 07:31.53 | Twingy | you can't beat free :) |
| 07:32.27 | DanielFalck | the other guy I mentioned, crotchet, is a machinist who has learned to program c++ |
| 07:33.16 | DanielFalck | he's ported over the old apt360 fortran code (in C, not C++) and has a nice app called aptsketch, that I actually use for making gcode |
| 07:33.42 | DanielFalck | it uses gtkmm and opengl |
| 07:34.21 | DanielFalck | I'm just a rookie,learning python |
| 07:44.24 | Twingy | k, I'm off to bed |
| 07:44.55 | DanielFalck | it was good chatting with you |
| 08:12.09 | *** join/#brlcad b0ef` (n=b0ef@95.34.57.61.customer.cdi.no) |
| 08:15.47 | *** join/#brlcad madant (n=madant@117.196.136.108) |
| 09:31.50 | *** join/#brlcad b0ef (n=b0ef@062016142244.customer.alfanett.no) |
| 09:53.06 | *** join/#brlcad Dr_Phreakenstein (n=phreak@216.151.24.198) |
| 12:18.41 | *** join/#brlcad Elrohir (n=kvirc@p5B14FD14.dip.t-dialin.net) |
| 13:02.58 | *** join/#brlcad madant (n=madant@117.196.138.212) |
| 13:24.34 | *** join/#brlcad madant1 (n=madant@117.196.138.212) |
| 13:54.01 | *** join/#brlcad docelic_ (n=docelic@78.134.199.40) |
| 14:00.09 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 14:52.28 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) |
| 15:35.42 | *** join/#brlcad b0ef` (n=b0ef@95.34.57.61.customer.cdi.no) |
| 15:52.35 | *** join/#brlcad Elrohir (n=kvirc@p5B14FD14.dip.t-dialin.net) |
| 15:58.27 | *** join/#brlcad b0ef (n=b0ef@062016142244.customer.alfanett.no) |
| 16:03.06 | *** join/#brlcad madant (n=madant@117.196.145.227) |
| 16:31.06 | *** join/#brlcad madant (n=madant@117.196.145.227) |
| 17:09.49 | *** join/#brlcad madant1 (n=madant@117.196.145.227) |
| 17:21.03 | starseeker | DanielFalck: Is there a link for aptsketch anywhere? |
| 17:43.34 | *** join/#brlcad madant (n=madant@117.196.145.227) |
| 18:02.08 | *** join/#brlcad DanielFalck (n=dan@pool-71-111-65-232.ptldor.dsl-w.verizon.net) |
| 18:02.40 | DanielFalck | http://sourceforge.net/projects/aptos/ |
| 18:04.04 | DanielFalck | another interesting project: |
| 18:04.05 | DanielFalck | http://heekscnc.blogspot.com/ |
| 18:19.28 | CIA-65 | BRL-CAD: 03brlcad * r33525 10/brlcad/trunk/src/other/incrTcl/compat/ (43 files in 2 dirs): |
| 18:19.28 | CIA-65 | BRL-CAD: add the tcl/tk headers for 8.4 since if we're compiling against a system 8.4, we |
| 18:19.28 | CIA-65 | BRL-CAD: still need access to tclInt.h and friends (which are not publicly installed |
| 18:19.28 | CIA-65 | BRL-CAD: headers). put them in a version-specific 'compat' directory that we can later |
| 18:19.28 | CIA-65 | BRL-CAD: refer to via cppflags. |
| 18:19.52 | CIA-65 | BRL-CAD: 03brlcad * r33526 10/brlcad/trunk/src/other/incrTcl/Makefile.am: include compat in the dist |
| 18:27.02 | CIA-65 | BRL-CAD: 03brlcad * r33527 10/brlcad/trunk/ (3 files in 3 dirs): |
| 18:27.02 | CIA-65 | BRL-CAD: if we're compiling against a system 8.4, use the newly added 'compat' headers in |
| 18:27.02 | CIA-65 | BRL-CAD: src/other/incrTcl/compat/8.4 so that we get the proper internal/private tcl/tk |
| 18:27.02 | CIA-65 | BRL-CAD: headers. this makes the entire compilation succeed using system tcl/tk with our |
| 18:27.04 | CIA-65 | BRL-CAD: bundled incrTcl, toggled off of the TCL_8_4_HEADERS conditional. also makes it |
| 18:27.06 | CIA-65 | BRL-CAD: so we can remove that tcl+itcl sanity check section that forced our tcl/tk if |
| 18:27.08 | CIA-65 | BRL-CAD: not 8.5. |
| 18:39.34 | CIA-65 | BRL-CAD: 03brlcad * r33528 10/brlcad/trunk/configure.ac: remove some dead logic, update the comment about -fast (it's because of aliasing), and remove the silly HAVE_BRLCAD conditional. |
| 18:53.19 | CIA-65 | BRL-CAD: 03brlcad * r33529 10/brlcad/trunk/TODO: too vague a task and it's an on-going one |
| 19:11.36 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-205.sbndin.btas.verizon.net) |
| 20:46.16 | *** join/#brlcad mafm (n=mafm@138.Red-83-54-182.dynamicIP.rima-tde.net) |
| 20:49.05 | mafm | hi |
| 21:38.23 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-205.sbndin.btas.verizon.net) |
| 22:53.18 | brlcad | howdy mafm |
| 22:53.24 | brlcad | (woo hoo, tv is now up on the wall) |
| 22:56.17 | mafm | burn it down! it only tells you lies :P |
| 22:58.57 | Ralith | hehe |
| 23:17.44 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1178014879.dsl.bell.ca) |
| 23:18.38 | IriX64 | http://www3.sympatico.ca/mario.dulisse2/project-cassandra.png <--- cassandra coming along :) |
| 23:28.38 | brlcad | mafm: hehe, so true |
| 23:54.38 | *** join/#brlcad mafm_ (n=mafm@138.Red-83-54-182.dynamicIP.rima-tde.net) |
