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.



>> Sunday, April 15, 2012

The GPU Technology Conference 2012 is being held in San Jose from May 14-17. Given the name, you might expect a broad coverage of GPU technologies, from traditional offerings by AMD and Nvidia to ARM's mobile GPUs and the embedded GPU in Intel's new Ivy Bridge processors. But this is not the case. GTC 2012 is an Nvidia-centric event, and as the schedule makes clear, no GPU manufacturer but Nvidia will be discussed.

This isn't the first time Nvidia has tried to convince people that they're the only game in town. At SC11, many attendees told me they'd never consider OpenCL because they'd heard it was too experimental and not as widely supported as CUDA (the reverse is true). After I gave my talk on OpenCL-OpenGL interoperability, every question from the audience focused on my choice of language: "Why would you use OpenCL instead of CUDA?" and "Don't you know how easy CUDA is to program?" and "Don't you care about performance?"

I hope the audience at the AMD Fusion Developer Summit will be more receptive. My breakout session, "Solid Modeling on the Fusion," will consist of three parts. The first two are theoretical, and present the basics of solid modeling and the mathematics underlying non-uniform rational B-splines (NURBS). In the last part, I'll demonstrate how NURBS can be processed and rendered at high speed using OpenCL, OpenGL, and AMD's heterogeneous processor architecture. I think it will be a great time.



>> Sunday, April 1, 2012

My spare time has fallen precipitously, but I feel compelled to mention a few points:

  • Current versions of Mac OS do support OpenCL 1.1. I'm not certain which OS versions or hardware configurations are compliant, but this link provides a good way to check using clGetDeviceInfo.
  • I received an e-mail saying that floating-point values can be added atomically by using as_int, which tells OpenCL to interpret floating-point values as integers. This is possible, but you have to make sure every value has the same sign and exponent. I think it would be easier to multiply the floating-point values by an integer (say 10000), round the products to integers value, and add them together using atomic_add.
  • I'm still working on a NURBS modeling tool based on OpenGL, OpenCL, and Qt. I'd originally planned to rely on COLLADA for file persistence, but many have recommended the ISO 10303 format, commonly called STEP. Unfortunately, STEP's underlying language (EXPRESS) is based on Pascal, there are few examples of its usage online, and each part of the ISO standard costs about $300. One part of the standard discusses XML formatting, but instead of providing a schema, it explains how to create a schema of your own. Frustrating. I think I'll stick with COLLADA.


  © Blogger template Werd by 2009

Back to TOP