[freearchitecture] Re: Re: x3d-cad vs. step

[Christopher Sean Morrison]

On May 8, 2006, at 14:44, Lars Grobe wrote:

> Well, the creation of that library is good news. Does the step  
> licensing
> allow other apps to link to that library without paying the license  
> fee for
> the parts of step implemented? I think it is hardly possible to  
> convince
> authors of independent open source tools to pay for their free  
> work, but if
> they could link against a library, this might be the approach to  
> encourage.

As Terry mentioned in his follow-up, STEP does allow other apps to  
link to the library.  The exact license of the library being  
developed is still under consideration but it will be either LGPL,  
BSD, or simply in the public domain.  Once the library is written,  
basically any application will be able to link against it for reading  
STEP files without needing to even care about the STEP standard  
itself; they'll only concern themselves with the documented library  
API so that they may process the geometry as their application requires.

> Another question, as there is a BRL-CAD developer on board - I  
> wonder if it
> was possible to plug-in an application like BRL-CAD into another.  
> The reason
> I ask is that, while BRL-CAD is said to be a very strong solid  
> modeler, it
> has not much in common with other tools an architect is used too.  
> So in my
> opinion one promising way to go would be to use BRL-CAD for solid
> operations, but from another GUI, together with other tools  
> (Blender for
> meshes, Pythoncad for 2d-drawings, Scribus for layout, ...). So it  
> would be
> necessary to use the engines of these applications on a shared  
> model and
> from an more or less independently developed GUI. Is this just a  
> naive idea?

It is entirely possible.  It's actually part of BRL-CAD's fundamental  
design to be extremely modular and reasonably easy to integrate with  
external codes.  BRL-CAD was designed around a UNIX philosophy of  
small contained tools that perform specific operations that can even  
be chained together on a command line.  BRL-CAD in its entirety is a  
suite of more than 400 tools built on top of 16 libraries that are  
all used together as a solid modeling system.  Most look immediately  
at the GUI modeler MGED, which while a production feature-filled  
modeler, was designed for specific purposes.  There are already two  
modelers built on top of the libraries and tools (mged and archer) as  
well as at least a half dozen major external codes that link against  
BRL-CAD's libraries for functionality.  I'm likewise in the process  
of implementing a next-generation graphical interface to our solid  
modeling facilities so no, I don't think it's a naive idea -- it's  
one of our design intents.


On May 8, 2006, at 16:17, Terry Hancock wrote:

> * There IS a fee to download the *official* documentation for STEP,
>    which, AFAIK, is copyrighted, which means that even if I were to  
> pop
>    for said $10,000 (I haven't got that much so this is entirely
>    hypothetical), I still couldn't post the results on the web, which
>    makes them next to useless for a community based project.  So I
>    don't propose that anyone pays the fees for the standards  
> documents.

While you can't post the ISO specifications on the web (i.e.  
unlimited distribution), you are generally able to share them with  
your own project's participants under a limited distribution  
agreement and within fair use considerations.  In BRL-CAD's case, we  
already have all the necessary standards for richer or poorer and can  
share them within our own group as necessary.  While an annoying  
limitation that the standard isn't fully open, that is the nature of  
almost all ISO standards.

One good thing is that you generally don't need the standard itself  
once a reference implementation is provided or the reference itself  
becomes fairly common knowledge (e.g. ISO 9899, ANSI C) and only a  
limited group of people truely need the standards to start with (e.g.  
compiler, library, and book writers).  Once you have software that  
implements the standard (e.g. a C compiler or a STEP library) others  
simply get to benefit through use.  This of course doesn't help  
anyone that doesn't want to work on our STEP library until the  
library is done, but it is at least a start.  Once completed, the  
approach being taken should be relatively fast, robust, cross- 
platform, and easily extended.

> * This last point is what EXFF is doing.  IIRC, they already have  
> an Express
>    parser, but I'm not sure what their complete toolset is.

The Express parser portion is pretty much the easiest part of the  
puzzle.  The original NIST C implementation was effectively a fully  
validating STEP application protocol schema parser, although not  
updated to the latest 10303 (year 2000) ratified version.  Since  
then, the NIST implementation has been revamped and improved; NIST is  
no longer interested in maintaining the library so there's a great  
degree of flexibility in adopting maintenance and upgrade  
modifications.  We're replaced their build system for better cross- 
platform and 64-bit support as well as the mods necessary to support  
the changes since the 1994 spec testing against the latest AP revisions.

> * I've already seen the NIST C implementation, but I think the EXFF  
> parser
>   either already supercedes it, or is meant to.

The EXFF project from what I've seen is very unappealing approach to  
say the least -- converting the STEP schemas to UML gets you no  
closer to writing an importer or exporter and merely adds yet another  
layer of complexity and another transformation layer to something  
already fairly complex.  Personally, I also don't see the "UML is  
better" argument from a basic schema representation perspective  
having written more than my fair share of UML documents, though I do  
admit the comparison is about as useful as a language A vs. language  
B argument.  It is a novel approach, but not one that I see helping  
any CAD/CAM/CAE project any time soon (STEP's primary intended  
market).  At some point, someone will need to write the glue code  
that goes from the STEP representation to an in-memory form and/or  
some other understood format (BRL-CAD's open specification geometry  
file format, for example).  If they can pull it off, or if someone  
else leverages their work as a baseline to actually creating a  
library or converter of some point, more power to them.

> [snip..]  Express schemas into various kinds of representations,  
> including XML,
>    which is the obvious target for a modern free CAD standardization
> project.

Not so obvious for projects that deal with relatively massive and  
complex models on a routine basis (which was a STEP consideration).   
When your compressed binary CAD models are already several gigabytes  
in size (or more), converting to a relatively verbose ascii-based  
format results in considerably more intensive processing and memory  
requirements (couple orders of magnitude).  XML is great for some  
situations and some collaborations, but certainly not for all of them  
-- at least not if you want your geometry to get processed/loaded/ 
imported/whatever sometime this week.  That said, it of course  
doesn't matter nearly as much if it's just an intermediate format  
that is infrequently exchanged or converted.

Cheers!
Sean Morrison
BRL-CAD Open Source