[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