[freearchitecture] Re: x3d-cad vs. step

[Christopher Sean Morrison]

On May 6, 2006, at 2:58 AM, Terry Hancock wrote:

> [..snip..]
>>
> STEP is a large, modular standard, and it covers a range of use-case
> based engineering domains.
>
> OTOH, STEP is probably "overbuilt", being, as it is, a committee-based
> ISO standards product.

Having dealt with STEP to a considerable extent with the BRL-CAD  
project, let me add that STEP in its entirety is _exceptionally_  
large and complex.  The standard in question is the behemoth ISO  
10303, which if printed in full would fill several long bookshelves  
(I have printed copies of about 6 APs that consume about 10k sheets  
of paper).  STEP is comprised of a series of application protocols  
(AP) which covers the _entire_ process of computer design from  
managerial, to modeling and analyses, to manufacturing, to  
validation, and then some.

When most people talk about writing a STEP importer/exporter or using  
STEP as a data format, they're basically referring to a very limited  
handful of the STEP APs -- usually AP 11 (the Express language), AP  
21 (the file format specification itself), and minimally AP 203  
(basic CAD/solid modeling geometry support).  Some go the extra step  
(no pun intended) and include AP 214 support for extended geometry  
representations (CSG, feature-based edits, etc) and maybe AP 238 for  
machining if CAM is their thing.

The standard is effectively the comprehensive combination of every  
major modeling representation concern with funded backing and  
participation from every major CAD vendor.  It is also a rather  
expensive standard for most small projects to even consider adopting.

Obtaining most of the portions of STEP relevant to solid modeling  
only (about 10 different APs) for BRL-CAD costs several thousand  
dollars to give you an idea.  That said,  this does then allow us to  
share those standards for anyone directly contributing to the BRL-CAD  
project.  That's a small drop in the bucket when your CAD software is  
sold for tens of thousand dollars but without a commercial/government  
body picking up the expense, it's a non-starter for small projects.   
This has been a major factor in limiting adoption of STEP outside of  
major CAD vendors.

> Does X3D-CAD support just geometry, or the whole range of engineering
> data?  STEP has a number of representational features that make
> it useful, not only for specifying geometry, but also tolerances and
> materials, and lots of other stuff.

One of X3D's "problems" is that it's a rather simplistic subset of  
geometry representation that is not much different from IGES, in my  
opinion, other than the W3D backing and XML format.  And IGES failed  
as a unifying solid modeling standard (though it did spawn STEP).   
X3D can represent most of the range of engineering data through  
transformations, but those are not necessarily even topology  
preserving (among other problems) -- which is generally critical for  
most engineering analysis applications.

Representing and _preserving_ geometric data faithfully even through  
transformations is a big problem in the industry; you try to avoid  
them at all costs.  If you don't, you generally pay for it in many  
other ways down the road.  That's been one of many reasons why  
Blender, for example, has effectively zero penetration in the CAD and  
solid modeling markets.  It's like comparing Maya to CATIA.  They're  
not interchangeable for most solid modeling purposes, you wouldn't  
even consider it.

> I imagine that any realistic CAD system, even if it implemented STEP
> would have to concentrate on a *subset* of STEP.  But, is that subset
> equivalent to what X3D-CAD represents?

I would venture to say that even AP 21 and AP 203 represent more than  
X3D in its entirety represents.  Not exactly a fair comparison or  
even a completely truthful statement for every possible consideration  
but a good one nonetheless.  The tradeoff, of course, is that X3D is  
cheap and open whereas STEP is more faithful, robust, complex, and  
expensive.

> I think one of the great weaknesses of a community-developed CAD
> system, is that the developer community doesn't really have a lot
> of experienced industry-based engineers. So, naturally, we don't know
> what experienced engineers want.  We can imagine "toy" CAD  
> application,
> and so that's what we're inclined to create.

Even if you do have a large community of experienced industry  
engineers backing you, that doesn't necessarily make for a CAD system  
that is applicable to everyone.  With BRL-CAD, for example, we have a  
large active community behind it that has been around for over two  
decades but focuses heavily on visualization and engineering analysis  
purposes.  That means, however, that there is considerably less focus  
on other non-analysis CAD issues such as schematics, drafting, and  
machining (among other areas) -- which in turn results in things like  
constraints and dimensioning being left up to the community to  
implement.

> STEP was created by industry input from many, many engineers and
> engineering companies. It therefore represents something close to
> a *complete* set of the things that engineers need to represent. It's
> quite comprehensive.

I would whole-heartedly agree.  From a purely technical  
representation robustness consideration, STEP wins hands down.  Very  
few that know the standard complain about what STEP is capable of  
representing.  They complain about the cost and/or complexity as you  
have to wade through lots of international standards fluff before you  
get to the meat of what matters.  That and you have to have/write an  
Express (AP 11) parser before you can even consider writing out a  
file (AP 21) containing geometry (AP 203, etc).  Not really any  
different than writing an XML parser before considering the DTD/ 
schema, but good XML parsers are more readily available than good  
Express parsers.

For anyone interested, the BRL-CAD project has been in the process of  
creating an open source STEP interchange library (in C with support  
for AP 203 and AP 214 for starters) in conjunction with previous  
efforts from folks at NIST.  It's priority is mainly driven by  
community interest, however, so if nobody contributes then the  
development of that particular feature stagnates as has been the case  
over the past several months.  I'd be glad to share the progress to  
date with anyone interested in picking up or contributing to the  
effort.  I can be reached via e-mail or on IRC in #brlcad on the  
Freenode network as brlcad.

Great discussion, nice to be listening in.

Cheers!
Sean Morrison
BRL-CAD Open Source