[cad-linux-dev] Re: uber-converter
- From: Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx>
- To: cad-linux-dev@xxxxxxxxxxxxx
- Date: Tue, 8 Jun 2004 09:33:32 -0500
# The following was supposedly scribed by
# cr88192
# on Tuesday 08 June 2004 07:02 am:
>by "core" I was referring to the basic set of semantic constructs that are
>assumed to be understood by everything connected to the system,
The only thing that would be understood by everything connected is the where,
who organizational-type stuff.
>and by
>"extensions" I meant new semantic constructs.
>
>eg:
>the "core" might define mesh, polygon, and vertex.
>an "extension" might define, eg, nurbs surfaces and beizer curves...
ok. Then *all* geometric and other entities are extensions by your
definition. That includes mesh, polygon, and vertex, circle, arc, text.
Because the 2D cad file (dxf, etc) and the 3D polygonal file (vrml, etc) are
so different, we may have a 2D cad connector which doesn't have any
entity-type overlap with a 3D polygon connector. Therefore every geometric
entity would have to be considered an "extension."
>all of this info will be held within the geometric db, just part is assumed
>to be understood by everything, and some may not be...
Right. The "connectors" are programs which marshal the data from one (usually
monolithic) format into and out of the database. They would all be expected
to know how to handle read/write permissions and commit/version-control
hooks. But the translation of entities is entirely up to the connector.
Let's say I have a dxf connector and a vrml connector. The dxf connector can
read and write dxf's with the following entities: polyline, line, arc,
circle, 3dface. The vrml connector only reads/writes the 3dface entity.
Starting with the cad program, some construction geometry (floor-plan) is
laid-out on the XY plane, with some vertical lines to establish
height-ordinates in space. These are then roughed-out with some polygons and
then loaded into the database under $dbroot/projects/house/. Now, I can read
from that into vrml, add/change polygons and load those back into the
database.
The drafting app can then read (and change) the polygons which were created in
the vrml-editor. The vrml-editor cannot mess with the 2D entities (unless
the connector translates them appropriately.)
So, the database is simply a place to store information, which needs to be
able to be write-protected and version-controlled (along with eventually
networkable.) The geometric entities need to be defined as a solid
specification, so that one connector reads/writes "in the same form" (tm) as
another (e.g. if I write circles in one way, but you write them in another,
our connectors won't ever see each other's circles) or the whole thing falls
down.
Therefore, we have to have some kind of "core specification" which describes
each and every entity, along with a set of protocols for commit hooks and
such. If we leave-out some entities at the start, I don't think that is a
problem, as long as their first implementation results in their getting
written into the spec.
--Eric
--
The opinions expressed in this e-mail were randomly generated by
the computer and do not necessarily reflect the views of its owner.
--Management
Other related posts:
