Re: [freearchitecture] Re: Re: x3d-cad vs. step
Lars O. Grobe
Is it possible to include scripts into a step file?
The background of my thought:
CAD is getting really useful if you are not only able to work on
geometry, but if you can get parametric objects that become application
specific. In today's CADs, these objects are application-specific, the
routine to create geometry from object parameters is in the application.
This means that all exchange formats contain only the resulting
geometry, not e.g. a stair, wall, wheel, engine object.
If I look at e.g. html, there has been a possibility for developers to
include content-generating routines into the content for a while. There
is a library of available function call present in every modern browser
to modify e.g. the content (DOM), so I can put some intelligency into
the content file and do not have to write (and install) a plug-in for
everything.
Now I wonder if something like that could not get introduced into CAD,
in an open way. And here it comes to the STEP format. I would like to
have a geometry of a stair in the STEP-file, and as an attribute the
code that generates the stair. Than I could view the stair in every
STEP-capable CAD, and in those able to interprete the code, could
natively modify the stairs by changing parameters (increase the number
of raisers etc).
Is this possible with STEP?
TIA & CU Lars.
P.S.: I am crossposting this to the new group "open-cad-format" on google.
Lars O. Grobe
can I put a routine written in Express into a Step file creating a stair
geometry defined by paramters that would be understood by all
step-parsers than???
I just try to learn what is possible... ;-) Lars.
Franz Reiter
ad:
> Is it possible to include scripts into a step file?
> I would like to
> have a geometry of a stair in the STEP-file, and as an attribute the
> code that generates the stair.
> Is this possible with STEP?
i think yes; you can append properties to objects or include the code as
user-data.
Geometric programs are a sequence of computations and geometric operations.
You need to have a environment with:
- programming-functions (variables, loops, comparisons, subprograms, IO)
- geometrical functions (rotate point, get tangent of curve, intersect..)
- and functions to create objects.
For this you need a description(language).
So the point is to select/define the programming-language.
If the objects are created you can export them with step or dxf; you can
include the creating program or store it separate.
If you select an existing language (lua, tcl ..) you have to add the
geometrical functions and the object-creating functions.
Autocad gives access to its functions from Lisp, VisualBasic and C++(Arx).
Franz.
Lars O. Grobe
> user-data.
>
> Geometric programs are a sequence of computations and geometric operations.
> You need to have a environment with:
> - programming-functions (variables, loops, comparisons, subprograms, IO)
> - geometrical functions (rotate point, get tangent of curve, intersect..)
> - and functions to create objects.
>
> For this you need a description(language).
I found that in Express you can actually reference values. E.g. you
define a line not as (0,0,0) to (0,10,0) but as (a,b,c) to (d,e,f) and
create or calculate the values for a-f somewhere else. There are
numerical operations available among others.
Now, for making this useable in real world, one would need a library of
procedures e.g. to find intersection points, test for collision /
overlaps etc. This library still could also be written in Express, thus
be a step file, right? So making parametric object cross-platform and
cross-application could start out to be defining the procedures such a
library should make available. Than step files containing parametric
objects (code like the one generating my stair) could rely on these
library functions, which must be standardized, and in case this lbrary
does not exist I just have to send one more Step-file containing the
library - right?
Can Express-procedures call external applications? If yes, how secure is
this?
I am getting more and more excited by this ;-)
CU Lars.
Gertwin
It sounds great embedding scripting in the file format, just like
javascript in html.
I don't have a 3D/solid modeling background so i am not familiar with
step and Express.
Using a well known scripting language is the best way to attract as
many people also from all CAD disciplines.
Having a GIS background i would like to see import from and export to
spatial databases, others maybe would like to see an interface with
FEM solvers.
If we take a general purpose scripting language (f.i. python) that can
call functions from existing external libraries (dll's) all that kind
of things can be done.
This language can also used to write 'exporters' from our file format
to other formats (dxf, etc.), for MicroStation and AutoCAD this is not
nescesary, we can provide plugins in ObjectARX or MDL (don't like that
one) to read and write our format.
Gertwin
Terry Hancock
A caveat -- although scripting is a nice feature, it's also a hazard!
If you can write scripts within the document, you can -- unless one is
very, very careful -- also write viruses into it.
Even on relatively secure systems (e.g. Linux), this is a real threat,
and since the most likely thing to be infected would be the user's
other CAD files, this will be a really nasty problem if it did happen.
From the application developer's PoV, this means any such code must be
run in a sandbox. From the format developers' PoV, it might mean "no
thanks, we'll do without scripting".
Just something to consider.
Cheers,
Terry
--
Terry Hancock (han...@AnansiSpaceworks.com)
Anansi Spaceworks http://www.AnansiSpaceworks.com
Lars Grobe
> very, very careful -- also write viruses into it.
Yes, I had asked for the implications on security too. Still if the capabilities are already there in Step, how are these problems handled today?
CU Lars.
Gertwin
wrote:
> From the application developer's PoV, this means any such code must be
> run in a sandbox.
Yes you are right, the script inside the drawing file should only
access objects in the drawing database, not system objects.
But the program interface used by the application developer must have
access to the local system objects, they produce a add-on or plugin
that run inside the application and is not exchanged with the drawing
file, like AutoLisp run inside AutoCAD and is not in the dwg file.
AutoCAD is what i think the wideliest used cad application, from
AutoLisp you are able to run shell commands from within AutoCAD.
In AutoCAD on startup, on every drawing that is loaded, on every menu
that is loaded you can execute AutoLisp code, not very secure.
We should think about this issue, but if you want to do spread a virus
or so you don't choose a niche CAD application but a browser, mail
application or a word proccessor.
> From the format developers' PoV, it might mean "no
> thanks, we'll do without scripting".
Scripting inside the drawing file is a possibility to offer something
extra, otherwise we can only make a clone of something that excist and
become at best another opendwg or whatever library.
Maybe it is time to list all the possibilities with there pros and
cons and we have and do some benchmarking, read large files and cound
the seconds to parse, not the time to build the database, all the
files should describe elements in a similar (parametric) way.
Also it is interesting how updates are done, i don't get it how gcad3d
handles mutations of the drawing, is every thing done in memory or is
the file updated or are mutations written at the end of the file?
If i can remember the drawing file is used to parse the parameters
when drawing the elements but that can only be done if the file is
kept up to date.
Gertwin
martin_gnu
>
> CAD is getting really useful if you are not only able to work on
> geometry, but if you can get parametric objects that become application
> specific. In today's CADs, these objects are application-specific, the
> routine to create geometry from object parameters is in the application.
> This means that all exchange formats contain only the resulting
> geometry, not e.g. a stair, wall, wheel, engine object.
>
Autodesk solution:
Build a compound primitive in autocad called stair.
Build a autolisp plugin to modify properties of "stairs" primitives
(nº steps, height,..).
Select a stair
Change the properties like you want.
If you want export a DWG file autocad break the stair primitive in
well know primitives (circles, rectangles,...)
You can break the compund primitive by hand using the explode button
in Autocad.
In maya also doing things so. The grass primitive for example works
so. You can modify the grass density, color,height... with properties.
Regards.
martin_gnu
> to other formats (dxf, etc.), for MicroStation and AutoCAD this is not
> nescesary, we can provide plugins in ObjectARX or MDL (don't like that
> one) to read and write our format.
Perfect. perfect.
By now we only works with privative software. It´s very easy build
plugins inside of privative CADs.
If we build a exporter to DXF we depend of Autodesk.
martin_gnu
On 29 sep, 01:22, Terry Hancock <hanc...@anansispaceworks.com> wrote:
> A caveat -- although scripting is a nice feature, it's also a hazard!
I think so. I don´t like HTML philosophy at all. I prefer adobe flash
system for example.
I can not imagine edit a big CAD file by hand using notepad, hehe.
Regards.
martin_gnu
On 29 sep, 23:27, Gertwin <gertwin.gr...@gmail.com> wrote:
>
> But the program interface used by the application developer must have
> access to the local system objects, they produce a add-on or plugin
> that run inside the application and is not exchanged with the drawing
> file, like AutoLisp run inside AutoCAD and is not in the dwg file.
>
> Gertwin
I totally agree with you. Nowadays we want HTML style files for
all....
I don´t see the advantages of internal scripting...
Regards.
Gertwin
> all....
> I don´t see the advantages of internal scripting...
Not anymore by me, a xml file format is not sufficient for writing
drawing mutations, you can not append to a xml file.
A xml file is not suitable as a database file format, updates cost a
large amounts of time.
Internal scripting has no advantage over external scripting, the
external script (like a AutoLisp file) can be exchanged beside the
drawing file if you want to be able to modify the stairs.
If you exchange the script with someone, you know the source where it
comes from, this reduces the security risk.
But what file format are we going to use?
I think the gcad3d format has advantages over the step format because
it is less condensed than gcad3d and it is not ordered.
Gertwin
"Martín RV (OPENGeoMap)"
>
>But what file format are we going to use?
>I think the gcad3d format has advantages over the step format because
>it is less condensed than gcad3d and it is not ordered.
>
>
>
>
because is more easy and we need add several things to the format like
paper space,... Things that STEP can not give us.
I would like a solution like you. I could support STEP o gcad3d, but i
prefer gcad3d. If all people like STEP i would defend STEP also.
Perhaps we can do votings?
Franz Reiter
Gertwin asks:
> Also it is interesting how updates are done, i don't get it how gcad3d
> handles mutations of the drawing, is every thing done in memory or is
gcad3d-mode MAN:
the primary source is held in the editor (in gtk); all changes are done there.
gcad3d-mode CAD:
the primary source is in memory; all changes are done there; first the
ascii-text is modified. Then the modified line (and all following lines) are
re-interpreted, this changes the DB-objects, the DispList and so on.
For CAD-modifications the sourceline is decoded, for (nearly) each type of
command exists a dialog (created automatically from a list). This dialog
displays the parameters (directly the ascii-words). The tab-key previews the
results dynamically, the Enter-key stores the (modified) line.
(CAD-modify/delete starts since V1.1 with Ctrl+selectObj).
For example how to modify a circular surface:
there is the contour (eg a circle) and this contour is declared as a surface;
no holes (islands).
2 sourcelines. (C=circle, A=area):
C1=P(0 0 0) 10
A1=C1
2 Lines = 2 dialogs (for creation=modification).
In step 111 total lines, the most important are:
#58=CIRCLE('',#57,20.) ;
#90=EDGE_CURVE('',#84,#82,#89,.F.) ;
#91=EDGE_LOOP('',(#92,#93)) ;
#94=FACE_OUTER_BOUND('',#91,.T.) ;
#76=PLANE('Plane',#75) ;
#69=TRIMMED_CURVE('',#66,(#67),(#68),.T.,.CARTESIAN.) ;
#82=VERTEX_POINT('',#81) ;
#52=GEOMETRICALLY_BOUNDED_SURFACE_SHAPE_REPRESENTATION('NONE',(#53),#46) ;
How could we manage that directly (if we would treat that native ?)
Franz
Gertwin
> the primary source is held in the editor (in gtk); all changes are done there.
I understand the file is read into a textbuffer, not into binairy
objects.
The DB objects are created by parsing the textbuffer.
> gcad3d-mode CAD:
> the primary source is in memory; all changes are done there; first the
> ascii-text is modified. Then the modified line (and all following lines) are
> re-interpreted, this changes the DB-objects, the DispList and so on.
Input is different but it is basically the same as in manual mode.
>
> For CAD-modifications the sourceline is decoded, for (nearly) each type of
> command exists a dialog (created automatically from a list). This dialog
> displays the parameters (directly the ascii-words). The tab-key previews the
> results dynamically, the Enter-key stores the (modified) line.
> (CAD-modify/delete starts since V1.1 with Ctrl+selectObj).
>
> For example how to modify a circular surface:
> there is the contour (eg a circle) and this contour is declared as a surface;
> no holes (islands).
> 2 sourcelines. (C=circle, A=area):
> C1=P(0 0 0) 10
> A1=C1
> 2 Lines = 2 dialogs (for creation=modification).
I understand, you can define linear elements (lines, arcs etc.), these
linear element can be combined to a boundary and this boundary or
multiple boundaries can be assigned to a area.
Can a area contain multiple exterior boundaries or is there only one
exterior boundary?
I saw you use boolean function to define areas, i think that is common
with solid modeling.
I am also interested if i can build a topology model in a similar way,
something like this (polygon topology)
3 sourcelines. (C=circle K=centroid, T=topology):
C1=P(0 0 0) 10
K1=P(0 0 0)
T1=K1 C1
>
> In step 111 total lines, the most important are:
> #58=CIRCLE('',#57,20.) ;
> #90=EDGE_CURVE('',#84,#82,#89,.F.) ;
> #91=EDGE_LOOP('',(#92,#93)) ;
> #94=FACE_OUTER_BOUND('',#91,.T.) ;
> #76=PLANE('Plane',#75) ;
> #69=TRIMMED_CURVE('',#66,(#67),(#68),.T.,.CARTESIAN.) ;
> #82=VERTEX_POINT('',#81) ;
> #52=GEOMETRICALLY_BOUNDED_SURFACE_SHAPE_REPRESENTATION('NONE',(#53),#46) ;
>
> How could we manage that directly (if we would treat that native ?)
Not coming form a mechanical background i don't prefer step over the
gcad3d format.
I think step is primary for solid modeling, for topology the format is
maybe not suitable.
We have to attract as may users as we can not only gis people,
constructural or mechanical engineers.
I think in it's simpliest way the library is used for a electronic
(2D) drawing board app or am i wrong?
Gertwin
Franz Reiter
ad:
> Can a area contain multiple exterior boundaries or is there only one
> exterior boundary?
only one exterior, but many interior bounds.
> I am also interested if i can build a topology model in a similar way,
> something like this (polygon topology)
> 3 sourcelines. (C=circle K=centroid, T=topology):
> C1=P(0 0 0) 10
> K1=P(0 0 0)
> T1=K1 C1
we use U (union) for a group of objects and B (body) for a closed surface.
We have defined in the last 3 weeks a new object type "pointcloud", which
consists of a group of points in external formats.
You can create a mesh from this points, which is also held in an external
file.
During cad-runtime this files are binary (in the temp-directory), but
permanent storage and loading is done via ascii. Performance is great.
Franz.
Lars O. Grobe
> #58=CIRCLE('',#57,20.) ;
> #90=EDGE_CURVE('',#84,#82,#89,.F.) ;
> #91=EDGE_LOOP('',(#92,#93)) ;
> #94=FACE_OUTER_BOUND('',#91,.T.) ;
> #76=PLANE('Plane',#75) ;
> #69=TRIMMED_CURVE('',#66,(#67),(#68),.T.,.CARTESIAN.) ;
> #82=VERTEX_POINT('',#81) ;
>
#52=GEOMETRICALLY_BOUNDED_SURFACE_SHAPE_REPRESENTATION('NONE',(#53),#46) > ;
> How could we manage that directly (if we would treat that native ?)
Hi Franz!
Well, first, you are using references in your step-example but assign
values in your gcad3d case. So actually you could melt down the
step-file a bit ad make it look simple afaik (I am not a step expert!!!).
But the key here is (again) the goal of all the development. If we are
discussing a format native to gcad3d, then all your performance
arguments are true. This would become a format propietary in the sense
as bound to ONE application, thus optimized to its needs and
functionality. It would still be an open format as gcad3d is open.
When I asked about the goals of the discussion, I learned that there was
a general, one for all applications format to be developed. I actually
expressed my doubts that this will be accepted because of the efforts
needed for parsing entities that are eventually unused in the
application. Actually almost every developer tries to have a native
format close to memory structures and growing with the applications
feature set. That is why I mentioned developments such as vectorsection.
But IF there is the ONE AND ONLY format to be developed, one has to
accept that it will be difficult to parse. And you will have to support
all kinds of unneeded entities, just because in another potential
application it may be needed. And maybe it will never be. For this task,
step seamed to be a great solution, e.g. because of its modularity,
taking at least some years of defining the needs of such an abstract,
everything covering file format, still independent of one application.
So I claim that my first question on this list has not yet been solved.
Are we searching for a file format suitable for gcad3d and its future
developments, or for one that all CAD applications could use without
loss of information? Before answering this, it does not make much sense
to vote or discuss performance and encoding questions imho.
CU Lars.
"Martín RV (OPENGeoMap)"
>
>So I claim that my first question on this list has not yet been solved.
>Are we searching for a file format suitable for gcad3d and its future
>developments, or for one that all CAD applications could use without
>loss of information? Before answering this, it does not make much sense
>to vote or discuss performance and encoding questions imho.
>
>
All people can edit this page with a google account.
I put his page only like temporal. It´s only temporal. This page it´s
like a blog of the most interesting opinions and formats by now.
From my point of view gcad/oca is complete. Besides we need add paper
space and other entities to the format. You talk us that gcad/oca is
only for gcad3D. I don´t think so. I study the file format and it´s
generic for all apllications. I could change my opinion and love STEP
also. Franz Reiter have support for STEP in gcad3D, but he think?? that
it´s very difficult to use in real CAD. This is an open group i think??.
You talk us that STEP is complete. Sean Morrison talks about STEP like a
"beast".
http://groups.google.com/group/open_cad_format/web/brl-cad-opinion
Hugo from Archimedes the other day tell me that he is going to post the
Archimides opinion soon,...
I don´t like STEP because it´s ascii long:
#82=VERTEX_POINT('',#81) ;
I don´t like edit CAD files by notepad else by GUIs. In large files the
software need understand long text like "VERTEX_POINT". If the file
grows up i don´t see that very efficient. We need think in big CAD
files. In the future the CAD files will be bigger (250 Megas for
example), and you will need open-save the file in good time.
What it´s the format used by CATIA?
What it´s the format used by Archicad?
Regards.
Lars O. Grobe
> From my point of view gcad/oca is complete. Besides we need add paper
> space and other entities to the format. You talk us that gcad/oca is
> only for gcad3D. I don愒 think so. I study the file format and it愀
> generic for all apllications.
I think the problem is that claiming something to be complete prevents
it from being open. CAD is a wide field, not even limited to drawing /
modeling. That is one reason why step is complicated, you can extend it
(it is built on top of some kind of programming language) and/or use
only parts (there have been comitees working only on this for years) of
it. I am not a step evangelist, but it seams to be really important to
exactly define the project goals here before discussing implementation.
This is just to avoid a step back.
If you define open cad format as for "geometric cad data a output
options" with a reference implementation being gcad3d, fine. You can
even release updates of the specification together with the application.
But I started to think as your proposed general, the "ONE" CAD format,
and that finally led me to step.
> You talk us that STEP is complete. Sean Morrison talks about STEP like a
> "beast".
> http://groups.google.com/group/open_cad_format/web/brl-cad-opinion
;-) Still he has to implement it right now.
> I don愒 like STEP because it愀 ascii long:
Please forget about that ascii/binary stuff for now, as you can encode
virtually anything both in ascii and binary. Also you will find that for
the same reason that the ascii file is long, it will compress well. It
may take more effort to parse, but it is not about file size afaik.
So I would suggest that we really define what we want, very detailed...
CU Lars.
Franz Reiter
concerning:
> But IF there is the ONE AND ONLY format to be developed, one has to
> accept that it will be difficult to parse. And you will have to support
> all kinds of unneeded entities, just because in another potential
> application it may be needed.
I think, that it will not be possible to fulfill all goals with one program.
I think that there exists no cad-program, that can represent all step-codes.
> Are we searching for a file format suitable for gcad3d and its future
> developments, or for one that all CAD applications could use without
> loss of information? Before answering this,
> it does not make much sense discuss performance ..
performance IS important; and i think that programmers can provide valuable
infos on performance and how to implement.
The decision of the implementation-language can be more important than the
language. Internally you have to work binary; so you can change the
import-format easier than the software.
That means also that you can produce and test code (routines) before the
format is defined !
Ad:
> What it´s the format used by CATIA?
both (Catia-V4 (Unix only) an Catia-V5 (Unix and MS)) work with binary Models,
but Iges & Step Import & Export works fine. The native filestructure is
proprietary (not open & not documented).
Franz
Lars O. Grobe
>> accept that it will be difficult to parse. And you will have to support
>> all kinds of unneeded entities, just because in another potential
>> application it may be needed.
> I think, that it will not be possible to fulfill all goals with one program.
> I think that there exists no cad-program, that can represent all step-codes.
That's a misunderstanding. By "support" I mean that the format would
have to support everything, not one application. I thik we have to be
clear distinguishing between application and format in this discussion
if we do not want to get completely confused ;-)
> performance IS important; and i think that programmers can provide valuable
> infos on performance and how to implement.
Of course it is, but before having described the problem how to optimize
the solution?
> The decision of the implementation-language can be more important than the
> language. Internally you have to work binary; so you can change the
> import-format easier than the software.
That is again true for an application-bound format. If you are
discussing an open standard it is the opposite. It may take months to
change an application according to the standard. Changing the standard
through all comitees and get it accepted and implemented in all other
applications takes years.
Again, I think I widely agree. I doubted that using a general file
format suitable for ALL imagineable CADs as a native format would be
possible. But than the idea came up - that was why I mentioned step. If
we give up this approach to support every feature from 2d sketching to
modeling, product info, material, csg, ... say make a format for ONE
application, everything will be much simpler. It is leading back to
solutions like vectorsection than when talking about interoperability
between different CAD applications.
The point is that we should agree on one of both approaches. Before that
I cannot have an opinion about encodings etc...
CU Lars.
Franz Reiter
ad:
> That is again true for an application-bound format. If you are
> discussing an open standard it is the opposite.
i think that all ascii-formats are open standards;
i guess that an application-bound format is binary, proprietary (not
documented).?
The ascii-description of geometry via P#=<pointCoords> and so on comes from
the seventies; most NC-processors (eg Exapt ..) use this Format (even
today !)
Franz
Lars O. Grobe
> i guess that an application-bound format is binary, proprietary (not
> documented).?
Hi Franz,
the point I am trying to express here is not about technical
specifications but about the process to get a file format, being binary
or asci or whatever, into an open standard accepted and approved such
that it can be and will be accepted by content creators as well as by
developers of free and closed source software. Of course all
ascii-formats are "open" in some way. But noone will use it if there is
not something like an agreement between contributors (that is what
people try here, right?), users (small scale and industry) and a certain
longetivity.
An example for an "open standard" in the definition "open as ascii" is
dxf. But as it is actually only the documented format of Autocad,
changing with almost every release of the software, you get into trouble
all the time. IF I have to use dxf as an exchange format, I almost use
"Autocad 12"-compatible dxf as an output, because than most parsers will
read it.
Take standards like html/xhtml/docbook/opendocument - they are specified
in detail, most of them even before implemented completely in any
application. They won't be parsed perfectly in older apps, but you do
not get the "unsupported version" popup - and the next release will have
an improved parser. But it is easier to agree on them, and people can
start to implement them. See what kind of support e.g. the fact that
opendocument became an ISO-standard created for Openoffice etc. - and
made companies like IBM or Google bring their office products into
position argueing with that argument!
My arguments applies only on the idea of an application-independent
standard. There this standardization process is an important factor, and
you cannot change at will. If you take the application-specific
approach, you do not have to care about it - people are always free to
download the latest release of gcad3d anyway, so why care about changes
in the format. But than do not wait for commercial providers to write
parsers.
CU Lars.
Gertwin
> I doubted that using a general file
> format suitable for ALL imagineable CADs as a native format would be
> possible. But than the idea came up - that was why I mentioned step. If
> we give up this approach to support every feature from 2d sketching to
> modeling, product info, material, csg, ... say make a format for ONE
> application, everything will be much simpler. It is leading back to
> solutions like vectorsection than when talking about interoperability
> between different CAD applications.
Just a thought:
Why should there exists one file format?
All the features are build from primitives (point, lines, etc.).
If there is one format describing the primitives and additional
formats describing branch specific
The 2d sketching apps uses only the primitives format, solid modeling
applications need additions from separate specifications.
Something like namespaces in xml, a csg namespace, a gis namespace
etc..
It will take a lot of time to define one huge format, better to break
up in parts.
Also it is easier to keep interest in a part that is for your special
needs.
The first/basic part is defining the primitives and the operations on
the primitives.
Additional parts can be defined separate, only with input of people
interested in it.
In the end there is a basic cad engine and several loadable modules in
wich the namespaces are implemented.
The 2d sketch appl. only uses the basic engine, apps like gcad3d can
use the basic engine and additional modules.
There will always be a loss of information if an application reads a
file containing namespaces it does not support.
Gertwin
Lars O. Grobe
> Just a thought:
>
> Why should there exists one file format?
> All the features are build from primitives (point, lines, etc.).
> If there is one format describing the primitives and additional
> formats describing branch specific
> The 2d sketching apps uses only the primitives format, solid modeling
> applications need additions from separate specifications.
> Something like namespaces in xml, a csg namespace, a gis namespace
> etc..
>
> It will take a lot of time to define one huge format, better to break
> up in parts.
> Also it is easier to keep interest in a part that is for your special
> needs.
What you describe is exactly STEP. At least in concept. It took them
several years to define these application fields. So if that is what we
want let's take step. You can recode it for performance, even reorder
it. Maybe reduce it to a static file format, taking away extendibility
(using no express - which has an open source implementation btw). But
keeping at least the modules and the entities from STEP would allow a
transfer new_format -> step without pain (the opposite way would still
loose whatever you do not want to support).
BTW:
The NIST library and other tools: http://www.mel.nist.gov/msid/scl/SCL.htm
There is a Python-binding called pyexpress in development at ESA that is
or is supposed to become opensource: pyexpress
Engineering eXchange For Free http://www.exff.org/
They are also working on a binary encoding of step data (express)
Anyway, this was again all related to an application-independent format,
but modular.
CU Lars.
martin_gnu
On Oct 4, 9:17 pm, Gertwin <gertwin.gr...@gmail.com> wrote:
>
> Why should there exists one file format?
> All the features are build from primitives (point, lines, etc.).
> If there is one format describing the primitives and additional
> formats describing branch specific
> The 2d sketching apps uses only the primitives format, solid modeling
> applications need additions from separate specifications.
> Something like namespaces in xml, a csg namespace, a gis namespace
> etc..
I totally agree with you in this. Autocad have a system based in
compound primivites (binary and closed...)
>
> In the end there is a basic cad engine and several loadable modules in
> wich the namespaces are implemented.
This sound great.
>
> There will always be a loss of information if an application reads a
> file containing namespaces it does not support.
>
This is not a problem. If i would be working with clothoids
primitives, before give the map to a architect i would break clothoids
in simple primitives, and for me i don´t want mechanical primitives...
Regards.
martin_gnu
On Oct 4, 5:20 pm, "Lars O. Grobe" <gr...@gmx.net> wrote:
>
> An example for an "open standard" in the definition "open as ascii" is
> dxf. But as it is actually only the documented format of Autocad,
> changing with almost every release of the software, you get into trouble
> all the time. IF I have to use dxf as an exchange format, I almost use
> "Autocad 12"-compatible dxf as an output, because than most parsers will
> read it.
>
Franz Reiter is different to Autodesk hehe. You are true about depend
of company, but here we don´t let that kind of things (GPL,...). I am
thinking begin, if this mail list work, a hosting to promote engineers
for freedom.
> Take standards like html/xhtml/docbook/opendocument - they are specified
> in detail, most of them even before implemented completely in any
> application. They won't be parsed perfectly in older apps, but you do
> not get the "unsupported version" popup - and the next release will have
> an improved parser. But it is easier to agree on them, and people can
> start to implement them. See what kind of support e.g. the fact that
> opendocument became an ISO-standard created for Openoffice etc. - and
> made companies like IBM or Google bring their office products into
> position argueing with that argument!
>
I put links to STEP here:
http://groups.google.com/group/open_cad_format/web/free-libraries
Autodesk build de landXML open format. Do you think that Autodesk want
a speed format or a open format??.
KML is form google earth,...
Many company open formats are to get more $$$$$.
I think that w3c format are great, but from this wc3 consortium was
born a lot of XML confusing open standards.
> My arguments applies only on the idea of an application-independent
> standard. There this standardization process is an important factor, and
> you cannot change at will. If you take the application-specific
> approach, you do not have to care about it - people are always free to
> download the latest release of gcad3d anyway, so why care about changes
> in the format. But than do not wait for commercial providers to write
> parsers.
We don´t love gcad3d format. We only want use gcad/oca like style and
guidelines. If you see in this list you can see to Franz doing free
propositions to the format, but he haven`t implement it in gcad3d.
Franz is from Germany but he is not Adolf Hitler hehe. We all can to
add primitives to gcad/oca. This is not the Franz Reiter format. I
only think that his style is very good to build a complete cad format.
He have a gcad3d with complete basic primitives and we can see that
work fine, but we need add especific primitives to architecture, and
other Engineering sciences.
In a free mail list, we can get opinions about architecs, land
surveyors, etc... to build the best format for all. I think that STEP
is oriented to Mechanical Engineering and i don´t find good
definitions to GIS/photogrammetry/civil,...
If someone have sample for architectural, surveying, ... in STEP i
would like see in this list.
Someone know where i can find a good STEP manual??
It´s supposed that we would need add paper space to STEP???
>
> CU Lars.
Lars O. Grobe
> Franz Reiter is different to Autodesk hehe. You are true about depend
> of company, but here we don´t let that kind of things (GPL,...). I am
> thinking begin, if this mail list work, a hosting to promote engineers
> for freedom.
Ok, that's all fine for me, we should only be aware that the format will
be application-bound than. That was all I wanted to express.
> Autodesk build de landXML open format. Do you think that Autodesk want
> a speed format or a open format??.
> KML is form google earth,...
> Many company open formats are to get more $$$$$.
Yes, it is a marketing argument today to open formats. They are still
bound to the application, meaning they can change with every release.
Than every 3rd-party vendor will have to adopt his app if he is
supporting that format - accepting to be always in the second row. That
is why application-bound formats are supported only if they dominate the
market.
> I think that w3c format are great, but from this wc3 consortium was
> born a lot of XML confusing open standards.
Well, quite successful yet ;-)
> Someone know where i can find a good STEP manual??
One last thing I had to post before the week-end:
http://www.pdtsolutions.co.uk/book/STEPbook.pdf
"Franz is from Germany but he is not Adolf Hitler hehe"
Hahaaa me to I was born there... still writing this in Istanbul now.
CU Lars.
"Martín RV (OPENGeoMap)"
http://groups.google.com/group/open_cad_format/web/open-cad-format
It´s a great document to learn. I don´t have any time this week, but i hope find a hour next week to study something this. What i don´t see it´s STEP code sample, only text explaining CAD teories...
http://open_cad_format.googlegroups.com/web/STEPbook.pdf
*All people it´s free to add interesting documents and links for us*
"Franz is from Germany but he is not Adolf Hitler hehe" Hahaaa me to I was born there... still writing this in Istanbul now.
Regards.