Boundary Representation, COLLADA, and STEP

>> Sunday, April 22, 2012

There are two main methods of forming computer models of three-dimensional figures: mesh representations (meshes) and boundary representations (breps). A mesh is an ordered collection of points in space and its chief advantage is simplicity. Meshes are easy to manage in code and modern GPUs excel at processing vast amounts of mesh data at high speed.

Boundary representations are more complicated. A brep of a figure takes into account its edges and surfaces, and instead of storing every point, it defines the figure's geometry using mathematical relationships. Boundary representation isn't a popular topic but it's vital to the field of computer-aided design. For example, if you use Sketchup to model a house, you don't want to deal with individual points. You want to move edges, extrude faces, insert holes, and manipulate curves. Brep makes these operations possible, and it's also important in computer vision, where computers recognize figures by measuring how light reflects and refracts from their surfaces.

There are plenty of ways to store mesh data, and the OBJ format is one of many free, popular formats. For boundary representation, I've only come across two non-proprietary formats: COLLADA and STEP. I've already discussed how COLLADA stores mesh data, but the latest version of COLLADA can also define a figure using edges, curves, faces, shells, wires, and solids. The COLLADA format is based on XML, and you can download the schema (*.xsd) and specification here. The specification is complex, but it's all regular XML and I found the brep documentation in Chapter 9 to be well-written.

The ISO 10303 standard, commonly referred to as the Standard for the Exchange of Product model data or STEP, is nearly two decades older than COLLADA and has a much broader scope. While COLLADA focuses on digital assets (graphics), the STEP standard is concerned with modeling real-world products. So in addition to boundary representation, a STEP design may include a product's method of manufacture, physical properties, and results of finite element analysis. Because the scope is so broad, you can't download a single STEP specification. Instead, ISO 10303 is split into nearly one hundred parts.

I became interested in STEP because I wanted my modeling tool to be ISO compliant, but I was surprised by how little useful information I could find. Many sources recommend STEP, but no one provides any non-trivial examples. So I opened my wallet and bought Part 28 of the standard, which discusses the XML representation of STEP data. I learned three important points:

  1. Each part of the STEP standard costs between 200 and 300 dollars.
  2. XML is not the primary format for STEP designs. The main language is EXPRESS, which looks like it's based on PASCAL.
  3. There is no STEP schema. That is, you can't download an XSD file that defines how STEP-compliant designs should be formatted.

This last point was the most discouraging. Instead of defining a schema, STEP presents a language that allows you to create your own schema. This is fine for companies like Autodesk, whose software already uses a model for storing product data. But without a hard specification, there's no way to ensure file compatibility. That is, two applications may produce design files based on STEP, but that doesn't mean that they'll be able to read one another's files.

So that's why I'm using COLLADA instead of STEP. I wouldn't mind getting my money back from ANSI, but I guess I'll just chalk it up to experience.


Anonymous,  July 18, 2013 at 12:53 AM  

I agree that ISO 10303 is a complex standard. I do not agree that there are no schemas. Although I do not know the details of every Application Protocol (the one you bought is AP28) but Wikipedia provides some info on this:
The EXPRESS language is defined in Part 11, the storage of these data in a database is described in Part 22 and how to implement this is described in Part 23 for C++, Part 24 for C and Part 27 for java. It is possible to map data from one schema to another using EXPRESS-X (Part 14). The exchange of data is done via ASCII(Part 21) or XML(Part 28). What you bought is a general description on how to exchange data, not an implementation and a specification of a certain data model (all Parts with number in 200 series).
A major disadvantage is that you need to invest quite some money and time to figure out what you need and then buy the parts. There are freeware tools available that can help you modelling and testing.
A huge advantage of EXPRESS over any other format is that it is a generic solution. I am currently working on a tool that will close the gab between the CAD data of a system and the associated information (FMECA, maintenance analysis, etc) so it will be possible to link any documentation directly to the hardware. Both are described in the same language and can be read by any STEP reader. If you want a specific solution for your company you can model it and create using EXPRESS and when you want to switch software vendors you can easily do so. There is no proprietary format.

Rob Shinn September 14, 2013 at 8:30 AM  

Actually, there are a few other non-proprietary formats. IGES is, in turn, decades older than STEP and you can find free copies of its specification if you look hard enough. It's an old and crufty 1970s 80-column fixed-length record format with Hollerith string notation , but like IGES, it's relatively open.

jaredsampson March 9, 2014 at 12:28 PM  

I know this is a fairly old post, but I'd like to ask: Are you still using COLLADA v1.5 in your projects? I really want to use <brep> in a COLLADA exporter that I'm writing, but I'm concerned that the adoption rate of v1.5 isn't what one would hope. For example, Apple's SceneKit only handles v1.4.1, and Blender doesn't support brep in either import or export of COLLADA files. Also, I haven't been able to find many examples using it--is it possible to bind materials and effects to brep surfaces?

Post a Comment

  © Blogger template Werd by 2009

Back to TOP