| 00:43.35 | *** join/#brlcad dtidrow (n=Don@c-71-238-51-148.hsd1.mi.comcast.net) | |
| 01:01.58 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 01:02.38 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 01:46.50 | *** join/#brlcad louipc (n=louipc@archlinux/trusteduser/louipc) | |
| 01:54.17 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 01:57.36 | CIA-32 | BRL-CAD: 03indianlarry * r34848 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: added new variables to brep_hit copy constructor |
| 02:24.51 | *** join/#brlcad stevegt_1 (n=stevegt@c-24-130-122-25.hsd1.ca.comcast.net) | |
| 03:46.55 | stevegt_1 | ~seen brlcad |
| 03:46.57 | ibot | brlcad is currently on #bzflag (15d 13h 6m 36s) #brlcad (15d 13h 6m 36s). Has said a total of 448 messages. Is idling for 7h 9m 47s, last said: 'cygal: I'd abort -- it shouldn't take that long'. |
| 03:47.09 | stevegt_1 | ~ralith |
| 03:47.14 | stevegt_1 | ~seen ralith |
| 03:47.15 | ibot | ralith is currently on #brlcad (1d 7h 54m 27s). Has said a total of 82 messages. Is idling for 5h 24m 1s, last said: 'brlcad: thanksâhopefully it won't come up again.'. |
| 03:47.15 | Ralith | sup |
| 03:47.21 | stevegt_1 | whup -- hi |
| 03:48.37 | stevegt_1 | ralith: still looking through src/rt/* -- i'm trying to figure out how to get a vector toolpath during or after processing ray hits... |
| 03:49.12 | stevegt_1 | raster is obvious, vector has me stumped so far |
| 03:50.44 | Ralith | stevegt_1: what do you mean by raster and vector? |
| 03:50.55 | Ralith | those terms don't really apply. |
| 03:51.24 | stevegt_1 | raster == e.g. .bw, .pix, .jpg etc. |
| 03:51.31 | Ralith | those aren't toolpaths |
| 03:51.32 | Ralith | those are images |
| 03:52.04 | stevegt_1 | vector == primitive edges |
| 03:52.12 | Ralith | primitive edges? |
| 03:52.15 | Ralith | what do you mean by that? |
| 03:52.43 | stevegt_1 | hm |
| 03:52.45 | louipc | ~seen louipc |
| 03:52.46 | ibot | louipc is currently on #brlcad (2h 5m 56s). Has said a total of 1 messages. Is idling for 1s, last said: '~seen louipc'. |
| 03:52.53 | louipc | laffs |
| 03:53.33 | stevegt_1 | vector as in svg, dxf |
| 03:53.52 | stevegt_1 | g-code, laser etc. need vectors |
| 03:56.08 | Ralith | stevegt_1: what do you mean by 'vectors'? |
| 03:56.31 | Ralith | rt will quite happily give you precise coordinates. |
| 03:57.13 | stevegt_1 | a vectorized shape description -- like a sketch |
| 03:57.40 | stevegt_1 | or an arb? |
| 03:57.47 | Ralith | that's a circular definition... |
| 03:58.00 | stevegt_1 | im trying here ;-) |
| 03:58.17 | stevegt_1 | okay, let's look at it this way: |
| 03:58.19 | Ralith | perhaps you mean you want to extract arcs? |
| 03:58.32 | stevegt_1 | ahh -- yes, arcs |
| 03:58.34 | Ralith | all g-code can represent is lines and arcs. |
| 03:58.38 | stevegt_1 | right |
| 03:59.09 | Ralith | that's nontrivial, because lines and arcs cannot exactly represent many possible region slices. |
| 04:00.19 | stevegt_1 | for a laser or CNC router, we need exactly one slice, aligned with the plane of the part we're cutting out |
| 04:00.30 | Ralith | you can use arcs to more closely approximate curves than you could with lines, but it's still an approximation unless you get lucky and the curve happens to be precisely circular. |
| 04:00.59 | Ralith | the level of the approximation is up to you. |
| 04:01.20 | Ralith | the raytracer provides sufficient information to perform this approximation; jonored implemented it, but I couldn't tell you how it's done. |
| 04:01.28 | stevegt_1 | some sort of successive approximation? |
| 04:01.42 | stevegt_1 | that's the only thing i've been able to think of so far |
| 04:03.19 | stevegt_1 | googles for clues about what jonored was doing |
| 04:04.54 | Ralith | ~seen jonored |
| 04:07.27 | ibot | jonored <n=jonored@dsl092-076-134.bos1.dsl.speakeasy.net> was last seen on IRC in channel #brlcad, 63d 8h 33m 20s ago, saying: '...er... wrong project. the brlcad database, not the reprap... wrong project I want to work on.'. |
| 04:07.50 | stevegt_1 | heh |
| 04:16.04 | Ralith | that took a while |
| 04:20.57 | stevegt_1 | i'm getting a creeping feeling that the most direct route to what i want might be to generate the shapes further upstream, probably in a python script, handle constraints etc there, then use brl-cad for rendering and interference checking, and finally generate the toolpath from the upstream output, rather than from brl-cad |
| 04:21.14 | stevegt_1 | which is probably what others are doing |
| 04:21.39 | stevegt_1 | darnit |
| 04:22.38 | stevegt_1 | the closest i'm seeing to what jonored was doing was his mention in the IRC channel of not being able to work on his 2009 gsoc proposal |
| 04:23.23 | stevegt_1 | those proposals aren't online anywhere? (just the ideas and the accepted ones? at least that's all i'm finding so far..) |
| 04:23.57 | Ralith | stevegt_1: I suspect you vastly underestimate the difficulty of evaluating CSG. |
| 04:24.34 | Ralith | reliably and precisely, anyway |
| 04:25.00 | stevegt_1 | not underestimating -- if i were to do things upstream, then i'd have to manually say "okay, a hole needs to go here so this other rod can pass through" |
| 04:25.08 | stevegt_1 | so not even trying to evaluate in that case ;-) |
| 04:25.24 | Ralith | I don't follow |
| 04:26.32 | stevegt_1 | like this: if all you've got is 2-d tools, qcad, autocad, whatever, then you have to manually do the booleans, calculate part fit, try to keep it all in your head |
| 04:26.55 | Ralith | afaik there are no 'others'; anybody currently generating toolpaths from brlcad models is almost certainly doing so with third party tools after exporting to another format (e.g. stl) |
| 04:29.42 | stevegt_1 | i figured that too -- but that loses info on the way through of course |
| 04:29.42 | Ralith | if all you've got is 2d tools, I don't think there's yet any way to get meaningful data from BRL-CAD to them anyway, short of writing your own tool. |
| 04:29.44 | stevegt_1 | other way around -- sketch in qcad, import into brl-cad, extrude, repeat |
| 04:29.45 | Ralith | that should be feasible; there appears to be a dxf importer. |
| 04:29.47 | stevegt_1 | then use rtcheck for interference checking to find out where you screwed up ;-) |
| 04:31.18 | Ralith | rtcheck? |
| 04:31.24 | stevegt_1 | the dxf importer seems to work -- the only thing i haven't been able to figure out os the right way to use 'extrude' -- it's not shown in the pdf tutorials, and the wiki seems to disagree with the code and/or usage statement |
| 04:31.30 | stevegt_1 | s/os/is/ |
| 04:31.42 | Ralith | someone in here probably knows |
| 04:31.44 | stevegt_1 | rtcheck -- checks for overlaps; it's great |
| 04:31.51 | Ralith | also check the reference card, and the built-in help |
| 04:31.59 | pacman87 | stevegt_1: do you already have the sketch? |
| 04:32.01 | Ralith | that's not what my manpage says... |
| 04:32.02 | pacman87 | for the extrude |
| 04:32.04 | Ralith | <PROTECTED> |
| 04:32.14 | stevegt_1 | pacman87!!! someone else is awake! |
| 04:32.30 | pacman87 | hi |
| 04:32.36 | pacman87 | reads the backlog |
| 04:33.08 | Ralith | perhaps it's used for something else in mged. |
| 04:33.35 | pacman87 | can you summarize what you're trying to do? |
| 04:33.52 | stevegt_1 | goes to see if he's completely confused about the name of that command |
| 04:34.12 | pacman87 | dxf -> sketch -> extrude? |
| 04:37.06 | stevegt_1 | is not crazy |
| 04:37.24 | stevegt_1 | unless i'm completely misinterpreting the results of mged's rtcheck |
| 04:37.31 | Ralith | shrugs |
| 04:37.32 | Ralith | I've never used it |
| 04:37.38 | stevegt_1 | pacman87: yes, dxf -> sketch -> extrude |
| 04:37.53 | pacman87 | and where does the problem start? |
| 04:38.08 | stevegt_1 | lemme go get an error message... |
| 04:38.16 | pacman87 | (and the command that caused it) |
| 04:43.30 | stevegt_1 | pacman87: i think i'm probably having basic usage confusion as much as anything else -- ' extrude sketch.1 5' errors out wanting the user to be in SOL EDIT state, but if I say 'sed sketch.1', it pops up the gui sketch editor... then if i say 'extrude sketch.1 5' again, it still says i'm in VIEWING state |
| 04:44.06 | stevegt_1 | i obviously haven't done enough of the tutorials, to begin with |
| 04:44.31 | pacman87 | oh, i'm using classic mode |
| 04:44.35 | stevegt_1 | ah |
| 04:44.47 | pacman87 | so i just do "in <name> extrude" |
| 04:44.51 | pacman87 | and it promps for the fields |
| 04:45.08 | stevegt_1 | lemme try that |
| 04:49.19 | pacman87 | the dxf-g converter used to double the line segments (one going each direction), but i think that's been fixed |
| 04:50.12 | stevegt_1 | notes that the 'extrude' command and the 'extrude' primitive are completely different |
| 04:50.17 | stevegt_1 | i think |
| 04:50.29 | pacman87 | i only know of the primitive |
| 04:50.31 | pacman87 | what's the command do? |
| 04:50.50 | stevegt_1 | the command just wants 2 args: 'extrude {face} {distance}' |
| 04:50.59 | stevegt_1 | much simpler ;-) |
| 04:51.02 | Ralith | yeah, that probably doesn't have anything to do with sketches. |
| 04:51.07 | stevegt_1 | if i could get it to work ;-) |
| 04:51.19 | Ralith | considering that sketches don't have faces. |
| 04:51.37 | pacman87 | what primitive results from the extrude command? |
| 04:53.13 | stevegt_1 | pacman87: the wiki says it 'modifies an ARB' -- ahh, yes, that won't work on sketches |
| 04:53.23 | stevegt_1 | i think |
| 04:53.56 | pacman87 | yeah, so it take the edge points from and ARB, and uses that as the base for (i'm guessing) another ARB |
| 04:54.04 | pacman87 | s/from and/from an/ |
| 04:54.39 | Ralith | stevegt_1: think about it; sketche don't have faces. |
| 04:54.44 | Ralith | sketches* |
| 04:56.01 | stevegt_1 | Ralith: i seem to remember seeing the code accepting a sketch as one of its args, but can't find it ATM... hang on, gotta put a 6-year-old to bed... |
| 05:01.04 | Ralith | brb |
| 05:05.14 | pacman87 | bedtime for me |
| 05:13.39 | Ralith | back |
| 05:31.32 | stevegt_1 | back -- nope, the mged extrude doesn't take sketches, wants an arb face -- don't know what code I was looking at the other day |
| 05:37.56 | Ralith | so see what you can do with in |
| 05:43.58 | stevegt_1 | yep |
| 07:22.32 | *** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch) | |
| 07:49.45 | *** join/#brlcad _clock_ (n=_sushi_@77-58-151-159.dclient.hispeed.ch) | |
| 09:53.34 | *** join/#brlcad Elrohir (n=kvirc@p5B14F13C.dip.t-dialin.net) | |
| 09:57.34 | *** join/#brlcad mafm_ (n=mafm@165.Red-81-35-69.dynamicIP.rima-tde.net) | |
| 12:21.48 | starseeker | growls - rebuilding gentoo sucks... |
| 12:29.24 | louipc | hehe still on that train eh? |
| 12:37.07 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 12:55.17 | _clock_ | starseeker: I can understand this rebuilding my gentoo sucked so much that I swapped to another distro |
| 13:06.41 | louipc | _clock_++ |
| 13:25.08 | starseeker | tried that |
| 13:25.14 | starseeker | sucked more than rebuilding |
| 13:37.48 | mafm_ | debian ftw! |
| 13:39.11 | louipc | starseeker: what distros? |
| 13:39.25 | louipc | not ubuntu! :D |
| 13:39.57 | starseeker | yeah, ubuntu |
| 13:40.19 | starseeker | has finely tweaked his desktop settings over the years, and ubuntu has its own ideas |
| 13:40.48 | louipc | yeah debian is probably better |
| 13:41.20 | louipc | I would plug arch linux though :P |
| 13:46.36 | brlcad | bsd ftw ;) |
| 14:02.08 | CIA-32 | BRL-CAD: 03irpguardian * r34849 10/brlcad/trunk/src/proc-db/human.c: (log message trimmed) |
| 14:02.10 | CIA-32 | BRL-CAD: Made significant updates to the human.c file which will eventually be a complete human generator that |
| 14:02.13 | CIA-32 | BRL-CAD: uses CSG to model a human. |
| 14:02.15 | CIA-32 | BRL-CAD: human.c currently creates a 'stick' human to a desired height by use of command line parameters and also |
| 14:02.18 | CIA-32 | BRL-CAD: allows for the output of specifically named .g file when using the -o command on input. |
| 14:02.22 | CIA-32 | BRL-CAD: Also included are most of the bounding blocked for each part of the generated body by using the -b command. |
| 14:02.25 | CIA-32 | BRL-CAD: So if you wanted to make a 'human' right now, the command would be... |
| 14:10.24 | louipc | crazy |
| 14:49.36 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |
| 14:52.37 | CIA-32 | BRL-CAD: 03irpguardian * r34850 10/brlcad/trunk/src/proc-db/human.c: Added bounding box support to each of the hands. |
| 14:59.47 | CIA-32 | BRL-CAD: 03bob1961 * r34851 10/brlcad/trunk/src/librt/db_open.c: Fixed a bug in db_sync (i.e. it was possible to return without releasing a semaphore). |
| 15:19.44 | CIA-32 | BRL-CAD: 03bob1961 * r34852 10/brlcad/trunk/src/libged/ged.c: Modify ged_open() to create a dbip if a NULL one is passed in. |
| 15:25.59 | CIA-32 | BRL-CAD: 03bob1961 * r34853 10/brlcad/trunk/src/tclscripts/archer/Archer.tcl: Now using inmem database for the ledger. |
| 15:34.23 | starseeker | brlcad: figuring out the bsd install would talk some time, and figuring out the new config file locations would take more :-P |
| 15:34.28 | starseeker | is getting old... |
| 15:39.14 | brlcad | 'scuses 'scuses |
| 15:40.38 | starseeker | was actually crazy enough to consider opensolaris for a second... |
| 16:36.36 | *** join/#brlcad BigAToo (n=BigAToo@64.74.225.82) | |
| 16:38.00 | CIA-32 | BRL-CAD: 03irpguardian * r34854 10/brlcad/trunk/src/proc-db/human.c: |
| 16:38.02 | CIA-32 | BRL-CAD: Added section that creates regions out of all the body parts and all the bounding boxes, aptly named |
| 16:38.05 | CIA-32 | BRL-CAD: Body.r and Boxes.r |
| 16:53.15 | *** join/#brlcad roberthl (n=robert@cobalt.rhl.me.uk) | |
| 17:03.45 | CIA-32 | BRL-CAD: 03brlcad * r34855 10/brlcad/trunk/TODO: binary installer for windows is missing external dependency headers (specifically need tcl and openNURBS headers) |
| 17:06.43 | CIA-32 | BRL-CAD: 03brlcad * r34856 10/brlcad/trunk/NEWS: bob implemented initial undo support for archer using in-memory geometry and a ledger of changes. |
| 17:15.30 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 17:41.21 | brlcad | hello jdoliner, how goes the progress? make sense of nmg? |
| 17:54.29 | jdoliner | yeah I got the basic idea of nmg |
| 17:55.26 | jdoliner | I have a weird problem right now |
| 17:59.42 | jdoliner | so I've written a test for my meshmeshintersection algorithm |
| 18:00.12 | jdoliner | and it seems good |
| 18:01.18 | jdoliner | except when I call it. control goes into ON_Mesh::ON_Mesh function and after it completes that it just hangs |
| 18:01.37 | jdoliner | I feel like there's something I'm not getting here |
| 18:28.03 | stevegt_1 | ~seen Ralith |
| 18:28.08 | ibot | ralith is currently on #brlcad (1d 22h 35m 20s). Has said a total of 120 messages. Is idling for 12h 50m 13s, last said: 'so see what you can do with in'. |
| 18:36.57 | stevegt_1 | needs a sanity check before he dives into writing something called 'g-laser' |
| 18:37.31 | stevegt_1 | i think i have an algorithm that will work for generating laser toolpaths, but i'm new to brl-cad and might be missing something important |
| 18:41.49 | stevegt_1 | i'm thinking: since popular lasers (like the epilog) are 3dof machines, the beam will always be perpendicular to the part being cut |
| 18:42.35 | stevegt_1 | that greatly simplifies trying to figure out the profile of any edges created by booleans |
| 18:43.50 | stevegt_1 | since these lasers can only do vertical hole walls, that means the primitives intersecting the part must have 'top' faces which are also normal to the beam |
| 18:44.22 | stevegt_1 | which means we can derive a clean toolpath directly from that 'top' face of the intersecting primitive |
| 18:44.37 | stevegt_1 | without tesselation or other approximation |
| 18:49.53 | stevegt_1 | this means cones, toruses, spheres, etc. can't be used to make coles in laser-cut parts, nor can complicated arbs (e.g. mushroom-shaped -- can brl-cad even do those?), but imho that's a reasonable constraint |
| 18:50.05 | stevegt_1 | <crickets chirping> ;-) |
| 18:50.53 | stevegt_1 | i'll probably write this up on a web page somewhere and pop in here again later -- i gotta unplug for an hour or so pretty soon |
| 18:51.06 | jdoliner | hi I don't know enough about your project yet to really comment. But I am working on CSG algorithms which is maybe related |
| 18:51.15 | jdoliner | so maybe if you explain at a lower level I can help |
| 18:51.16 | stevegt_1 | hi jdoliner |
| 18:52.22 | stevegt_1 | goes to look at what jdoliner's working on |
| 18:54.31 | stevegt_1 | (still reading) |
| 18:57.03 | stevegt_1 | jdoliner: okay, done reading/skimming your proposal -- the output of the algorithm is a bezier curve? |
| 18:57.31 | jdoliner | yeah |
| 18:57.37 | jdoliner | basically |
| 18:57.45 | jdoliner | that bezier curve becomes a trimming curve |
| 18:58.09 | stevegt_1 | as in something that could be stated as a primitive in gcode or dxf? |
| 18:58.39 | stevegt_1 | (as opposed to tesselation) |
| 18:58.50 | jdoliner | yeah I believe so |
| 18:59.16 | jdoliner | it can be stated as an ON_NurbsSurface object |
| 18:59.16 | stevegt_1 | if that's true, then halleluyah, or somesuch |
| 18:59.37 | stevegt_1 | s/tesselation/tessellation/ ;-) |
| 19:01.46 | stevegt_1 | the need for that algorithm is where i was hung up on the toolpath-generation problem -- i could see that some thorny math would be required, but the closest i'd be able to get is by trying to duplicate what librt does in solving quadratics or something -- and i barely made it through Calc II, 25 years ago ;-) |
| 19:03.28 | stevegt_1 | something that algorithm will be needed to generate toolpaths for machines which have more that 3 axes -- i.e. if the machine can tilt the cutting tool, or otherwise do over/undercuts in holes and at the sides of a part |
| 19:03.37 | stevegt_1 | s/something/something like/ |
| 19:06.14 | stevegt_1 | anyway, i *think* i can cheat in the case of 3-axis machines like lasers, since they can only do vertical-walled cuts -- just constrain the intersecting primitives to have faces that are perpendicular to the part being cut |
| 19:11.36 | *** join/#brlcad stevegt`` (n=stevegt@cislunar.TerraLuna.Org) | |
| 19:13.30 | stevegt_1 | jdoliner: i gotta go get lunch; i'll try to write this up and be back later |
| 19:14.06 | jdoliner | yeah, particularly if you get hung up on thorny math I can try to give you a hand with ti |
| 19:14.25 | jdoliner | it** |
| 19:14.31 | stevegt_1 | i'm pretty sure you could ;-) |
| 19:25.33 | *** join/#brlcad BigAToo (n=BigAToo@64.74.225.82) | |
| 19:42.35 | CIA-32 | BRL-CAD: 03bob1961 * r34857 10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: Added cc.c and lscon.c to build. |
| 20:03.22 | CIA-32 | BRL-CAD: 03bob1961 * r34858 10/brlcad/trunk/misc/win32-msvc8/ (brlcad/brlcad.sln g2adrt/): Removed g-adrt from windows build. |
| 20:13.43 | CIA-32 | BRL-CAD: 03bob1961 * r34859 10/brlcad/trunk/src/tclscripts/archer/ (Archer.tcl ArcherCore.tcl): Removed a bit of leftovers from the previous edit history hack. |
| 20:41.34 | *** join/#brlcad stevegt_ (n=stevegt@cislunar.TerraLuna.Org) | |
| 21:19.39 | brlcad | jdoliner: hm, hard to say without walking the execution or knowing more info about the ON_Mesh::ON_Mesh problem -- have you tried stepping through with a debugger? |
| 21:20.47 | jdoliner | yeah gdb's really been the flavor of the afternoon :) |
| 21:20.56 | brlcad | stevegt_: mushroom-shaped arbs?? picture of one? |
| 21:21.08 | brlcad | jdoliner: heh, awesome |
| 21:21.23 | jdoliner | it was something weird with initializing ON_Meshes |
| 21:21.39 | jdoliner | but I switch the function to use pointers instead |
| 21:21.42 | jdoliner | and that cleared it up |
| 21:22.15 | jdoliner | which in all honesty probably makes more sense because I imagine meshes can get big |
| 21:25.32 | brlcad | they can get huge, Gigs |
| 21:27.54 | brlcad | stevegt_: sorry we keep failing to cross paths :) |
| 21:28.05 | stevegt_ | brlcad: right here ;-) |
| 21:28.23 | stevegt_ | other than the mushrooms, did the rest of what i was saying make sense? |
| 21:33.13 | stevegt_ | overall, what i'm trying to do is pick a cad package for designing and generating toolpaths for making low-end machines that have a laser-cut acrylic parts, and are otherwise built from bolt-together things off the shelf -- motors, lead screws, fasteners, etc |
| 21:33.16 | stevegt_ | like http://fabathome.org/wiki/index.php?title=Main_Page |
| 21:33.39 | brlcad | Ralith: rtcheck's primary purpose is interference (aka overlap) detection with a side-effect of overlaying a plot of the overlaps if you run it in mged (yes the help line is misleading) |
| 21:34.09 | stevegt_ | brlcad: good, i wasn't insane that time ;-) |
| 21:36.04 | brlcad | stevegt_: docs are pretty thin on extrude, but it's really pretty simple to extrude a sketch -- run the 'in' command in mged and it'll interactively prompt you |
| 21:37.11 | brlcad | ah, and yes, there is an 'extrude' command which is different than creating an extrude primitive -- you don't want the extrude command, you want the 'in' command |
| 21:37.13 | stevegt_ | brlcad: so i gathered; i haven't figured out what some of the prompts are asking yet, but i'm sure that'll be obvious by the time i get used to the way brl-cad does things |
| 21:38.41 | stevegt_ | s/low-end machines that have a laser-cut acrylic parts/low-end machines that have a lot of laser-cut acrylic parts/ |
| 21:38.49 | brlcad | ah, all caught up with the log now :) |
| 21:39.03 | brlcad | yes, the rest you said made sense (i think!) :) |
| 21:40.12 | brlcad | basically it asks you what scaling factors do you want (you can skew/stretch the sketch before extruding it) and then the distance |
| 21:40.35 | brlcad | usually best to just use orthogonal unit vectors, 1 0 0 and 0 1 0 |
| 21:41.01 | brlcad | that aligns the sketch normalized to an x/y plane like one would usually expect be default |
| 21:42.11 | brlcad | that's a pretty cool machine, hmm.. :) |
| 21:42.13 | stevegt_ | anyway, i *think* i'm in a common use case for the newer crowd of maker community, arduino controllers, fabbers, people who might have access to a laser or CNC router, and are looking for something more capable than qcad for modelling the machines -- so something like 'g-laser' seems like a good idea, just trying to figure out how doable it is |
| 21:42.47 | stevegt_ | so 'in ... extrude' wants a sketch? lemme go try it again... |
| 21:42.53 | brlcad | g-gcode is something that's been on the "todo" for a while :) |
| 21:43.41 | brlcad | yeah, 'in' is the interactive input tool for creating primitives .. you can feed it the whole line or parts of a line and for any part remaining it'll prompt you |
| 21:44.46 | stevegt_ | yeah, i'm saying to myself "wow, brl-cad is great!!" and i'm going through the tutorials, and then it hits me -- right now, it seems to be optimized for importing and analyzing models, rather than making them -- unless you are using STL e.g. 3-d printing? |
| 21:45.14 | stevegt_ | s/making them/making things from them/ |
| 21:45.16 | brlcad | the real solution to what you want is very much related to jdoliner's project where you evaluate a given object (regardless of geometry format, csg or non-csg) to a spline-surface boundary representation that has no booleans, then project that to a given plane |
| 21:45.46 | brlcad | gives you a series of 2D spline curves and line segments that could them be turned into arcs and polylines or what have you |
| 21:45.46 | stevegt_ | i agree -- for generic gcode for a 3 or more axis mill, you need jdoliner's stuff |
| 21:47.23 | brlcad | what you intuited about brl-cad is quite true -- it's presently heavily geared around import and analysis requirements .. but also visualization and creation (but a very different approach than most commercial systems) |
| 21:48.00 | stevegt_ | the light bulb this morning was that, since a lot of these potential users (including me) are just using lasers, then i can just ensure via raytracing that hole walls are vertical, and then directly derive the dimensions of the hole by looking at the top face of the intersecting shape -- i think ;-) |
| 21:49.30 | jdoliner | stevegt_: whenever you need me I'm here to help |
| 21:49.36 | stevegt_ | i plan to generate a lot of parts from scripts in the first place, so brl-cad fits with that usage as well |
| 21:49.39 | brlcad | for nearly two decades, brl-cad has been used (with the csg approach) to model vehicles down to the nut bolt and wire using CSG boolean operations and primitives -- many things are considerably more efficient that way over BREP methods, but it's definitely a very different way of thinking about things and a large body of experience that has to be built up -- but once you do, the advanced brl-cad modelers are just as effective in brl-cad as they are in other com |
| 21:50.54 | brlcad | stevegt_: you know, if you're ray-tracing, it's not a whole lot extra logic to make it derive that top-hole using ray-tracing to a given tolerance using adaptive subdivision |
| 21:51.14 | stevegt_ | goes and looks up "adaptive subdivision" ;-) |
| 21:51.27 | brlcad | that would let you extract a contour for any arbitrary view |
| 21:52.12 | stevegt_ | is that more or less what the tessellation routines do? |
| 21:52.27 | brlcad | not at all |
| 21:52.38 | stevegt_ | i see 'curves' in the description... |
| 21:52.51 | brlcad | it's basicaly a sampling approach, you sample down to a specified level of detail |
| 21:54.33 | stevegt_ | is that related to the use of voxel spaces? |
| 21:54.40 | brlcad | think of it this way.. you shoot a grid of rays and find the edges of an object .. but instead of filling in pixels, you build up coefficients for a set of polynomial curves |
| 21:54.53 | stevegt_ | ah |
| 21:55.34 | brlcad | sampled sufficiently, you'll derive a spline that fits to the circular top of a cylinder, for example |
| 21:56.06 | stevegt_ | is there code anywhere in the brl-cad tree that does something like this right now? |
| 21:56.21 | brlcad | I'm sure you could *very* easily sample at a resolution much higher than the resolution of your fabbers stepper motors :) |
| 21:58.26 | brlcad | hm, the closest starting point is probably rtedge, which simply renders an edge outline (raster) of an object based on neighboring hits -- you'd want to extend that to be calculate the curves |
| 21:58.44 | brlcad | example, http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html |
| 21:58.47 | stevegt_ | ah ha -- 'adaptive subdivision algorithm' is giving me some good hits in google.... |
| 21:59.38 | stevegt_ | yeah, i looked at rtedge and got worried that i'd be stuck with raster-like limitations, then popped in last night to bug Ralith about it ;-) |
| 22:00.24 | brlcad | yeah, just forget about the pix output -- you'd be outputting curves or directly to gcode or whatever |
| 22:00.31 | stevegt_ | huh |
| 22:02.00 | stevegt_ | i'm wondering if it would be easier to write the code such that it tries to read the hole geometry directly off the top face of the intersecting object, and *then* falls back to adaptive subdivision, or just uses adaptive subdivision always... |
| 22:02.39 | stevegt_ | probably the latter, assuming i can figure out how to do it |
| 22:03.31 | stevegt_ | the raytracing hits sure are nice to be able to get at |
| 22:06.59 | brlcad | nice example: http://www.museum.state.il.us/ismdepts/library/linuxguides/povray/image112.gif |
| 22:07.26 | brlcad | "adaptive sampling" <- another useful term you can search on |
| 22:08.00 | stevegt_ | now has to go back and remember how polynomial curve fitting works -- those brain cells died decades ago :-b |
| 22:09.14 | Ralith | it's not hard |
| 22:09.27 | brlcad | so in that image, where you have a hit neighbored to a miss, you know there's an edge somewhere between those two rays, you adaptively sample to more precisely find that edge -- if you recurse down all edges, you can find a 'perfect' contour from which you can derive coefficients for a representative set of splines |
| 22:10.01 | stevegt_ | hi Ralith! |
| 22:10.04 | Ralith | hullo |
| 22:11.28 | brlcad | another example, http://www.lamrug.org/resources/images/samples/samples.03d.jpg |
| 22:12.48 | brlcad | done well enough, you end up with an rtvector .. from which you could output svg or gcode or pdf or whatever format ;) |
| 22:13.15 | stevegt_ | brlcad: that sounds like it might be successive approximation -- do you ultimately compare the polynomial-generated curve with the original edge, or is the algorithm open-loop? (if that makes sense) |
| 22:14.06 | stevegt_ | (i'm still skimming papers from citeseer) |
| 22:14.54 | brlcad | yes, it's a way to get a successive approximation |
| 22:15.24 | brlcad | there is no "original edge" to compare it to, you're deriving a representation for that edge |
| 22:15.55 | brlcad | you just keep refining until you're below a specified accuracy level (ideally below your machine's capabilities) |
| 22:16.13 | brlcad | so even if there is error, it's never realized |
| 22:17.32 | *** part/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 22:17.55 | stevegt_ | the way you're envesioning this working, is it iterative? or am i missing some direct way to get from ray hits to coefficients? |
| 22:18.34 | stevegt_ | s/envesioning/envisioning/ |
| 22:18.51 | brlcad | here we go, even better |
| 22:19.29 | brlcad | it's basically an implementation of marching cubes with adaptive subsampling, but in 2D (i.e., marching squares with adaptive subsampling) |
| 22:19.33 | brlcad | http://www.exaflop.org/docs/marchcubes/ |
| 22:19.53 | stevegt_ | funny -- march cubes was one of the links i saw a few minutes ago |
| 22:19.55 | brlcad | and yes, it is iterative |
| 22:19.56 | stevegt_ | goes to look |
| 22:20.48 | brlcad | that page even speaks to the sampling issues, good stuff |
| 22:21.58 | brlcad | just when reading, you're working in 2D so read it as s/cubes/squares/ and s/polygons/line segments/ (for starters) |
| 22:22.03 | stevegt_ | ok, yes, they're talking about voxel spaces... |
| 22:22.19 | brlcad | voxel spaces are for 3D |
| 22:22.28 | stevegt_ | ...and they're using polygons instead of curves, but i'm grokking it |
| 22:23.04 | brlcad | right, the even mention that near the end -- that's basically applying smoothing algorithm to derive a curve |
| 22:23.36 | stevegt_ | saw that -- and you're picturing polynomial curve segments instead of straight line segments |
| 22:24.24 | brlcad | yeah, only because I don't think many machines would be robust with millions of sub-millimeter line segments that would be required to describe a smooth curve |
| 22:24.48 | brlcad | would expect aliasing artifacts |
| 22:25.36 | brlcad | interpolate a curve and simplify (e.g., identify and make curves that are linear actually just be line segmenets) |
| 22:25.48 | stevegt_ | okay, i think i can do this -- the way my brain works, i'm probably going to wind up re-deriving a lot of the algorithm, but to me it looks familiar when i think of it in the class of successive approximation, binary search, interpolation, etc. |
| 22:29.18 | stevegt_ | just don't make me solve quadratics ;-) |
| 22:31.34 | brlcad | adaptive marching squares, tis good stuff ;) |
| 22:41.00 | CIA-32 | BRL-CAD: 03brlcad * r34860 10/brlcad/trunk/src/libbu/parallel.c: ws indent cleanup |
| 22:53.23 | CIA-32 | BRL-CAD: 03brlcad * r34861 10/brlcad/trunk/src/libbu/parallel.c: |
| 22:53.25 | CIA-32 | BRL-CAD: make sure the file is actually world read/writable like we said it would be, |
| 22:53.27 | CIA-32 | BRL-CAD: call bu_fchmod(). that said, this is a horrible way to do this. mark the |
| 22:53.35 | CIA-32 | BRL-CAD: implementation as deprecated even if it's not likely anyone is relying on the |
| 22:53.37 | CIA-32 | BRL-CAD: temp files and rtsrv is the only brl-cad tool that can leverage this. |
| 22:54.04 | stevegt_ | brlcad: while i'm only going to write something like g-laser, g-toolpath2d, or whatever ("marching squares"), it does strike me that the marching cubes could be used to generate gcode suitable for N-axis mills |
| 22:55.27 | stevegt_ | <lightbulb on> and the raytracing lib could be used to fire rays at various angles to test the approache angle of the tool itself, make sure it doesn't hit anything |
| 22:55.37 | stevegt_ | s/approache/approach/ |
| 22:59.45 | brlcad | yep |
| 23:01.02 | brlcad | the exact approach you're using it 2D extends very well to 3D -- hell, with the 3D approach, that's a viable alternative for a variety of purposes including visualization, tessellation, and evaluation |
| 23:01.37 | brlcad | the problem is that it's not nearly as robust for all uses (e.g. visualization) where you can continue to "zoom in" and start to see the artifacts |
| 23:01.46 | brlcad | works well for hardware though |
| 23:02.12 | stevegt_ | that would really go far in cleaning up the CNC tool chain -- where I sit right now (middle of silly valley) there are about 900 CNC mills with a 1-mile radius; we've gotten to know a few of them over the last several years; they are all still very labor-intensive when it comes to massaging the dxf they get from the customer and generating the gcode |
| 23:03.03 | brlcad | to make sure the tool doesn't hit anything, something ala rtcheck or g_qa would work great by just having them represent the tool as geometry and test for overlap |
| 23:03.42 | brlcad | cool that you're interested in this, look forward to seeing what you make of it |
| 23:03.51 | brlcad | the idea has been around for a while, just nobody to work it |
| 23:04.35 | brlcad | lots of squeaky wheels that require attention, like better modeling interface, better interactive visualization, step conversion support, full hybrid nurbs brep support, etc ;) |
| 23:05.41 | stevegt_ | i've been interested in this ever since I was in the USAF in the early 80's, and saw how far we (still) are from being able to "print metal" -- it really drives up the cost of everything |
| 23:07.50 | stevegt_ | whups -- s/early 80's/late 80's/ -- i'm not *that* far gone yet ;-) |
| 23:08.56 | brlcad | heh |
| 23:11.36 | CIA-32 | BRL-CAD: 03brlcad * r34862 10/brlcad/trunk/src/librt/ (primitives/table.c wdb.c): ws indent consistency |
| 23:19.28 | stevegt_ | makes himself stop and go get (very late) lunch |
| 23:24.04 | CIA-32 | BRL-CAD: 03brlcad * r34863 10/brlcad/trunk/src/librt/ (7 files in 6 dirs): break out arb8 mirroring, modify all the mirror function signatures to not take a pointer, instead just taking a plant_t |
| 23:25.33 | *** join/#brlcad Elrohir (n=kvirc@p5B14F13C.dip.t-dialin.net) | |
| 23:25.47 | CIA-32 | BRL-CAD: 03brlcad * r34864 10/brlcad/trunk/misc/ (2 files in 2 dirs): add arb8_mirror.c to the other windows build files |
| 23:41.08 | CIA-32 | BRL-CAD: 03brlcad * r34865 10/brlcad/trunk/misc/win32-msvc9/: |
| 23:41.10 | CIA-32 | BRL-CAD: remove the vc9 project files as they've gotten considerably out of sync without |
| 23:41.12 | CIA-32 | BRL-CAD: a maintainer. there are more than 163 differences with the vc8 project. |
| 23:41.14 | CIA-32 | BRL-CAD: someone can revive and resync if they're willing to maintain it, otherwise it's |
| 23:41.18 | CIA-32 | BRL-CAD: just a costly maintenance burden and confusing to users. |
| 23:43.32 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-196.sbndin.btas.verizon.net) | |
| 23:49.59 | ``Erik | would it be easy to generate vc9 files from the vc8 ones? |
| 23:50.33 | ``Erik | (or mebbe solicit the mailing list for a vc9 volunteer?) |
| 23:54.06 | starseeker | glares at gentoo - I might have known - a non-clean config path upgrade |
| 23:54.30 | starseeker | first rule of Xorg building - never,never,NEVER build a configuration that won't work |
| 23:54.58 | starseeker | oh, well - I was due for a scrub anyway, but GRRRRRRRR |
| 23:55.52 | ``Erik | pkg_add x11/Xorg on bsd, binary install of all the right stuff, then you can portupgrade at your leisure with automatic failure recovery and 'last good state' saved just in case |
| 23:57.05 | ``Erik | throw in the normal bsd nerd approach of putting edited config files in cvs or rcs and you have a system very very hard to fuck up for more than 2 minutes |
