Re: [freearchitecture] open CAD format is working
Lars O. Grobe
> http://groups.google.com/group/open_cad_format
>
> We are working with Franz Reiter in a new native file for CADs based in
> Step and X3D-CAD for exchange.
I see, and I just joined the ml. What I wonder is - why do you want to
create a "new format"? What are the design aims? I see you referencing
two completely different formats, but which both have a specified useage
scenario. Besides, there are other formats, some of them have been
discussed here in depth. There is work needed in implementing formats
for different applications.
CU Lars.
Lars O. Grobe
Thanks, nice to be here ;-) BTW, you are aware of the different
CAD-Linux lists?
> gcad/oca format is a real format working. It愀 seems that is dificult
> work in good times with DXF o XML formats. oca/gcad is a simplification
> of STEP format. gcad3D is in 3d using MESA/openGL that is a freedeskop
> specification.
> There are a lot of free CADs, but if you try open big files, they don愒
> work.
OK. I really like the idea of step, so if gcad uses it I am delighted
;-) I do not really like to simplify it, as it is already a modular
system - you can simply support the subset you need and still be
compatible to the standard. There are free implementations available,
the whole is an ISO-Standard.
> By now only Autocad, Microstation or gcad3D works fine with big files.
Well, it depends on what you want to do and what Apps you use. Talking
about dxf-files, Autocad has to win in most cases as they define. But
you cannot define dxf and Step, dxf is less then the geometry parts of Step.
> We are thinking in XML
I like xml because it gives a set of tools to parse, validate and
translate. But actually you can encode everything into xml. It is just
how you store something, or better how you intermediately store, as the
source and target of xml data are usually databases.
> Perhaps SVG can be good for plotting also.
SVG is a nice import/output format, both for 2d-sketches and plotting,
and should should be supported. I can even imagine allowing "2d-objects"
encoded in svg.
I think the most important decision is what your target is. Are you
aiming something like Step, describing products? Are you interested in
geometry and interaction combined with some light and materials
describing worlds as x3d? Or is it all only about geometry like dxf & Co
? Are you targeting parametric processing, surfaces, ...?
My wish would be to bundle everything to support STEP in all existing
CADs / modellers and give them all clean x3d and svg import and export.
This allowed to start implementation immediately, ensuring some security
for investments as these standards already have support, also in the
commercial world, and give a development gain of some years, as it takes
so much time if you first re-invent the standards instead of
implementing existing ones.
CU Lars.
martin_gnu
> I think the most important decision is what your target is. Are you
> aiming something like Step, describing products? Are you interested in
> geometry and interaction combined with some light and materials
> describing worlds as x3d? Or is it all only about geometry like dxf & Co
> ? Are you targeting parametric processing, surfaces, ...?
>
> My wish would be to bundle everything to support STEP in all existing
> CADs / modellers and give them all clean x3d and svg import and export.
> This allowed to start implementation immediately, ensuring some security
> for investments as these standards already have support, also in the
> commercial world, and give a development gain of some years, as it takes
> so much time if you first re-invent the standards instead of
> implementing existing ones.
>
> CU Lars.
I have send a mail to linux-cad like you say me...
Here Franz talks about problems in formats. I don´t have experience in
big software to answer. It was a interesting discussion.
http://groups.google.com/group/open_cad_format/browse_thread/thread/df4fef4c0403a17a
Eric Wilhelm
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
---------------------------------------------------
martin_gnu
> My wish would be to bundle everything to support STEP in all existing
> CADs / modellers and give them all clean x3d and svg import and export.
> This allowed to start implementation immediately, ensuring some security
> for investments as these standards already have support, also in the
> commercial world, and give a development gain of some years, as it takes
> so much time if you first re-invent the standards instead of
> implementing existing ones.
>
I totally agree with you, but Franz in gcad3d use STEP and his own
format based in STEP...
It´s seems that people likes "STEP based" format like native and x3d-
svg to exchange. perfect!!
NOT 3D modeling especifications for movies, games,.... We have blender
and K-3D to that task in open source world.
We have here a masterful explanation about CAD by Franz Reiter:
http://groups.google.com/group/open_cad_format/web/gcad3d-opinion
I think that it´s interesting talk about a format used by a real time
CAD using MESA like gcad3d...
http://groups.google.com/group/open_cad_format/web/freedesktop-specifications-for-cad
A oca/gcad file especification of Franz is here:
http://groups.google.com/group/open_cad_format/web/open-cad-format
I think that it would be a good idea reading a little this document to
know if it´s possible with it.
Regards.
martin_gnu
Hi:
On 14 sep, 21:17, Eric Wilhelm <scratchcomput...@gmail.com> wrote:
> 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".)
Great job Eric. I didn´t know. Blender uses python scripts to import-
export al kind of files. Perhaps your Perl code would be great. Parrot/
perl 6 is coming...
> adoption, I think it needs to have some amount of DWG support.
DWG support is essential like you say, but not openDWG like native
file for us, only import/export.
> Similarly, a large DXF is dirt-slow even in Autocad.
Perfect. Not DXF
> 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.)
"STEP based" file it seems that it´s our option to native file. Franz
Reiter in gcad3d works with step and with a modified STEP more fast.
The important here is the job with MESA library:
We have here a masterful explanation in CAD:
http://groups.google.com/group/open_cad_format/web/gcad3d-opinion
http://groups.google.com/group/open_cad_format/web/open-cad-format
> Anyway, that's my "hello list" and I wish you all the best of luck and
> reason.
We want to build a pyramid between all:
http://groups.google.com/group/open_cad_format/web/how-to-build-a-pyramid
> indirect) *economic* backing which Linux, Apache, and other open-source
Perhaps SCILAB model can be a option:
http://groups.google.com/group/open_cad_format/web/scilab-software-model
Regards.
Terry Hancock
>> We are here working in a new open CAD format:
>> http://groups.google.com/group/open_cad_format
>>
>> We are working with Franz Reiter in a new native file for CADs based
>> in Step and X3D-CAD for exchange.
> I see you referencing
> two completely different formats, but which both have a specified useage
> scenario. Besides, there are other formats, some of them have been
> discussed here in depth. There is work needed in implementing formats
> for different applications.
STEP isn't really a file format, it's just a database schema -- it
defines the relationships between entities in the database, but not how
those relationships are serialized to disk. STEP can be implemented in
different data formats, so it's somewhat meaningful to talk about a
"STEP based format with X3D-CAD for exchange".
OTOH, there are already initiatives to create XML-based STEP
representations.
Some leads:
"Engineering Exchange For Free":
http://exff.org/
"STEP-XML" entry, Wikipedia:
http://en.wikipedia.org/wiki/ISO_10303-28
ISO STEP standards. Most of the standards documents are
pay-access only, but the EXPRESS schema documents themselves
are free for download:
http://www.tc184-sc4.org/
As far as using a distinct internal format is concerned, there are
significant advantages (in terms of diskspace and loading speed) to
using binary formats. So while it might be sensible to use the
"interchange format" as the internal format, there are reasons you might
want to go the other way, too.
HTH,
Terry
--
Terry Hancock (han...@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com
Franz Reiter
TextFormat versus BinaryFormat:
We have chosen TextFormat for gcad3d because we intended to do cam and
kinematics (kinematics: designed, but not yet implemented).
But:
Since TextFormat must be translated to binary (database) the loading-speed
of a BinaryFormat is much better.
The database-objects normally do not know where they come from.
Is there a list of pros and contras for TextFormat versus BinaryFormat ?
Then, regarding TextFormat:
If you want to use step as native code for an interpreter,
you have to reorder the whole input.
The sequence in Step-files is usually not ordered, so you have to load
the complete file; resolve all references, write out in correct sequence
(in the new format).
This describes a line in step:
#449 = TRIMMED_CURVE( '', #869, ( CARTESIAN_POINT( #870 ) ),
( CARTESIAN_POINT( #871 ) ), .T., .UNSPECIFIED. );
#870 = CARTESIAN_POINT( '', ( 0.0, -1.25, 13.0 ) );
#871 = CARTESIAN_POINT( '', ( 0.0, -1.25, 15.987 ) );
#869 = LINE( '', #1612, #1613 );
#1612 = CARTESIAN_POINT( '', ( 0.0, -1.25, 13.0 ) );
#1613 = VECTOR( '', #2336, 1.0 );
#2336 = DIRECTION( '', ( 0.0, 0.0, 1.0 ) );
This is the result of the import-process of gcad3d:
P20=P(0 -1.25 13)
P21=P(0 -1.25 15.987)
L20=P20 P21
A open-cad system should be able to import many formats (dxf, step, collada,
x3d ..) but it can have only one native (internal) format.
But with good export-functions this should not be a problem ...
For the import-process the imported format must be translated into the native
format. To improve speed we made the step-translator in C.
The step-import of gcad3d works fine (and very fast) with files from
catia-v5.
For the export-process you can:
- translate the native format into the exportFormat or
- export the objects direct from the (binary) database
The second version is easier to implement, but the output has the
'intelligence' of a dxf-file; you have lost the parametric relations.
To translate a gcad3d-code into stepFormat (not yet implemented)
the first version should be used.
The export to vrml1 and vrml2 is done from the database-objects
(dxf-intelligence is sufficient).
Franz
martin_gnu
On 16 sep, 12:45, Franz Reiter <franz.rei...@cadcam.co.at> wrote:
> Is there a list of pros and contras for TextFormat versus BinaryFormat ?
No. We want to talk with BRL-CAD to talk about this. they have a assci
file similar to your file, but a binary version to native Work in BRL-
CAD.
Is easy build a binary portable file?.
are doubles always the same? In GSL manual i read that doubles are
always IEEE 64 bits standard. In all kind of compilers, in all kind of
architectures?
> Then, regarding TextFormat:
> If you want to use step as native code for an interpreter,
> you have to reorder the whole input.
> The sequence in Step-files is usually not ordered, so you have to load
> the complete file; resolve all references, write out in correct sequence
> (in the new format).
>
> This describes a line in step:
> #449 = TRIMMED_CURVE( '', #869, ( CARTESIAN_POINT( #870 ) ),
> ( CARTESIAN_POINT( #871 ) ), .T., .UNSPECIFIED. );
> #870 = CARTESIAN_POINT( '', ( 0.0, -1.25, 13.0 ) );
> #871 = CARTESIAN_POINT( '', ( 0.0, -1.25, 15.987 ) );
> #869 = LINE( '', #1612, #1613 );
> #1612 = CARTESIAN_POINT( '', ( 0.0, -1.25, 13.0 ) );
> #1613 = VECTOR( '', #2336, 1.0 );
> #2336 = DIRECTION( '', ( 0.0, 0.0, 1.0 ) );
>
> This is the result of the import-process of gcad3d:
> P20=P(0 -1.25 13)
> P21=P(0 -1.25 15.987)
> L20=P20 P21
BRL-CAD have very similar sintax to gcad3d.
> A open-cad system should be able to import many formats (dxf, step, collada,
> x3d ..) but it can have only one native (internal) format.
> But with good export-functions this should not be a problem ...
I totally agree. blender, k-3d and BRL-CAD work with binary native
files. the question like Frank say is. ¿assci or binary?
Other masterful course in CAD by Franz, hehe.
I edit another time the gcad3d opinion page with this comments...
Lars Grobe
> files. the question like Frank say is. ¿assci or binary?
You can even have both and use as needed. E.g. in x3d-world, you can use text encoding during editing, clean-up, validation, use bianry encoding for optimized parsing, use compressed (gz) encoding for wan-access. It is still x3d, you only need a filter or parser able to detect.
Lars.