01:02.44 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
06:15.57 |
*** join/#brlcad ChanServ
(ChanServ@services.) |
06:15.57 |
*** mode/#brlcad [+o ChanServ]
by leguin.freenode.net |
06:21.37 |
*** join/#brlcad louipc
(~louipc@archlinux/fellow/louipc) |
12:10.28 |
*** join/#brlcad andrei
(~andrei@188.25.162.226) |
12:34.21 |
*** join/#brlcad Al_Da_Best
(Al_Da_Best@cpc2-shep12-2-0-cust21.8-3.cable.virginmedia.com) |
14:04.53 |
Notify |
03BRL-CAD:brlcad * 53812
(brlcad/trunk/src/librt/primitives/half/half.c): comment the
peculiarity I had to research. ensures segment is valid, equiv to
>inf || <-inf |
15:35.57 |
*** join/#brlcad jarray52
(~bigbear@unaffiliated/jarray52) |
16:18.52 |
*** part/#brlcad jarray52
(~bigbear@unaffiliated/jarray52) |
17:15.14 |
*** join/#brlcad archivist
(~archivist@host81-149-189-98.in-addr.btopenworld.com) |
17:55.07 |
*** join/#brlcad jarray52
(~bigbear@209.203.86.178) |
17:55.27 |
*** join/#brlcad jarray52
(~bigbear@unaffiliated/jarray52) |
17:56.58 |
jarray52 |
expr (2 + 2) gives 4 at the mged prompt.
Similarly, expr (2 - 2) gives 0, and expr (2 / 2) gives 1. However,
expr (2 * 2) states Error: unbalanced open paren in expression
"(2". |
17:57.36 |
jarray52 |
How does one multiply two numbers? |
17:58.08 |
``Erik |
globbing is turned on and * is read as a file
matching argument instead of as an expression symbol, you can
either turn globbing off or escape the * "expr (2 \* 2)" |
17:59.04 |
jarray52 |
will \* work even when globbing is turned off?
I'm writing an mged script. |
18:00.33 |
``Erik |
I'm not sure, one of the tcl weenies might
have a good answer... might consider turning off globbing at the
beginning of the script just to be sure? (I don't know if there's a
scope/state issue doing that) |
18:01.11 |
jarray52 |
``Erik: Thanks. That was helpful. |
18:01.14 |
``Erik |
I'm sure an answer will pop up if you lurk for
a while (might take a day or so, though) |
18:01.31 |
``Erik |
or maybe look at other scripts, or just try it
:D |
18:02.30 |
jarray52 |
Are example scripts available somewhere? So
far I've only seen the box and logo scripts |
18:03.42 |
``Erik |
src/brlcad/tclscripts/ would be where I'd
start |
18:05.04 |
``Erik |
mged/dbfindtree.tcl saves glob_compat_mode to
a var, sets it, runs, then sets it back to var |
18:11.14 |
jarray52 |
``Erik: Thanks again. |
18:11.51 |
``Erik |
np, good luck! |
18:24.04 |
*** join/#brlcad jarray52
(~bigbear@unaffiliated/jarray52) |
18:40.13 |
brlcad |
jarray52: set glob_compat_mode 0 |
18:40.19 |
brlcad |
that will turn globbing off in a
script |
18:41.27 |
jarray52 |
brlcad: Is there a problem with leaving the
glob_compat_mode set to 1 and using \* wherever multiplication is
needed? |
18:42.31 |
brlcad |
there may be a problem depending on how the
script is passed to mged, but it's more of a syntax issue |
18:42.56 |
brlcad |
it won't look like proper tcl source,
especially once you start needing to also escape the other globbing
characters like [] |
18:43.09 |
brlcad |
which is the common way to invoke a
subexpression in tcl |
18:43.51 |
brlcad |
puts "The result is [expr 2*2]" |
18:45.37 |
jarray52 |
brlcad: That is good to know.
Thanks. |
18:47.08 |
*** join/#brlcad andrei
(~andrei@188.25.162.226) |
19:37.07 |
jarray52 |
I created a part using brlcad, and I would
like to create g-code for this part. I created a .dxf file using
g-dxf, and I was planning on using dxf2gcode to generate gcode.
However, the output of g-dxf output 3124 triangles. Will the final
g-code be useable? |
19:37.45 |
jarray52 |
Does anyone have suggestions on generating
g-code using brlcad? |
19:38.33 |
brlcad |
that entirely depends on dxf2gcode |
19:39.04 |
brlcad |
dxf is a polygonal format, so I'm not sure
what the concern is exactly though |
19:41.39 |
jarray52 |
brlcad: I was concerned that converting to a
format that uses triangles will lose information/make the
information unuseable. But, if that's the only way to store things
in the dxf format, then it is dxf2gcode's task to handle the
generation of gcode. |
20:54.26 |
jarray52 |
brlcad: When I ran g-dxf -i -o part.dxf -p a.g
part.c, I got the error message _db_walk_subtree() FAIL on
... |
21:05.03 |
brlcad |
jarray52: yeah, dxf is a rather limited format
in that regard -- it has some support, but I highly double
dxf2gcode would handle them any more than we would write
them |
21:05.57 |
brlcad |
whether a FAIL message is significant depends
on your hierarchy construction (and whether it's correct) and the
object that failed |
21:06.22 |
brlcad |
best way to check is to run dxf-g and look at
the result in mged, see if it's missing anything you care
about |
21:07.23 |
brlcad |
if it is, you can often overcome the failure
by changing the geometry that failed in minor ways (so that faces
and edges aren't coinciding) |
21:31.22 |
*** part/#brlcad jarray52
(~bigbear@unaffiliated/jarray52) |
22:02.10 |
*** join/#brlcad jarray52
(~bigbear@unaffiliated/jarray52) |
22:02.51 |
*** join/#brlcad cristina
(~quassel@188.24.72.207) |
22:19.12 |
jarray52 |
What's the best way to go from brlcad 3D
models to engineering drawings and/or file formats that can be
submitted for the purpose of manufacturing physical
parts? |
22:27.42 |
brlcad |
jarray52: the best way will be our step
exporter, but we're not there yet -- for now, it's the complexities
of performing an export conversion |
22:28.56 |
jarray52 |
brlcad: Once the step exporter is complete, we
can create a step file and then submit it to a machine
shop? |
22:29.04 |
brlcad |
yep |
22:29.11 |
brlcad |
technically most take stl these days
too |
22:29.20 |
brlcad |
it's sort of the lowest common
denominator |
22:29.28 |
jarray52 |
stl seems to be a lossy format,
right? |
22:29.29 |
brlcad |
some *only* take stl |
22:30.01 |
brlcad |
of course, but that is meaningless for some
purposes (like gcode generation) |
22:30.13 |
brlcad |
you just have to control the tessellation
quality (with is hard, but necessary) |
22:31.08 |
jarray52 |
brlcad: Can gcode generated from stl create
parts with small tolerances? Parts such as pistons. |
22:32.58 |
brlcad |
depends which machine is creating the
piston |
22:33.15 |
jarray52 |
brlcad: Something like a turning
center. |
22:33.26 |
brlcad |
the only way to do that well is with a CAM
system that goes *directly* from the parametric form to output
"smart" gcode instructions |
22:34.16 |
brlcad |
the ones that take stl will perform an
automatic tool-path conversion, which is but yet another
approximation on top of the stl |
22:34.58 |
jarray52 |
Are there any CAM systems that output "smart"
gcode which can use brlcad models as the input? |
22:35.09 |
jarray52 |
the CAM system can be open source or
commercial. |
22:35.11 |
brlcad |
a turning center is going to want precision
measurements, probably drafting instructions so that they can set
turning knobs to specific measurements |
22:35.34 |
brlcad |
there are lots of commercial ones, gibbscam
comes to mind |
22:35.53 |
brlcad |
there are a couple toy open source projects,
but nothing to the level of precision a piston would
imply |
22:36.35 |
jarray52 |
what input formats does gibbscam
use? |
22:37.18 |
brlcad |
no idea |
22:37.30 |
brlcad |
but they're one of the big names |
22:37.36 |
brlcad |
so it should be "most formats" |
22:38.24 |
jarray52 |
Does any CAM system take brlcad databases as
an input? |
22:39.56 |
brlcad |
I have heard of a couple commercial CAD
systems that implemented support for our format, but not any of the
CAM systems |
22:40.12 |
brlcad |
it'd be unlikely -- best bet is going to be
that step exporter |
22:40.40 |
brlcad |
perhaps g-iges, but I lack faith in it's
stability (it's a dying format) |
22:41.19 |
brlcad |
jarray52: so you see our conundrum and why we
need more hands ;) |
22:41.54 |
brlcad |
that's a gap I've been working on bridging for
a long time |
22:41.56 |
jarray52 |
brlcad: I would like to see brlcad grow into a
complete solution. |
22:42.05 |
brlcad |
ditto |
22:42.30 |
brlcad |
getting nurbs/brep support was a HUGE piece of
that puzzle |
22:42.40 |
brlcad |
that lets us import and gives us foundation
for export |
22:43.38 |
brlcad |
that's also the same foundation that will give
us shaded opengl displays, not just wireframe, not just
raytracing |
22:44.07 |
brlcad |
same foundation giving STABLE export to the
polygonal exports without those FAIL messages |
22:44.28 |
brlcad |
same foundation giving explicit boundaries so
we can spit out drafting documents |
22:45.37 |
jarray52 |
How far is brlcad from producing drafting
documents? |
22:45.45 |
jarray52 |
labeled drafting documents? |
22:48.08 |
brlcad |
we have about ... |
22:48.11 |
brlcad |
calculates in
head |
22:50.50 |
brlcad |
there's about 9 weeks of effort needed to spit
out a labeled drafting document (with proper infrastructure support
and some basic docs) |
22:51.32 |
jarray52 |
brlcad: Is anyone working on this? |
22:53.04 |
brlcad |
the problem is that is roughly 4 major tasks
to get there (csg->brep, projected bbs, ann objects,
output) |
22:53.29 |
brlcad |
two of those are being worked, so we're
getting closer, but nobody specifically working towards that
goal |
22:54.05 |
jarray52 |
brlcad: I was imagining something to draw
lines on an rtedge drawing. Is that the wrong approach? |
22:54.17 |
brlcad |
csg->brep is top priority this year, kind
of waiting to see how good a job on the hardest problem |
22:54.35 |
brlcad |
you could do that now frankly, but yeah
completely different approach |
22:55.14 |
jarray52 |
brlcad: I have to checkout of this room. I
will see you around though. |
22:55.14 |
brlcad |
getting that machine-precise is
tricky |
22:55.24 |
brlcad |
okay, see ya |
22:55.28 |
jarray52 |
brlcad: Yes. That is the tricky
part. |
22:55.41 |
jarray52 |
brlcad: Thanks for answering my
questions. |
22:55.42 |
brlcad |
doing it via brep and projection is not as
hard |
22:56.04 |
jarray52 |
brlcad: I see. |
22:56.18 |
jarray52 |
brlcad: Thanks. Bye. |
22:56.20 |
brlcad |
cya |
22:56.27 |
*** part/#brlcad jarray52
(~bigbear@unaffiliated/jarray52) |
22:58.51 |
brlcad |
finishes adding some basic
table formatting to help with Deuces readability |