Converting Geometry

A common source of frustration with BRL-CAD is importing and exporting geometry. Objects are converted through BRL-CAD's NMG (polygon) and BoT (triangle) representation formats because we convert file formats such as STL, DXF, and X3D. They are predominantly polygonal file formats. BRL-CAD's support for converting polygonal boundary representations is extensive an unparalleled in the open source realm, but there are several problems. This is an overview of what is being done [1] to address those problems.

[1] http://brlcad.org/wiki/Image:GeometryConversion.png

Without getting into the theory and principles surrounding geometry representation types, solidity guarantees, and the fundamental limitations of using polygonal formats for analytic purposes, polygons are common for visualization so we have to support them (and do so well) regardless of the problems they cause. To that end, a lot of work has been going into BRL-CAD to make things better!

We're hitting up the problems on multiple fronts. The big picture enhancements being worked on involve:

A) avoiding polygons where possible,
B) fixing our existing NMG/BoT support, and
C) changing the method we use for CSG boolean evaluation.

As an example of avoiding polygons (i.e., enhancement "A"), our Pro/E export plugin presently converts their native boundary representation (BREP/NURBS) format to triangles (BoT). That is a big problem. Many years ago, that approach was quick and dirty to implement, solved the immediate problem, but ended up causing all new problems that are very costly for modelers and analysts to deal with.

BRL-CAD developers have spent the past three years implementing BREP/NURBS support for multitudinous benefits. One major gain is so that no change in representation type is needed during import. By avoiding polygons, there is no change to the model's representation, no data explosion, no introduction of pegs that don't fit into their holes. The goal is to import geometry faithfully and preserve data to the extent possible.

The BREP/NURBS work is nearing completion and presently going through an extensive validation, verification, and review process before it's announced as ready for production use. Consequently, supporting NURBS also paves the way for changing how boolean evaluation is performed (i.e., enhancement "C") -- even for good ol' traditional CSG implicit geometry -- and establishes a foundation suitable for implementing modern interactive shaded displays.

Fixing our existing NMG/BoT code (enhancement "B") almost goes without saying given the exporters should just work and be robust. A lot of effort has gone towards establishing a baseline on conversion failures so we may systematically investigate, track, and fix them. While a very complex set of problems (naturally, or they would have been fixed by now), there are several bugs already fixed in the upcoming release and continual improvements that can be expected over the upcoming months.