CodeReps: A better way to communicate geometry

We are constantly looking for better ways to communicate geometry from nTop to other software and manufacturing processes as efficiently and cleanly as possible. George Allen proposes a new interoperability methodology based on our approach to geometry.

Introduction

Transferring data between modeling systems is often a source of frustration in engineering and manufacturing. Exchange formats like STL, 3MF, and STEP are widely supported, but they’re far from ideal. The files are often huge and complex, the data is imprecise, and the transferred models are often called “dumb”, as they don’t support parametric editing.

At nTop, we’ve found a better way, which we call “CodeReps”.

CodeReps provide a way to transfer implicit models between different systems, including models that reference CAD geometry and field data as inputs. As we will see, they have some very nice properties; they are

Small in size
Precise
Portable
Unambiguous
Intelligent

The CodeRep concept is very new, and we’re not yet entirely sure where it will lead. We’re talking about it to initiate a dialog with end users who might find the approach valuable, and with other software companies who are interested in collaborating with us to develop it further.

CodeReps and implicit modeling

To understand CodeReps, we first have to understand implicit modeling — the advanced modeling technology that nTop is built upon. Briefly, the idea is to represent a solid object using an implicit function, typically a signed distance function (SDF). This is a mathematical function F that returns a numerical value at each point P in 3D space, where F(P) < 0 when the point P is inside the object, and F(P) > 0 when P is outside.

A simple example is a spherical solid of radius 3, centered at the origin. The corresponding SDF is given by F(x,y,z) = sqrt(x2 + y2 + z2) - 3.

A more interesting example is a solid block with corners at the points (-1, -4, -9) and (1, 4, 9). A traditional b-rep system would store the 6 faces and 12 edges of the block, along with topological information recording face-edge connections, whereas an implicit modeling system would simply store the SDF given by F(x,y,z)= max(|x|-1, |y|-4, |z|-9) . For more information about implicit modeling, please refer to our modeling whitepaper.

The use of implicit modeling is becoming increasingly common in engineering software. A growing number of systems can work with implicit models defined by general scalar-valued functions. So, it makes sense to look for good ways to transfer implicit models between systems. CodeReps give us a way to do this while avoiding all of the problems that come up during file conversions using the existing formats.

What are CodeReps?

A CodeRep is a text file that represents an implicit function as a sequence of lines of code. Each line of code performs some simple mathematical operation. So, for example, for the function

F(x,y,z) = sqrt(x2 + y2 + 9 z2) - 1

which represents an ellipsoid,

the corresponding CodeRep could be:

Each line of code is a simple assignment statement where the right-hand side includes a single mathematical operation. The operations permitted include:

Arithmetic operations (add, subtract, multiply, divide)
Trigonometric, exponential, and hyperbolic functions
Other common function such as sqrt, abs, min, max, mod
Comparisons (equals, greater than, less than, etc.) and the conditional (ternary)
Referencing geometry, which is interpreted as an SDF
Calls to external functions, such as noise functions
Calls to application-specific functions, such as smoothing or radial basis functions of sampled data

The idea is that a CodeRep can be used to transfer an implicit body from one software system to another:

The CodeReps shown here are expressed in something akin to the C language. This is a temporary choice, and there might well be better alternatives — we’re open to suggestions. All we need, really, is a simple language that can represent mathematical operations and is easy to parse.

In the receiving system

In the receiving system, the CodeRep function will need to be converted into some usable form.

A typical approach would be to convert the CodeRep into a language like Python or C# that can be compiled at run-time into a callable function. By calling this function, the receiving system can determine whether any given point is inside or outside the corresponding solid body, and this provides enough information to support a wide range of applications.

Different systems will support different capabilities, but, at a minimum, it should be fairly straightforward to display the body, compute its mass properties, or slice it with planes, and so on.

What’s so good about CodeReps?

Earlier, we claimed that CodeReps solve many of the problems associated with data exchange based on meshes and b-reps. Let’s dig into the details.

CodeReps are small

For models common to advanced manufacturing, CodeReps are much smaller in size than typical meshes and b-reps, sometimes by a factor of 1000. An example is the heat exchanger (the green part) shown in the following picture:

The sizes of its various representations are as follows:

CodeRep: 880 lines of code, 42 KB
3MF mesh: 3.6 million triangles, 51 MB (1200x larger)
STL mesh: 3.6 million triangles, 178 MB (4200x larger)

Of course, the size ratio will depend on the geometry of the specific part and the required mesh tolerance.

CodeReps are precise

A CodeRep is a precise representation of the original implicit shape, whereas meshes and voxel representations are only fairly crude approximations.

The receiving system might use the CodeRep to construct an approximation, like a mesh, that’s more readily usable in downstream operations. Approximations like this are useful, but they should be done as late as possible, at a point where the intended use is well understood, and tolerances can be chosen appropriately.

If the approximation is performed too early, in the sending system, then some fixed tolerance is “baked” into the mesh, making it unsuitable for some applications. Better to send a CodeRep, and let the receiving system use it to generate whatever approximations it needs, whenever it needs them. Specifically, coarse or fine meshes can be generated, as needed.

CodeReps are portable

The statements in a CodeRep are very simple, and easy to execute in any reasonable computing environment. In nTop, CodeReps are often executed on the GPU, for example. Various high-performance computing (HPC) or cloud computing architectures could also be used. An intriguing possibility is executing CodeReps on a printer. This seems quite feasible, and the printer could take advantage of the precise geometric information to fine-tune the manufacturing process. For example, optical feedback could locally modulate model offsets to calibrate surface tolerances.

CodeReps are unambiguous

In the past, there have been several attempts to transfer feature-based models between CAx systems, but these have not met with much success. One problem is that feature definitions are sometimes ambiguous. For example, two systems might both have fillet or shell features, but the precise semantics of these features are usually not rigorously specified. So, performing a fillet or shelling operation in two different systems might give quite different results. On the other hand, a CodeRep is lower level, so its semantics are 100% clear: every system will interpret a subtraction or a square root operation in exactly the same way, so executing a CodeRep will produce the same result on any system.

CodeReps are intelligent

In some cases, the receiving system will be able to store a CodeRep and use it to perform intelligent parametric editing. A user interface can be provided that allows the user to modify certain numbers in the CodeRep, which will change the associated shape.

This is in sharp contrast to data exchange techniques used in the past. Data transfers that use meshes or b-reps always produce a “dumb” body in the receiving system, which is very difficult to edit efficiently. Not only do CodeReps contain the entire recipe, as well as relationships and design intent, making parametric edits possible, but also geometry and field data such as CAD models and simulation results can serve as inputs.

Beyond closed-form implicits

In the discussion so far, we have focused on bodies having a closed-form implicit equation that can be written as a sequence of mathematical operations. Of course, not all bodies are this simple.

In fact, CodeReps can work with any kind of geometry, because every geometric object has an SDF. For complex objects like meshes and b-reps, there will be no closed-form formula for the SDF, but its value can still be computed at any point (x,y,z) in 3D space. We envision that a receiving system could provide an SDF, and this function would be called from the CodeRep. Distance functions are well-defined and unambiguous, so different implementations can be checked for correctness.

Another interesting point is that if your functions receive geometry as inputs, as opposed to scalars and vectors, you can swap out the input geometry, applying the CodeRep to a different shape. For example, one could create a workflow to hollow a B-rep and fill it with a lattice, in which case the inputs might be the body to shell, the faces to remove when shelling, the shell thickness, and lattice parameters. Even the thickness could be specified using spatially varying simulation results rather than a constant value.

Some interoperability prototypes

The CodeRep concept is very new, and we’re still figuring out the details, but we have done some work to test out the idea. Below, we describe some prototype implementations that use CodeReps to achieve data interoperability between nTop and three other systems.

Interoperability with NX

In the example shown below, a CodeRep has been stored as a Custom Feature in the Siemens NX CAx system. When the feature is replayed, the CodeRep function is used to construct an NX “convergent” body, which is a solid body whose faces are triangle meshes. Convergent bodies can be used in many downstream operations in NX. A dialog is provided that allows the user to change some of the driving parameters in the CodeRep. This causes the convergent body to be recomputed with a modified shape. For example, in the picture below, the user has changed a parameter that controls the wall thickness of the model:

Interoperability with the Zea Viewer

The image below shows interoperability between nTop and a viewer based on the Zea rendering engine.

The Zea engine has an open architecture that allows you to add new data types to its scenes, which you are then responsible for rendering. We added CodeReps as a new data type, and we render by executing the CodeRep as GLSL in a suitable shader. As you can see in the top right, certain variables in the CodeRep are identified as driving parameters, and these are exposed in the user interface. This might seem similar to the NX integration, but there is an important difference: here, we are rendering the CodeRep directly, without producing a mesh, and this delivers far better performance. In fact, in the model shown above, the shape of the heat exchanger is modified in real time as the user moves the sliders.

Interoperability with Intact.Simulation

The image below shows the results of a thermal analysis performed using the Intact.Simulation software and the MFEM solver.

The Intact.Simulation software is remarkable because it can use any type of geometry as input. Rather than reading the input geometry directly, it relies on a small number of geometric queries to obtain information. The most basic of these is the point membership query, which asks whether a given point is inside or outside a solid object. Of course, this is exactly the information a CodeRep provides. Using the results of the queries, Intact.Simulation prepares input for various finite-element solvers, such as Nastran. Interestingly, Intact interfaces with solvers without constructing a traditional finite element mesh.

Summary

As we have seen, CodeReps are

Small -- sometimes 1/1000th the size of a typical mesh
Precise -- not an approximation, like meshes or voxels
Portable -- can run on HPC, cloud, GPU, or even printer
Unambiguous -- just simple math, whose meaning is 100% clear
Intelligent -- supporting parametric editing; not just “dumb solids”

We don’t expect meshes and b-reps to disappear anytime soon, so nTop fully supports import and export of STL, 3MF, STEP, and several other data types, and will continue to do so. But, as we have seen, these formats all have flaws, and CodeReps are both fully compatible with them as well as providing a better alternative in certain situations.

But a data exchange mechanism is only valuable to the user community if it is widely supported, so we’d like to know what other people think of the CodeRep idea. If you have questions, or you’re interested in contributing, we’d love to talk.

If you're interested in learning more or inquiring about a partnership, please contact us.

Introduction

CodeReps and implicit modeling