RE: [Algorithms] FW: [CsMain] Scene Graphs (long tangent rant on "standards")

[Graham S. R. <gr...@se...>]

Steve wrote,

> There are dozens of OpenSourced scene graph API's out there.
> Inventor becomes yet another.  There are dozens of file formats
> out there - .iv becomes yet another (and it's essentially just
> VRML anyway - IIRC)

Yes, quite true. I hear you and feel your pain. The same situation exists in
the CAD world. Every solid modeler has its own native file format. CAD
vendors don't want portability because their established customers would
then have a choice, an option to choose a different tool without losing
their past models, their past investment. Competition would become more
price based---prices would have to come down and all hell would break loose.
There is currently no good and robust way to pass parametric models back and
forth among different CAD/modeling systems. The best you can do is to pass
an instantaneous boundary rep model, and even that usually requires a human
expert to resolve inconsistencies.

I haven't had too much good experience with true standards, beyond, say,
HTML. And I'll expand here at length on one of my recent BAD experiences
with standards.

We've just built a STEP translator for our Inventor-based model assembler.
STEP is an international (ISO) standard data schema and file format for the
storage and exchange of product data. And by product data I mean geometry
describing the product, material properties and thicknesses, dependencies,
analysis data (such as finite element models and results), electrical
wiring, etc. It is sort of a replacement for IGES, among many other things.
STEP is huge and after 15 years of development it is still experimental and
incomplete. Pre-alpha.

Our purpose was to support STEP AP 209 (an "application protocol" of STEP
for finite element models and data). We use NASTRAN and ANSYS here, two
finite element packages that have together the largest market share of all
finite element packages. Their file formats are straightforward, even human
readable. The STEP AP 209 file is a nightmare. In theory, it is human
readable---it is text and the entity names appear to be meaningful at first
glance. But there are so many many many different levels of abstraction and
generalized terminology that it is just not possible to read it without
going insane. And that would be OK----since really we would rather that
computers read it----except that someone has to implement the translators
and that means someone has to understand all these levels of abstraction. We
are working with a STEP expert on this. Its their full time job to
understand STEP and write translators and mappings. The STEP expert is
having to consult with other STEP experts to interpret the standard. That
would be OK, except that on numerous occasions *NONE* of the experts are
able to come up with a concrete decision on what the standard actually
intends. Even with our in-house expertise in finite element modeling, there
are unanswered questions about how to model certain things. The
documentation for this thing sucks. There are only a very very few examples
out there. And the examples are *all* trivial ones, while our models are not
trivial.

We wanted to do some testing on our translator, to make sure we could read
STEP files produced by another application and vice versa. That's the
purpose, anyway, isn't it? So we contacted MSC Software to license their
STEP translator for their MSC.Patran product. OK, we send them a purchase
order, all seems well. They're very happy that we will send them money.
We're happy too, until we get the code and try it. We export an AP 209 file
from Patran and none of the AP 209 data is there. Its just NOT THERE. The
documentation states it works, but clearly it does not. For 2 weeks, we
fight with them. Turns out, they have multiple versions of the thing and no
one is certain which one works. We are in contact with two other customers
of MSC who have had similar problems getting working code. Eventually,
somehow, thanks to calling MSC multiple times every day, we're able to get
the "working" version of their translator. The version that supposedly had
been conformance tested by MSC. The files that it exports are actually
wrong, although they do contain the relevant information. They do not
conform to the AP 209 schema. We have to manually modify the file to get it
to conform. And we have to strip some information out, namely curved
geometry data, since that is just completely bad---curves with knots at
infinity, lost associativity, etc. Even MSC's own product cannot read it
back in.

MSC is one of the more active players in the committee that created the AP
209 part of the standard. And yet they cannot seem to produce a compliant AP
209 translator. If they can't get it right, how can we expect AP 209 to
really work?

So, in short, I just don't really believe that truly good standard file
formats can emerge when they are designed by committee. I see more success
in standard API's. The OpenGL approach is something I like. A top-notch
company designs something that is simple, works damn well, and they run with
it, making it available to the world, teaching the world how to use it,
proving that it is good, superior, extending it over time----and building in
an extensions mechanism. De facto standards, I believe, are much better than
true standards, with very few exceptions.

I'll give you another example. Anyone ever heard of PHIGS/PHIGS PLUS?
Probably a good number of you, depending on how long you've been around
doing 3D graphics. How many of you use it? What about you Playstation 2
developers? No? Windows? No? Macintosh? No? Linux? No? And yet...PHIGS and
PHIGS PLUS are ISO standard APIs for 3D graphics.

Graham Rhodes