[cad-linux] Re: CAD with server/client architecture
- From: Roland Krause <rokrau@xxxxxxxxx>
- To: cad-linux@xxxxxxxxxxxxx
- Date: Mon, 12 May 2003 10:39:48 -0700 (PDT)
Interesting discussion this is.
I have been thinking about a truly open solid modelling kernel myself
lately. Having worked with ParaSolid and Asics in the past, I would say
the first step, after reviewing what is already out there, would be to
design the actual modelling kernel and it's interface.
Extensible file formats we have - it is obvious that one possibility
here is some dialect of XML. There is probably something like that out
there already.
So, my question is first of all, what is out there? There is
OpenCascade's kernel, which is after all "Open Source". Are there any
others?
Roland
--- Eric Wilhelm <ewilhelm@xxxxxxxxxxxxx> wrote:
>
> > The following was supposedly scribed by
> > Jim Parker
> > on Saturday 10 May 2003 04:16 pm:
>
> >My problems to date is trying to keep a file format generic enough
> to
> >make drawings in any engineering disipline, but still useful so my
> >modules have useful data to work with.
>
> >So where to store it is a general file format .... or do
> >you use 2 or more files, to hold the info ?
>
> I mentioned briefly in this write-up the idea of using a "family" of
> file
> formats. The format used by the openoffice.org suite is really
> interesting
> in that they use a gzipped tarball to store several files and a
> folder
> structure. There is some overhead associated with this, but the
> benefit to
> programming is that you are able to use pre-existing modules to read
> and
> write the file formats.
>
> I would say the best way to handle the data is to base everything on
> an
> object-properties model. Say you have a ship's hull, the hull is
> just a
> shape, handled by any modeling software as a shape, and stored in the
>
> file-format as a shape (though maybe with some defining geometric
> attributes
> to allow for parametric modification) in something like STEP format.
> The
> properties which are present with all homogeneous elastic solids
> (aka:
> metals) are stored in an xml spreadsheet (or some other standard
> database)
> along with all of the other material properties for all of the other
> objects
> and the object addresses are referenced from the spreadsheet to
> associate
> this information with the geometric entities in the model.
> Properties
> specific to some usage (say the hydrostatic loads on the ship's hull
> or the
> point loads on a beam or the cut-paths for an NC torch) should be
> stored in
> individually tailored files (which are stored inside the tarball).
> The way
> this data is organized and interpreted depends on the usage, so why
> try to
> make it all fit the same stencil? Some data would have to be linked
> back to
> the model, but the link would consist of generic geometric entities
> (like the
> points to which the loads are applied (these points would be attached
> to the
> "beam" entity)).
>
> The key to keeping the data interoperable is the open-source core,
> which
> should be responsible for writing all of the file-formats (and would
> then
> present objects and data structures to the running programs). This
> is the
> part which would handle the associations between entities, as well as
> the
> data locking and revision control.
>
> --Eric
>
>
>
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
Other related posts:
