[freearchitecture] open CAD format is working
Eric Wilhelm
scratchcomputing at gmail.com
Fri Sep 14 20:17:40 BST 2007
Hi all,
I'm pleased to see some enthusiasm in this arena. It has been rather
quiet for a couple years.
# from Lars O. Grobe
# on Friday 14 September 2007 03:58 am:
>> We are working with Franz Reiter in a new native file for CADs based
>> in Step and X3D-CAD for exchange.
>
>... What I wonder is - why do you want to create a "new format"?
>What are the design aims?
I wonder the same thing. We've had similar discussions on the
cad-linux-dev mailing list, which led me to start work on VectorSection
(previously known as "Uber Converter".)
http://www.freelists.org/webpage/cad-linux-dev
http://scratchcomputing.com/projects/vectorsection/
> Besides, there are other formats, some of them have
> been discussed here in depth. There is work needed in implementing
> formats for different applications.
This is a key point, and the main driver behind VectorSection. There
are lots of programs and formats (proprietary and open) already
entrenched and most of them are unable to optimally exchange data.
While VectorSection *does* define new formats for the hubs, the focus is
on translating existing formats. Studying the existing formats has
made me aware of which mistakes are possible and also made it clear
that "one format" is not an option. My ultimate goal/hope is for the
hub formats to expressive and efficient enough to act as standalone
data for new programs (which by-definition gives said programs access
to a lot of converter tools for existing formats.)
Fortunately, I've been extremely busy with paying work for the last
couple years. Unfortunately, it is not in the realm of CAD.
Aside: I am the author of the CAD::Drawing Perl modules (mentioned in
this group's introduction), which contain a CAD::Drawing::IO::DWGI
backend that depends on the "Open"DWG libraries. When I started that,
the OpenDWG libraries were "free beer", but they did not yet require
FAXing a 9-page legal document (which they now do.)
Also note that pythoncad has made some impressive headway in reading (up
to acad2k IIRC) DWG files. For any 2D/3D-wireframe format to gain real
adoption, I think it needs to have some amount of DWG support.
Regarding XML, I recommend exhausting all other alternatives first.
Even "Enterprise Software" (which places such high hopes on XML) has
trouble exchanging data with it.
Similarly, a large DXF is dirt-slow even in Autocad. It is really quite
innefficient as a textual format because it basically only replicates
the DWG binary structure in ASCII. So, you get lack of readability
*and* loss of performance -- similar to writing Perl in a C style, but
with malloc. ;-)
STEP is a fairly sane format until you get into it's ability to define a
function for everything from "leap year" to "add three". Nonetheless,
I would like to see a usable open-source STEP library (note NIST had
built SCL, but seems to have abandoned it -- Sean Morrison of brlcad
has successfully updated this to a modern autoconf setup, but he's
supposed to be trying to find the tarball this month.)
Anyway, that's my "hello list" and I wish you all the best of luck and
reason. Please do review the archives and prior art. One of the
things that I think keeps a great open-source CAD from taking hold is
our collective innability to communicate and know what else is
happening. (And maybe also the lack of the sort of (direct or
indirect) economic backing which Linux, Apache, and other open-source
projects have enjoyed.)
--Eric
--
Issues of control, repair, improvement, cost, or just plain
understandability all come down strongly in favor of open source
solutions to complex problems of any sort.
--Robert G. Brown
---------------------------------------------------
http://scratchcomputing.com
---------------------------------------------------
More information about the freearchitecture
mailing list