Any interest? Both gEDA and KiCad are interested.

122 views
Skip to first unread message

timofonic timofonic

unread,
Jan 11, 2016, 2:40:13 AM1/11/16
to open_cad_format
Hello.

What about resurrecting your project?

EdaCore was another failed try...

FOSDEM is there. There's discussions about it in geda-users...

Are you still alive?

Kind regards.

Bruno Postle

unread,
Jan 11, 2016, 10:07:30 AM1/11/16
to open_ca...@googlegroups.com

What is the background to this? The reason I wanted a new file format (and this still applies) is to enable the kind of forking/merging workflow that we enjoy when writing software - this being a prerequisite for a proper sharing economy for physical things built around open designs. In all other circumstances it is probably simpler to reuse an existing format.

But this way of working would require some basic changes to the way CAD software works, it isn't enough to just add another parser/serialiser to an existing tool.

--
Bruno

franz....@cadcam.co.at

unread,
Jan 11, 2016, 12:24:41 PM1/11/16
to open_cad_format
Hallo,
ad: "would require some basic changes to the way CAD software works" ..
what do you mean ?
Franz

Christopher Sean Morrison

unread,
Jan 12, 2016, 2:45:15 AM1/12/16
to open_cad_format

On Monday, January 11, 2016 at 2:40:13 AM UTC-5, timofonic timofonic wrote:
Hello.

What about resurrecting your project?

EdaCore was another failed try...

FOSDEM is there. There's discussions about it in geda-users...

What do you mean by this?
 
Are you still alive?

Yes and no.  Obviously no visible activity here in a long while, but BRL-CAD is still interested in making headway on data exchange among the open source CAx efforts.

For BRL-CAD, we're approaching the problem from a somewhat different angle in two ways:  1) Establish a non-profit group that can help coordinate and support collaborations such as this one.  More on this at a later date.  2) Instead of trying to create yet another format (obligatory: https://xkcd.com/927/), we're creating a "GCV" geometry conversion library that sports reader, filtering, and writer plugin modules.

The goal is for this GCV lib to become its own stand-alone project, but right now it heavily leverages BRL-CAD's object database as a pivoting container (it can hold anything).  This was also the fastest way to set up a framework for sharing our 24+ converters that we've developed over the past couple decades.  We've written a paper up with documentation, basic examples of plugins, etc, and will be formally publishing it this year.

Cheers!
Sean

Bruno Postle

unread,
Jan 12, 2016, 2:45:15 AM1/12/16
to open_ca...@googlegroups.com
On 11 January 2016 at 16:52, wrote:
>
> ad: "would require some basic changes to the way CAD software works" ..
> what do you mean ?

To enable a forking/merging workflow, the CAD tool has to be careful
to only update data that has changed. For example: opening a project,
changing the colour of a 'line' element, then saving, should result in
minimal changes - the 'line' element should be in the same file
position, have the same GID as it had before, and any other data
should be byte for byte identical - even if the original project was
created by a different CAD tool and contains unknown data specific to
that tool.

There are three ways to do this as I see it:

1. Have an extremely strict formatting and ordering convention so you
can be sure that two different tools will create exactly the same
serialised data, even for unknown data.
2. Don't touch the original data, update just the part of the file
that has changed.
3. Alternatively, keep all projects on a central database server that
keeps track of users, software versions and data versions, then use a
network API to access it.

Each of these involves more than just a new file format, CAD tools
that simply parse everything on load and serialise on save are not
going to be good enough.

--
Bruno

Franz

unread,
Jan 12, 2016, 4:00:16 AM1/12/16
to open_cad_format
CAD-software is very extensive, collaboration is necessary.
Collaboration needs standards and basic tools.
Standards not only for the exchange-format, also for the basic functions of the binary-cad-base, the viewer, the geometry-module, the format-exchange-modules, and the user-interface should be defined. With basic rules for non-standard object-types or object-attributes.
Math could be eternal; the basic functions of CAD-software live VERY long; so the comments in the code are very helpful.
Franz

Sean

unread,
Jan 13, 2016, 2:31:21 AM1/13/16
to open_cad_format


On Tuesday, January 12, 2016 at 4:00:16 AM UTC-5, Franz wrote:
CAD-software is very extensive, collaboration is necessary.

Amen!

Every single new open source CAD project I've seen pop up over the last 10 years has died within 2 years because the original author(s) undervalued the importance of collaborating (or underestimated the amount of work to even baseline features).
 
Collaboration needs standards and basic tools.

I generalize that to collaboration requires sharing and mutual benefit.  Standards and basic tools are enablers.
 
Standards not only for the exchange-format, also for the basic functions of the binary-cad-base, the viewer, the geometry-module, the format-exchange-modules, and the user-interface should be defined.

Guess I disagree that all of these are required but, more importantly, I really don't see that kind of collaboration happening any time soon -- and I've been actively trying for years.  Certainly agree that they "should" be defined, but that task is insurmountable across all the CAx domains, to even agree on basic scoping/requirements.  There's a reason that even the commercial companies with consistent steering by NIST have had serious trouble even with basic data exchange standardization (e.g., ISO STEP).
 
With basic rules for non-standard object-types or object-attributes.

This is something I've been wrestling with and thinking about quite a bit lately.  With our GCV project, there's a significant plugin architecture question as to whether the core uses a standard pivoting format OR the core declares a dynamic schema and plugins describe their data in those terms.  Merits to both, but I'm currently leaning towards the latter.  This avoids disagreements over encoding and file properties.

What this requires, though, is coming up with an object model schema where there is no notion of standard object types or attributes.  For example, some extensible JSON-style container schema just might work.

Bruno, for what it's worth, BRL-CAD's .g geometry file format behaves exactly as you suggest.  It's the only CAD format I'm aware of where you can literally "cat file1.g file2.g > file3.g" and end up with a completely valid file and this was by design.  It's a layered object database so changes to are also minimized to just the bits of data that changed (i.e., your option #2).  This consequently is usually highly performant too, with minimal seeks/read/write operations, letting BRL-CAD open geometry files with equivalent data faster than .. well, pretty much anyone else's format.

We've considered submitting it to ISO or ANSI, but that's a ton of work with no mutual gain identified ...

Cheers!
Sean

Franz

unread,
Jan 13, 2016, 3:05:44 AM1/13/16
to open_cad_format
Where can i find a description of the "BRL-CAD's .g geometry file format" (sorry - did not find it with google) ?
Franz

Bruno Postle

unread,
Jan 13, 2016, 6:32:33 AM1/13/16
to open_ca...@googlegroups.com
On 13 January 2016 at 07:26, Sean <brl...@gmail.com> wrote:
>
> Bruno, for what it's worth, BRL-CAD's .g geometry file format behaves
> exactly as you suggest. It's the only CAD format I'm aware of where you can
> literally "cat file1.g file2.g > file3.g" and end up with a completely valid
> file and this was by design. It's a layered object database so changes to
> are also minimized to just the bits of data that changed (i.e., your option
> #2). This consequently is usually highly performant too, with minimal
> seeks/read/write operations, letting BRL-CAD open geometry files with
> equivalent data faster than .. well, pretty much anyone else's format.

This sounds great, the threshold for me would be: if I was able to put
a CAD project on github, let other people fork and edit it using
different tools, then pull and merge their changes without corrupting
the data, then I have a CAD file format that the whole world will have
to adopt eventually. There is no point designing new file formats
unless this is the aim.

This doesn't _have_ to use text files, it would still work ok with
custom diff/patch tools that know about the file format internals
(since every object would need to have a persistent GUID, this GUID
has to make it into every patch file).

--
Bruno

Dirk Steuwer

unread,
Jan 14, 2016, 4:50:33 AM1/14/16
to open_ca...@googlegroups.com
as a non-programmer, id like to bring in my 2c here as well:
because of mostly binary cad file formats, i found forking to be a
"dead end" when checking cad files into version control.
i choose svn over git, because it lets you lock files, so that only
one person at a time can gain access to a specific file, basically to
prevent any forking. (no diff viewer at hand means duplicate work is
often wasted..)
however, it would be great if forking would be possible. this creates
the need to be able to "diff"-view the changes of others. Either the
cad-files a human readable/understandable-textiles that can be
highlighted by any text-diff-viewer or the cad-soft comes with an
internal diff-viewer to highlight changes in 3D and elsewhere between
two files. Or there is an independent cadfile-diffviewer, that can
handle this for a given format.

*dreaming on:*
i was wondering, if it would even be possible to design by
"web-browser" and the "back end" is a mix of version-control and
cad-rendering engine, that sends the result back to any web-user,
essentially creating a one-stop-shop for cad-design as well as
project-management, update-notification, etc like this is done via
trac or redmine for software development.
*dreaming off*

so exchangeable format is important, but diff-viewing to enable a
version-control process with forking is an even higher priority in my
view.
quite often, the specific needs in a design process force you to
choose cad-tool A, so anyone in the project needs to use that as well...
i can imagine, that the definition of a format that supports any kind
of future extension to it is very demanding...

-dirk

Zitat von Bruno Postle <br...@postle.net>:
> --
> You received this message because you are subscribed to the Google
> Groups "open_cad_format" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to open_cad_form...@googlegroups.com.
> To post to this group, send an email to open_ca...@googlegroups.com.
> Visit this group at https://groups.google.com/group/open_cad_format.
> For more options, visit https://groups.google.com/d/optout.



Franz

unread,
Jan 14, 2016, 5:38:06 AM1/14/16
to open_cad_format, di...@steuwer.de
ad:

"so exchangeable format is important,"
and

"the definition of a format that supports any kind of future extension to it is very demanding..."

DXF and many other formats will be used for many more years.

Format exchange works (usually) this way:
- import objects into native format
- store objects in CAD-DB (native format!)
- export from native format into export-format.

Modification of objects by:
- get object from DB as native binary object
- modify the binary object
- store back.

If there is no spec / definition of the native format and no basic toolset for reading / writing; how could one make eg a "diff-viewer" or even add or modify objects ?
Which open-source CAD-DB's exist / could be compared ?

Duncan Lithgow

unread,
Jan 14, 2016, 5:20:18 PM1/14/16
to open_ca...@googlegroups.com
Nice surprise when I opened my email today and noticed some activity here!

I'm a user of CAD software not a developer. I can't see any mention here of leveraging the IFC format (https://en.wikipedia.org/wiki/Industry_Foundation_Classes), which I know FreeCAD has started doing (http://www.freecadweb.org/wiki/index.php?title=Arch_IFC). That may be a good solution for describing geometry, and I know of one CAD application which uses IFC natively, I don't remember which, and it's not a mainstream project.

Duncan
--
With or without religion, good people can behave well and bad people can do evil; but for good people to do evil — that takes religion.

Steven Weinberg

Sean

unread,
Jan 14, 2016, 5:20:18 PM1/14/16
to open_cad_format

On Wednesday, January 13, 2016 at 3:05:44 AM UTC-5, Franz wrote:
Where can i find a description of the "BRL-CAD's .g geometry file format" (sorry - did not find it with google) ?
Franz
 
Here:

This is an older unannotated version, but sections 1.1 and 2.1 have the core meat of the extensible object structure.  Of course, similar to other binary formats, we provide a library for reading and writing.

We obviously think it's a great format with lots of potential for a whole host of reasons, but our current focus is on GCV.  With our GCV project, format exchange becomes more transparent.  This is intentionally similar to how imagemagick and libmagick don't care (API-wise) about image formats, you just open your image file and work with it.  With GCV, you do the same and so long as there's a reader plugin that recognizes that format, you can get at the objects or export them through any of the export plugins. 

Cheers!
Sean

Sean

unread,
Jan 14, 2016, 5:20:18 PM1/14/16
to open_cad_format

On Wednesday, January 13, 2016 at 6:32:33 AM UTC-5, Bruno wrote:

This sounds great, the threshold for me would be: if I was able to put
a CAD project on github, let other people fork and edit it using
different tools, then pull and merge their changes without corrupting
the data, then I have a CAD file format that the whole world will have
to adopt eventually. There is no point designing new file formats
unless this is the aim.

This is also possible with the .g format today at the object-level if objects are encoded using the format's "submodel" construct where you put objects into their own file(s).  This isn't a feature we use ourselves very often because, well, multiple file opens are obviously slower than a single file open (similar seeks+reads).  But it will work exactly as you suggest and even work with existing revision control diffing (albeit as opaque binary changes).  That all said, you'd have a problem with the .g submodel approach if you wanted to go below the object level and localize diffing to a specific NURBS surface, for example, on the same object.  You're limited to the notions of "object" that are registered in the .g format. 

That said, I think GitHub as a target is a terrible idea. :)  Revision controlled geometry is great, leveraging a distributed or centralized VCS is really cool -- we had a project doing exactly that, but halted work on it 4 years ago when funding was cut.  GitHub (the platform), though, is rather ill-suited for geometry due to all the specializations needed to do it well, some of which you noted.

This doesn't _have_ to use text files, it would still work ok with
custom diff/patch tools that know about the file format internals
(since every object would need to have a persistent GUID, this GUID
has to make it into every patch file).

We have a gdiff tool for this too. :)  One of our more successful efforts two years ago was development of 2-way and 3-way differencing and merging of 3D geometry.  This was a stepping stone so production users could manually do their own version control management merging and comparing changes from others, with the obvious longer-term goal of hooking this up behind a VCS that is auto-integrated with our main tools.

That all said, I don't think most of that matters (much) as this problem has been hashed out at length in the web space where another approach has shaken out.  Instead of trying to agree on encoding formats, a services approach that has the ability to exchange object schema notations may be the way to go.  This isn't the format users work with, or even necessarily the storage/encoding format, but a means for pivoting between formats in a way that preserves as much information as possible.

Cheers!
Sean

Franz

unread,
Jan 16, 2016, 4:06:51 AM1/16/16
to open_cad_format
ad:
" IFC format (https://en.wikipedia.org/wiki/Industry_Foundation_Classes)"
for me this format (it is STEP) is -
- is not really free (CHF 178 for the spec! See eg:
  http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=33713
- is extremely complicated
- but - really great: it is ascii-text.

ad:
GCV and http://brlcad.org/w/images/2/2d/BRL_CAD_g_format_V5.pdf:
when would it be possible to eg import some objects in DXF,
modify some coordinates, export also as DXF ?

Franz

Charlie

unread,
Jan 19, 2016, 7:40:26 AM1/19/16
to open_cad_format
The STEP file format (also used by IFC) is being updated.   
Edition 3 can be found here
and includes
  • upward compatibility with earlier versions
  • digital signatures and multi-file ZIP/directories
  • ECMAscript programs
  • persistent GUIDs (ANCHOR)
  • URLs to link files (REFERENCE)
Thus, it supports multiple files, linking outside a single CAD system, modularity, abstraction, security, and dynamic programming.   These capabilities could support some fork/merge workflows for version control/configuration management.   

Note that IFC already contains a GUID.   STEP also has an existing capability to add identifiers to shape_aspects that can be assigned to any geometric_representation_item.  

Franz

unread,
Jan 19, 2016, 8:09:58 AM1/19/16
to open_cad_format

ISO 10303-21 starts with:
 
.. neither this ISO standard nor any extract from it may be reproduced, stored in a retrieval system or ..
 
- is this an OPEN cad format ?

Franz
 

Sean

unread,
Jan 20, 2016, 3:49:15 AM1/20/16
to open_cad_format


On Saturday, January 16, 2016 at 4:06:51 AM UTC-5, Franz wrote:
ad:
" IFC format (https://en.wikipedia.org/wiki/Industry_Foundation_Classes)"
for me this format (it is STEP) is -
- is not really free (CHF 178 for the spec! See eg:
  http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=33713
- is extremely complicated
- but - really great: it is ascii-text.

I call STEP the "union of all CAD formats", which is both a benefit and a detriment.  STEP (and by extension IFC) suffers from several problems, but is mature, mostly comprehensive, and has come the closest to promoting interoperability among commercial CAD vendors that really just want everyone to import...

It's definitely from a different world than open source, but is an important format (obviously) to learn from, learn from, and leverage.
 
ad:
GCV and http://brlcad.org/w/images/2/2d/BRL_CAD_g_format_V5.pdf:
when would it be possible to eg import some objects in DXF,
modify some coordinates, export also as DXF ?

Really hard to give an estimate on that -- hey, it's open source... :)  It could be a project this summer, a couple years out, or done in a week (unlikely).  We're started focused in scope to simple import+filtering+output so we make sure that part of the API is good to go.

Initial filtering does not yet include individual coordinate editing, but high-level operations like selecting objects to work on, tessellation, and mesh decimation.  Namely, critical bits required to go from one format to another with minimal loss (e.g., from IGES NURBS entities to OBJ triangles).  The focus is on I/O so application developers don't have to spend years implementing support for the latest format ... or worse, limit their support to worst common denominator (looking at you STL).

I can say that DXF is one of the formats under crosshair because we already have a converter for it, so integration is easy.  It's nearly identical in complexity with OBJ, too, which is done.  First round included STL, OBJ, VRML, BRL-CAD, and a DoD-specific format.  Next up, we really want STEP AP203 (solid entities, followed by non-solid) since that introduces additional challenges, but will probably require funding or some seriously concerted effort.  There's a dozen remaining, but some of the more important ones as I see it are DXF, X3D, IGES, and STEP (203, 214, and 242).

Cheers!
Sean

Franz

unread,
Jan 20, 2016, 3:54:01 AM1/20/16
to open_cad_format
ad "Initial filtering does not yet include individual coordinate editing ..":

With "modify some coordinates" i did mean:

- start a plugin (a user-function) doing:
  - get object(s) out of (with cad-function)
  - modify object(s) (user function)
  - store back to Cad-DB (with cad-function)

This would mean that the Cad-system provides functions:
- import file into Cad-DB
- export Cad-DB into file
- get object(s) out of Cad-DB (into memSpace, binary)
- store object(s) in Cad-DB

Is this correct ?
Franz

Sean

unread,
Jan 20, 2016, 8:50:48 AM1/20/16
to open_cad_format

GCV is intended to be a universal converter framework.  The library consists of plugins that can be importers, exporters, or filters.  In order to do individual coordinate editing/modification, there would either need to exist a filter with some defined edit interface or you'd need to be an application developer, as you noted.  If such a filter existed, then users wouldn't need to write any code.


On Wednesday, January 20, 2016 at 3:54:01 AM UTC-5, Franz wrote:
ad "Initial filtering does not yet include individual coordinate editing ..":

With "modify some coordinates" i did mean:

- start a plugin (a user-function) doing:
  - get object(s) out of (with cad-function)
  - modify object(s) (user function)
  - store back to Cad-DB (with cad-function)

Aha, I think this gets at a nomenclature difference.  To me, a user in this context is not necessarily someone that needed to write any code.  They can just use importers, exporters, filters that have been made available to them.  If the user is an application dev, then they absolutely could create a plugin that does exactly this and is the intended goal of building up a GCV plugin ecosystem. 

This would mean that the Cad-system provides functions:
- import file into Cad-DB
- export Cad-DB into file
- get object(s) out of Cad-DB (into memSpace, binary)
- store object(s) in Cad-DB

Is this correct ?
Franz

Yes, this is the way it works now.  If you're an application developer, you can get at the Cad-DB objects and do whatever you want with them but that's not GCV doing anything.  The hope is that people contribute / publish interesting plugins for GCV that suit their needs (and hopefully the needs of someone else).

Cheers!
Sean


Franz

unread,
Jan 24, 2016, 3:24:40 AM1/24/16
to open_cad_format
This is also the way gcad is designed; additional modules are:
- user-interface (an interface between the grafic user-in/output and eg gtk)
- the viewer (displays the Cad-DB objects via OpenGL)
- interactive module (provides all functions for creation and modification of objs)
- some others (plugin-interface, script-interface, interactivity, remote-control, ..)

We tried to separate all modules strictly.
The change from Gtk2 to Gtk3 was very expensive so we designed a interface;
this simplifies the menu-design and we have to change only the interface.

I think there exists a lot of software for the functions mentioned,
but it does do not fit together. Maybe the problem is the lack of docu ..
Franz

Sabu Francis

unread,
Jan 27, 2016, 6:53:32 AM1/27/16
to open_ca...@googlegroups.com
Hi
Sorry, The send button got pressed by mistake

... to continue

That intro was to form the backdrop to my criticism of IFC and conventional BIM. There seems to be a bias towards built-matter. Spaces are also represented, some may claim -- but my contention is that they should be represented at equal priority as the built matter. Only then can we represent the ongoing design process. Else, all the representation would gravitate towards that point in time in the design process where the design has been already fleshed out. If I put that crudely -- the horse has already largely run away from the stables by then


I would like to open-source my own work in this area. My software is called "TAD" (The Architect's Desktop) and I am looking for collaborators who can work on this. Some initial documents are available here http://ww3.teamtad.com 

There, I promote "Open source in architecture" I believe open-sourcing architecture should necessarily start at the design stage and not at the construction stage (There are some open-source construction projects and some very interesting and useful examples there) For, only during the design process can we really live in "parallel universes" where we can objectively "live" inside our alternate creations at the same time, and then choose one which will then go to the singular real universe out in the physical world

I have founded a company for this work. At this point in time, our company is just too small to give a very polished product. My work was used in all the projects I did as an architect (almost 25 years of work) but I understand that architects would need a more holistic and professional support. I had not given too much publicity all these years. It would be nice if I can get people here to join this

We are also considering taking TAD out, not only as an "open source" software; but also set up an "Open Value Network" kind of organization to promote it

A lot has been done with TAD but a huge lot more need to be done. This talk of data-formats both of CAD and BIM must be done in context of the actual practice of architecture and the demands of society that this subject has to meet

Thanks for listening. My company website is http://syncspace.com Currently, we hope to make some revenues by bringing out general purpose graphical, space based solutions that everyone can enjoy on the Internet. We will surely enter the technical field too -- once we are stronger

Regards
Sabu Francis

On Sun, Jan 24, 2016 at 3:15 PM, Sabu Francis <sabuf...@gmail.com> wrote:
Hi
I am from India. I am both a practising architect and also a researcher in the field of architetural representation systems. Initially I was only practising and had the proverbial frog-in-the-well effect, sitting in one corner oblivious about what is happening elsewhere. India got the www only in 1996 and it was extremely slow and costly too. 

Being isolated had its advantages too, I guess. I developed a BIM system based around spaces; instead of built-matter. Architecture has a "figure-ground" epistemology issue. We need to represent both the built matter as well the space. But one forms the background of the other. Traditional CAD and even conventional BIM discards representing spaces. After all, when the building is built, we do not have to "build" the space. By the virtue of building what is to be built, the spaces emerge. 

--
You received this message because you are subscribed to the Google Groups "open_cad_format" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open_cad_form...@googlegroups.com.
To post to this group, send email to open_ca...@googlegroups.com.

Sabu Francis

unread,
Jan 27, 2016, 6:53:33 AM1/27/16
to open_ca...@googlegroups.com
Hi
I am from India. I am both a practising architect and also a researcher in the field of architetural representation systems. Initially I was only practising and had the proverbial frog-in-the-well effect, sitting in one corner oblivious about what is happening elsewhere. India got the www only in 1996 and it was extremely slow and costly too. 

Being isolated had its advantages too, I guess. I developed a BIM system based around spaces; instead of built-matter. Architecture has a "figure-ground" epistemology issue. We need to represent both the built matter as well the space. But one forms the background of the other. Traditional CAD and even conventional BIM discards representing spaces. After all, when the building is built, we do not have to "build" the space. By the virtue of building what is to be built, the spaces emerge. 
On Sun, Jan 24, 2016 at 1:54 PM, Franz <franz....@cadcam.co.at> wrote:

--

Duncan Lithgow

unread,
Jan 29, 2016, 6:38:07 AM1/29/16
to open_ca...@googlegroups.com

Hi Sabu

I have looked at your project once before and think it sounded interesting.

In this forum we are discussing free and open formats, opensource and/or GNU software. What do you have to add to that sphere of work.

Last time I looked I couldn't find the code for TAD. I also can't find anywhere documentation of the file format(s) your software uses.

Please share your knowledge in this context of freedom in formats and software. Not just free as in no-cost but free as in freedom.

Best regards

Duncan

--
Sendt fra min vanilla Android mobil

timofonic timofonic

unread,
Jan 31, 2016, 12:33:46 PM1/31/16
to open_cad_format
Did anyone attend at FOSSDEM?

Are there any hopes to make a meeting between different projects, organize documentation in form of RFC voted process, deal with a final file format,propose a planning and start coding?

I know chatting is funnier than coding ;)
Reply all
Reply to author
Forward
0 new messages