[cad-linux-dev] Re: simplicity in the face of complexity
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: cad-linux-dev@xxxxxxxxxxxxx
- Date: Mon, 6 Oct 2003 16:16:06 -0500
> The following was supposedly scribed by
> Lee Harding
> on Monday 06 October 2003 11:16 am:
>But consider how many different formats might be involved in a
>(hypothetical) command-line like this:
>
>rg a.recipe b.recipe | ss -p1,1,1 -t 1 | ic | fg | gv
>
>where:=20
>
>rg =3D=3D a program to realize geometry from a discipline-specific =
>recipe
>ss =3D=3D a program to perform spatial selection (filtering) of geometry
>ic =3D=3D a program to perform interference checking
>fg =3D=3D a program to generate tessellations (scene graph?) from =
>geometry
>gv =3D=3D a program to view the faceted geometry
The limitation of the pipe is that data travels in only one direction.
If the interference checking is not going to have any kind of feedback which
results in modification of the recipe, then all of these commands could read
and emit different formats. However, I think that to have some kind of
feedback in the modeling/design with an interdisciplinary shared model, all
of the programs need to speak the same language, or at least speak enough of
the same language to be able to say something meaningful to each other.
I don't think that markup language is what we need here (particularly if the
data is to be broken into separate files (since a majority of the markup in
markup language is just there to establish a hierarchy within a flatfile.))
Maybe what I'm looking for is something with multiple layers and flavors,
where the data on the lower layers is common across all programs.
By flavors, I mean relational vs static geometry. Relational geometry can be
converted to static, but static cannot usually be converted back to
relational. I think it is fine for the two to coexist within the same
[x,y,z] format, and quite useful programs could be created very easily if you
could reliably take a static snapshot of the relational geometry.
By layers, I mean the recipes used to create an automatic layout or drive a
lower-level representation. Maybe the recipe can be used to create low-level
relational geometry or maybe it is only able to create low-level static
geometry. At some point, I'm going to have to cut a hole in a beam. If the
beams are created by recipe, how does the fabricator know where I want them
to cut the hole (and in what size beam?) Maybe I'm an HVAC contractor and I
need to size my duct based on the beam depth and total plenum space. I might
be a lighting designer and need to know where I can place lights or how much
light is transmitted through the windows.
What I'm saying is that we currently use the computer to communicate design
intent via e-mail when we could be communicating this via geometric data.
There needs to be some way to resolve the recipes across disciplines. If
there isn't, we might as well go back to sheets of paper and slide rules,
then at least we won't be deceiving ourselves by thinking that we are using
technology.
--Eric
--
"Insert random misquote here"
Other related posts:
