00:04.45 |
*** join/#brlcad nayasi
(~na@ti541110a080-1145.bb.online.no) |
00:08.54 |
*** join/#brlcad tjyang
(~cc@c-67-175-74-12.client.comcast.net) |
00:13.38 |
nayasi |
hei |
00:29.06 |
*** join/#brlcad tjyang
(~cc@c-67-175-74-12.client.comcast.net) |
01:22.46 |
*** join/#brlcad cc_
(~cc@c-67-175-74-12.client.comcast.net) |
01:43.26 |
*** join/#brlcad noyb
(~noyb@wbar2.lax1-4-8-213-215.dsl-verizon.net) |
01:46.37 |
*** join/#brlcad CIA-2
(~CIA@to.je.spocco.com) |
01:58.54 |
*** join/#brlcad tjyang
(~Administr@c-67-175-74-12.client.comcast.net) |
02:09.39 |
*** join/#brlcad cc_
(~cc@c-67-175-74-12.client.comcast.net) |
02:30.16 |
*** join/#brlcad tjyang
(~cc@c-67-175-74-12.client.comcast.net) |
02:40.03 |
*** join/#brlcad tjyang
(~Administr@c-67-175-74-12.client.comcast.net) |
03:16.22 |
*** join/#brlcad mycr0ft
(~mycr0ft@pcp09883071pcs.ewndsr01.nj.comcast.net) |
03:55.58 |
learner |
hello mycr0ft |
03:56.16 |
learner |
mycr0ft, the getting started link on
brlcad.org is the relevant portions of volume I |
03:56.34 |
mycr0ft |
ah OK thanks learner |
03:56.43 |
learner |
the rest of volume one involved distribution,
license agreements, etc -- all invalidated by the open
sourcing |
03:57.08 |
mycr0ft |
sweet |
03:57.47 |
mycr0ft |
OK I've downloaded everything and will be
trying out BRLCAD right after I finish all my SBIR proposals.
Sigh. |
03:57.56 |
mycr0ft |
Thanks |
03:58.11 |
learner |
sounds like fun (not) |
03:58.33 |
learner |
slipping some brl-cad improvements into the
sbir? :) |
03:58.45 |
learner |
or leveraging the codebase ;) |
03:58.57 |
learner |
(it's been done before so I'm not exactly
joking) |
03:59.21 |
mycr0ft |
Actually BRLCAD doesn't really enter into this
round. |
03:59.47 |
mycr0ft |
I'm writing on MEMS projects and a Natural
Language parser. |
03:59.49 |
learner |
mged's replacement is actually coming out of
an sbir as will much of the windows support |
04:00.15 |
learner |
ahh, nlp is fun stuff |
04:00.17 |
mycr0ft |
I think getting SBIR support for OSS software
would be a worthy goal |
04:00.51 |
mycr0ft |
Especially when it can benefit both the govt
partner and the general community |
04:01.02 |
learner |
it would, though it's more support of an "old,
stable, powerful military code" ... |
04:01.08 |
learner |
... that happens to now be open
source |
04:01.15 |
learner |
exactly |
04:01.30 |
mycr0ft |
unfortunately, the one problem with the SBIR
program is the Commercialization aspect of it. |
04:01.55 |
mycr0ft |
And OSS software is a hard sell since you have
to claim that you are selling support contracts |
04:02.02 |
mycr0ft |
or services |
04:02.20 |
mycr0ft |
At least that's what I got back in one
review |
04:02.52 |
learner |
actually not that hard for a codebase like
brl-cad |
04:03.10 |
learner |
brl-cad is just an underlying code used to
some other means usually |
04:03.24 |
mycr0ft |
Yeah, that's true. |
04:03.46 |
mycr0ft |
The licensing on the BRL Code-base... is it
more BSD or more GPL? |
04:04.07 |
learner |
it's like picking up libpng or some other
library .. lots of facilities jump-starting the project |
04:04.33 |
learner |
different parts are under different
license |
04:04.44 |
learner |
the binaries are under the gpl |
04:04.50 |
learner |
the libraries are under the lgpl |
04:05.01 |
learner |
the docs are under the gfdl |
04:05.23 |
learner |
the build system, support scripts, benchmark
suite, regression test suite are all under the bsd license or in
the public domain |
04:05.45 |
mycr0ft |
Thanks for the info. \n Well, I gotta sleep
before I croak... I've got to finish 2 more SBIR proposals by
Friday morning. |
04:05.53 |
learner |
good luck |
04:06.06 |
mycr0ft |
gl to you too. |
04:06.12 |
*** part/#brlcad mycr0ft
(~mycr0ft@pcp09883071pcs.ewndsr01.nj.comcast.net) |
04:32.26 |
*** join/#brlcad tjyang
(~cc@c-67-175-74-12.client.comcast.net) |
04:51.28 |
*** join/#brlcad PrezKennedy
(~Matthew@pcp035019pcs.aberdn01.md.comcast.net) |
04:53.04 |
PrezKennedy |
aint nothin like bein rejected cuz youre on a
different "intelectual" level :-\ |
04:53.20 |
PrezKennedy |
me bein on the upper side no less |
05:19.29 |
learner |
heh |
07:58.26 |
*** join/#brlcad noyb
(~noyb@wbar2.lax1-4-8-213-215.dsl-verizon.net) |
07:58.51 |
learner |
wb noyb |
10:34.21 |
*** join/#brlcad tjyang
(~cc@c-67-175-74-12.client.comcast.net) |
10:51.54 |
*** join/#brlcad CIA-2
(~CIA@to.je.spocco.com) |
14:15.25 |
*** join/#brlcad tjyang
(~cc@c-67-175-74-12.client.comcast.net) |
14:39.14 |
*** join/#brlcad cc_
(~cc@c-67-175-74-12.client.comcast.net) |
14:41.38 |
*** join/#brlcad phshadow
(point@portablehole.net) |
15:00.22 |
*** part/#brlcad phshadow
(point@portablehole.net) |
15:31.48 |
brlcad |
ahh, just missed him |
15:34.14 |
EricWilhelm |
brlcad, I think brlcad's sketcher is a little
clunky |
15:34.20 |
EricWilhelm |
Is it just me? |
15:34.33 |
brlcad |
no, it's very clunky |
15:34.51 |
brlcad |
it was minimal support for a very limited
task |
15:35.06 |
EricWilhelm |
what would it take to export the sketch
geometry and let a drafting program edit it? |
15:35.30 |
EricWilhelm |
(e.g. like your mail client or browser
launching an external program with a tempfile name) |
15:35.43 |
brlcad |
in general, brl-cad has had no funding for
2d-related geometries, anything related to drafting, CAM,
etc |
15:36.38 |
brlcad |
i'd imagine that the easiest would be to add
direct export support for the sketch primitive to the converter
formats that can handle it (like g-dxf) |
15:36.43 |
EricWilhelm |
what about printing a hidden-line drawingL (as
vectors, not raster/rendered) |
15:37.08 |
EricWilhelm |
but .g can't have simultaneous access,
right? |
15:37.33 |
EricWilhelm |
s/drawingL/drawing?/ |
15:37.39 |
brlcad |
not from separate processes |
15:38.09 |
EricWilhelm |
can brlcad create a .g tempfile from a slice
of the database? |
15:38.21 |
EricWilhelm |
and read any modifications back in? |
15:39.08 |
EricWilhelm |
that would make for a very hackable plugin
architecture |
15:39.12 |
brlcad |
yes it can |
15:39.30 |
brlcad |
you can "keep" geometry and various was to
read them back on |
15:41.47 |
EricWilhelm |
what code would I have to work with? The mged
source? |
15:47.48 |
EricWilhelm |
(or is there a way to do it with
scripts?) |
15:48.55 |
brlcad |
the code to "keep" subsets of a .g and reload
them are available via the api and as simple mged commands .. so
that part is pretty flexible |
15:49.32 |
brlcad |
the conversion of that geometry to another
format via a converter would be the work involved |
15:50.15 |
EricWilhelm |
okay, say I want to replace the
create->sketch menu item code. Does that have to be
compiled-in? |
15:50.45 |
brlcad |
e.g. you keep all.g from moss.g to a file..
run g-dxf or g-iges on that file with sketch pritive support coded
in .. edit somewhere else, then iges-g or dxf-g back and reload
into .g |
15:51.13 |
brlcad |
ahh, to replace the sketch menu code is all
tclscripting |
15:51.16 |
brlcad |
src/tclscripts |
15:51.20 |
brlcad |
mged |
15:52.20 |
EricWilhelm |
/usr/local/brlcad/tclscripts/mged/ ? |
15:54.33 |
EricWilhelm |
is this all in some developer documentation
that I should be reading? |
15:55.32 |
brlcad |
yes.. that's where tclscripts gets installed
to |
15:55.50 |
brlcad |
it's basically a direct copy from
src/tclscripts to $prefix/tclscripts |
15:56.05 |
brlcad |
with a package index step in between |
15:56.40 |
brlcad |
There's the HACKING file at the top level for
general documentation .. for code-level, what you find is what you
get |
15:57.05 |
brlcad |
for the C library interfaces, there are
manpages documentation |
15:58.12 |
brlcad |
e.g. brlman libfb |
15:58.51 |
brlcad |
Oh, and there's developer documentation from
within mged on the help menu |
15:59.18 |
brlcad |
there's a broad set of developer commands not
listed in the general command set |
16:04.05 |
brlcad |
and of course feel free to drop questions in
here .. it's a lot of code to get to, but generally easy to follow
one piece at a time |
16:10.16 |
EricWilhelm |
hmm. It sounds like it would only take a day
or two to make qcad the sketcher. Am I kidding myself? |
16:13.25 |
brlcad |
ooh, very interesting idea |
16:14.47 |
brlcad |
actually that sounds fairly reasonable ..
"hardest" part is going to be making sure that the converter is
supporting the primitive in question |
16:15.11 |
brlcad |
and that's not really that hard .. just
another case statement and a some writes |
16:17.51 |
EricWilhelm |
is there any "special" data in a sketch?
(e.g. named entities or "the legbone's connected to the thighbone"
type stuff) |
16:18.05 |
EricWilhelm |
or, would randomly ordered connected lines
work? |
16:19.12 |
brlcad |
to be honest, I don't recall |
16:19.17 |
EricWilhelm |
E.G. in other sketchers (pro-e, catia,
inventor), you have constraints to model geometry, etc that can't
be represented in dxf. |
16:19.39 |
brlcad |
the geometry primitives as a datatype are
defined in librt |
16:20.29 |
brlcad |
src/librt/g_sketch.c |
16:21.13 |
brlcad |
brl-cad does not have explicit constraints
(yet), so it sounds pretty safe to assume randomly ordered is
fine |
16:21.43 |
brlcad |
constraints are one of the funded todo items
over the next year |
16:26.55 |
EricWilhelm |
<homer>hmm... funded
(drool...)</homer> |
16:27.30 |
EricWilhelm |
how would a dumb cad program deal with
constraints? |
16:27.34 |
brlcad |
so are a variety of other goodies |
16:27.51 |
EricWilhelm |
maybe with a constraint editor? (external to
both brlcad and the cad program?) |
16:28.21 |
EricWilhelm |
e.g. it seems to me that the biggest problem
with most sketchers is the inability to just throw-down some
geometry |
16:28.27 |
brlcad |
well, dumb cad program is most likely only
supporting dumb cad format |
16:28.42 |
EricWilhelm |
they all seem to want you to constrain it as
you draw it |
16:28.58 |
brlcad |
uni and pro do, sure |
16:29.15 |
EricWilhelm |
maybe Draft could grow-up to be a
constaint-based drafting program |
16:29.41 |
brlcad |
little colored light telling you if you are
fully/partially/un-constrained was a pita |
16:29.56 |
brlcad |
but in the end, useful/good |
16:30.08 |
brlcad |
Draft is part of qcad? |
16:30.12 |
brlcad |
or something else |
16:30.35 |
EricWilhelm |
it certainly isn't trying to work with a dumb
cad format (this is Bruno's cddf prototype (http://bugbear.blackfish.org.uk/~bruno/draft/) |
16:32.04 |
brlcad |
hrm, i'll have to take a look at
that |
16:32.32 |
brlcad |
i'd imagine the dumb cad modeler will have to
smarten up some ;) |
16:32.37 |
EricWilhelm |
of course, with a cddf (cad directory database
format), you could have a drawing editor running next to a
constraint editor |
16:33.23 |
brlcad |
i see it more as making your values complex
types, expressions |
16:33.39 |
brlcad |
you need a consistent way to refer to other
geometry |
16:33.50 |
brlcad |
and support for your basic math |
16:34.30 |
EricWilhelm |
rhizopod is the current uber-converter format,
but doesn't have any facility for relational drafting, however it
is probably the framework for the next level, which would be less
static |
16:36.13 |
brlcad |
so instead of "radius == 3" .. it supports
"radius == [box.corner.4.x * .3] |
16:36.16 |
EricWilhelm |
Right. When you get relational, the
endpoints, radii, etc. have to be expressed as formulas or
functions. |
16:36.17 |
brlcad |
or something |
16:36.44 |
EricWilhelm |
But, I think that the rhizopod format lays a
groundwork for what could be an addressable version. |
16:37.25 |
EricWilhelm |
And, with persistent entity ID's, I'm not sure
that the drafting program ever has to worry about the
formulas. |
16:38.46 |
EricWilhelm |
e.g. if you can just scratch-out the geometry
and then apply constraints in another program, the drafting program
could just have a way to display constraints and lock values which
cannot be modified directly (you can only change box.corner.4.x,
not radius) |
16:40.39 |
brlcad |
that would be good, I'd imagine you'd
conversely want to allow direct access/modification of those
constraints for packages that do have good constraint management
(unigraphics, for example) |
16:44.24 |
EricWilhelm |
right, but with the cddf (let's say that the
step after rhizopod is medusa (a jellyfish (complicated enough to
hurt you, but still relatively simple))) both programs (in the
two-program version) would be using the same data (but the drafting
app would just see read-only files where the geometry is
dependent) |
16:44.51 |
EricWilhelm |
so, the independent geometry in the medusa
format is identical to static geometry in the rhizopod
format |
16:45.30 |
EricWilhelm |
therefore, a rhizopod drafting app can change
any independent geometry, and a medusa-aware constraint editor can
just handle constraints (but not draw anything) |
16:45.57 |
EricWilhelm |
ok, so if you add drafting to the constraint
editor, you get an all-in-one program that is a medusa
editor |
16:45.57 |
brlcad |
and something like brl-cad that understands
both could do both :) |
16:46.06 |
EricWilhelm |
right |
16:46.43 |
EricWilhelm |
but does brlcad modify the sketch geometry or
just use it? |
16:47.01 |
EricWilhelm |
since brlcad is a csg editor, that's a few
steps past medusa |
16:48.26 |
brlcad |
it reads/writes it and uses it |
16:48.40 |
brlcad |
it's just the editing capabilities are
primitive |
16:49.02 |
EricWilhelm |
okay, so maybe brlcad's editing is limited to
exporting faces of existing solids or something? |
16:49.08 |
brlcad |
but once you have one, and it's extruded, it's
just as fully useable as any of the other solids |
16:49.17 |
brlcad |
for intersection analyses etc |
16:49.24 |
EricWilhelm |
sort of an interactive g2rhizopod |
16:49.48 |
EricWilhelm |
create->sketch->from_solid |
16:50.17 |
brlcad |
hrm |
16:50.46 |
EricWilhelm |
s/g2rhizopod/g2medusa/ |
16:50.55 |
brlcad |
that would be interesting perhaps.. but right
now the sketch (which is covered briefly in volume III or IV
iirc) |
16:51.23 |
brlcad |
the sketch is just a basic collection of
spline curves thatdescribe an enclosed space |
16:51.33 |
brlcad |
you extrude that space to form a useable solid
object |
16:51.56 |
brlcad |
bbiab |
16:53.26 |
EricWilhelm |
I'll have to find some time and dig around a
bit. Making a way to use an external drafting program for sketches
would be my first step. That would give the uber-converter
something to do (not that I have time or funding for the
uber-converter right now...) |
18:06.03 |
*** join/#brlcad tjyang
(~cc@c-67-175-74-12.client.comcast.net) |
19:56.59 |
*** join/#brlcad tibor_
(~tibor@217.21.35.33) |
20:29.51 |
*** join/#brlcad PhantomBantam
(~phantomba@dialup-4.238.67.170.Dial1.Providence1.Level3.net) |
20:30.12 |
PhantomBantam |
Hello. |
20:30.58 |
jano |
howdy |
20:32.16 |
PhantomBantam |
Any idea when the mac binary will be
posted? |
20:37.22 |
jano |
he'll know |
20:43.27 |
PhantomBantam |
Okay. |
22:24.22 |
*** join/#brlcad guu
(guu@myth.gibbscam.com) |