Wednesday, January 23, 2013

The Geometry Kernel and What it Means to Product Development

There certainly has been much talk about the CAD geometry kernel in the last few years. Much of this talk comes from the rumors around Dassault Systems changing the SolidWorks kernel. I think it is clear now that Dassault has no plans to change the SolidWorks kernel, but rather is developing a new product on the Dassault kernel.

So what's the big deal about the geometry kernel anyway? Why do we even care about what kernel is under the covers of our favorite CAD tool? Should we care about it? Do you know how the geometry kernel can impact your ability to be effective in the design of your products? Strangely, the answer to these questions depends on many factors.


I know I am going to over simplify this, but here it goes anyway. In its purest form the CAD kernel is a geometry engine. It takes instructions, processes the instructions, and delivers results. The results are typically in the form of geometry. Every geometry kernel on the market can be unique in many different ways.


  • The instructions or "functions" that the kernel will accept are very specific to the kernel. Also each function has a specific set of operatives or parameters that go with it. These of course have to be presented to the kernel in the appropriate format. There are no standards for kernel functions/instructions.
  • Kernels can also define geometry in many different forms. Some kernels understand analytic geometry, some understand B-Splines, some understand NURBS, and so on. Some might understand all of the previous and know how to merge the different definitions. There are no standards as to how kernels mix and match these definitions.
  • Geometry kernels can also work at different geometry resolutions (accuracy). Some kernels are more stable at very low resolution, while others work more effective at a higher resolution. Most kernels provide adjustable geometry resolution and the CAD system typically controls this, either through a setting or automatically. There is no standard geometry resolution for CAD geometry.
  • Geometry kernels can also calculate the geometric results differently. Perhaps the easiest way to see this is with the corner "Round" or "Blend" function. Every kernel out there will calculate the vertex region differently - and it is very visible. There are no standards as to how a kernel calculates this type of geometry. Here are some examples from some of the more popular CAD tools on the market. Pay close attention to the differences in topology in these examples. Also note in these examples how the planar faces are effected differently. I can usually tell which CAD system was used to create a 3D model just by looking at the rounded corners. There are no standards for these types of calculations.

same geometry with same radius in all 4 cases
all blends done in one function/feature

Those are some of the big differences. There are many more, especially in the area of freeform surface definition.

So, again, what does all this kernel stuff mean to the product development process?

When we are working with CAD we are typically creating two layers of information. The TOP layer is the feature definition including any import or non-ordered geometry, sketches, parameters and other modeling functions. This is the history tree, or some may call it the "design intent". On the BOTTOM layer is the resulting geometry. (Of course with direct modeling all you have is the bottom layer.) When moving CAD data from one kernel to another, both layers need to be considered.

Let’s consider the TOP layer first; it is actually the most complex. (And for you direct modeling people you don't need to be concerned with this layer. You can skip to the BOTTOM layer covered below). A parametric history-based CAD system is basically recording every function it sends to the kernel into the history tree. These kernel functions and their parameters are bundled into the "parametric feature" definition. For example; a sketch with an extrusion distance creates a primitive. Constraints control the size and position of the new primitive. Then a Boolean function is added to specify whether the primitive will be added or removed from the parent geometry. The Boolean function with the primitive and related parameters are passed to the kernel and the resulting geometry is processed and revealed. This kernel function is processed every time this "feature" is regenerated or reprocessed. The kernel function along with its required parameters is very specific to the kernel as discussed above. It is highly likely that another kernel will not understand this very specific function, and even if it did the geometrical results could be very different.

Moving this TOP layer from one kernel to another kernel is very much like taking a FORTRAN program and trying to compile it with a C compiler. It won't work. The functions and related parameters are just not compatible. As such these functions that are recorded in the history tree have to be translated to work on a different kernel. The CAD industry has made several attempts to make translators that will translate this TOP layer from one kernel to another - but we have had very limited success. By the way, this is also one of the reasons for slow progress on geometry kernels - we are too locked into this TOP layer. If we make too many changes to the kernel we may impact upward 
compatibility with previous version "history trees", i.e. “kernel functions”. There have been many examples of this problem over the history of CAD.

Moving the TOP layer from kernel to kernel may provide the highest risk to product development. This translation has to work perfect otherwise history/design intent can be lost. By the way, if you do get a complete and robust translation of this TOP layer from one kernel format to another, you don't need to be concerned with the BOTTOM layer. The geometry will be recreated for you when the translated TOP layer is processed by the receiving kernel.

Now let’s consider the BOTTOM layer, i.e. the geometry (and for you parametric modeling users that were able to get an accurate translation of the TOP layer, you can skip this section - unless your TOP layer has a lot of import or non-ordered geometry features in it). As I mentioned earlier, geometry kernels can create geometry in a variety of different forms and at a variety of different resolutions (accuracy). Although we have industry exchange standards for geometry (IGES, STEP), as mentioned above we don't have standards for geometry accuracy or definition. Translation of geometry from one kernel to another is not flawless. You most likely have experienced this imperfection if you have ever translated geometry through the STEP or IGES formats.

If you have experienced errors or gaps in translated geometry it could be a result of, for example, translating an analytic surface to a NURBS surface, or vice-versa. Or it could be a geometry accuracy problem. In some cases the translation issues may be related to the IGES or STEP processors within the CAD tool, but it’s also possible that the issues are due to big differences in the sending and receiving geometry kernels. We all likely know how poor geometry translations can impact the product development process. When moving CAD geometry from one kernel to another, you can expect some of this. Fortunately most modern CAD systems have tools to quickly resolve these geometry imperfections - don't they?

So how might a kernel change impact your product development process? Well, it depends. Will you be transferring the TOP layer or the BOTTOM layer with the kernel change? I hope you can begin to see the pro's and con's of each.Here are few final questions to ponder:
  • What do you think happens if you use one geometry kernel for concept design, and another for detail design? Can you "round trip" without loosing data or degenerating the model?
  • How robust is your TOP layer? Do you maintain strict modeling standards?
  • What geometry accuracy does your geometry kernel run at? Does it make high quality geometry that other kernels can consume without error?
  • Are your drawings associated to the TOP layer or the BOTTOM layer?
  • How is "model-based" impacted when multiple geometry kernels are used in the product development process?
  • What downstream functions are driven by the TOP layer versus the BOTTOM layer?
Paul

11 comments:

Dmitry Ushakov said...

Thank you for this post, Paul!
Very informative.
We translated it to Russian for our readers:
http://isicad.ru/ru/articles.php?article_num=15874

But what do you think about TOP layer in non-history-based CAD systems? Features and constraints can be defined declaratively - with no associative procedures for geometry generation.

Paul Hamilton said...

Hello Dmitry,

Thanks for the re-post.

I know I have oversimplified this by putting everything into two layers: TOP and BOTTOM. With my 2 layer distinction in mind, I simply put the “recipe”; the sequences used to create the 3D model, in the TOP layer and all results in the BOTTOM. As such what you refer to would go in my BOTTOM layer. We should certainly take a more detailed look at what is happening in this BOTTOM layer. It is getting more and more complex - perhaps with many different layers in itself.

The industry really does need to have some in-depth and open discussions about the types of information we are now embedding into our 3D geometry (the BOTTOM layer). This can include Feature Definitions (UDF’s), PMI, Constraints, and MANY other types of attributes. Will any of this type of information be exchangeable between systems? I know some of it is, but what about things like 3D constraints? Will constraint attributes be compatible between solvers? If so, will the results of a geometry change driven by one of these 3D constraints be consistent across kernels? And many more questions. If we are not careful we will add more complexity to interoperability rather than reduce complexity.

Paul

Dmitry Ushakov said...

I took part in development of two different constraint solvers - LGS by Ledas (now by Bricsys) and CDS by Spatial - and I know that the semantics of constraints in each solver is similar (it can be standardized), but the full compatibility between two solvers can be achieved only on very basic scenario. A more or less complex constraint problem will be solved differently - because of different algorithms coded inside each solver (geometry decomposition, generation of system of non-linear equaltions, equation solving).

However, I don't see a big problem here, because constraints are not used to generate geometry - in contrast to history tree. Constraints are only used when the geometry is modified. But once it was modified in one CAD, the constraints are all satisfied - and after the translation to a different CAD system the constraints will remain satisfied (if two systems have compatible constraint specifications). So geometry won't be changed in translation.

The same is true for declarative features - if we consider them not as procedures to generate geometry, but as collections of B-Rep faces and 3D constraints linking them.

Paul Hamilton said...

Dmitry, I like your thoughts on this. As we are not transferring the procedures to generate geometry (in my so-called BOTTOM layer) there is no chance that geometry would be changed in the translation. Very good.

Mark Stapleton said...

Thanks very much for the informative article.
I'm wondering if some CAD packages of specific types are able to increase their specified geometry accuracy on the fly? I note that I very often get invalid faces and gaps in geometry when importing neutral format files from these packages (which obviously are built on different kernels than my CAD of choice), and it would be great if I could just ask the original modeler to increase the accuracy as a means to providing a more complete result.

Paul Hamilton said...

Mark,
That could be a complete topic on its own - great question. Yes - almost all parametric history-based CAD tools come “out-of-the-box” with Geometry Resolution/Accuracy set to “automatic”. In other words as the model becomes more complex the CAD system automatically reduces the accuracy of the resulting 3D geometry. CAD vendors do this to try and keep performance at an optimal level as the geometry increases in complexity. Most people will probably appreciate the better performance, but it comes at a cost that most people don’t realize or understand. If you are on the receiving end of this data – you do!!

At one of the companies I worked at (many years ago) we actually set a geometry resolution/accuracy standard. We didn't care what CAD system our partners and suppliers used, but we were very clear with what geometry resolution they had to deliver to us – after all we paid for it. Unfortunately for some, they had to change CAD tools to comply as their tool of choice would not deliver the geometry at the required accuracy. (I won’t tell you what CAD systems those were, ). Once geometry is generated it is very difficult to increase the resolution, but with history-based CAD you can change the resolution of the CAD system and then regenerate the model – resulting in higher resolution geometry.

Most all CAD tools will allow you to set the resolution to an “absolute” resolution. You can request this of those that are generating geometry for you. It will cost them though. The higher they go, the slower the performance - usually. Also some “parametric features” may fail to regenerate as the kernel that is being used to generate the geometry simply can’t handle it.

If you are paying for geometry, you really should define a geometry resolution standard.
OR - If your customer is delivering to you geometry that you work from, perhaps you could offer a price incentive for higher quality geometry.

Jon Banquer said...

Mark,

"I note that I very often get invalid faces and gaps in geometry when importing neutral format files from these packages (which obviously are built on different kernels than my CAD of choice), and it would be great if I could just ask the original modeler to increase the accuracy as a means to providing a more complete result."

Have the problem you describe on a weekly basis. I think the most realistic solution to the problem is the types of automatic healing tools that my current CAD direct modeler of choice has. I must really like Paul and Dmitry or I'd mention that CAD product and also plug a certain LinkedIn group. :>)

Jon Banquer

Mark Stapleton said...

Wow!
Very interesting thread, and illuminating answers from everyone. MUCH appreciated. And Jon thanks for linking to this thread from the LinkedIn CAD/CAM Technology Leaders forum.

Paul Hamilton said...

I too use a CAD tool that is very good at auto healing geometry :-). Many CAD tools can do this, and as you state; it may be “the most realist solution”. But to be clear, these healing functions do not increase the resolution of the geometry; they only extend and trim geometry in an attempt to close gaps. They may also fix things like curve normals and so on. Many times these “healers” will actually further reduce the resolution of the geometry to try and “heal” it. You will never end up with higher resolution geometry.

Back to the kernel topic. Did you know that a typical B-Rep geometry kernel cannot perform Booleans (unite, subtract, intersect, …) on a group of objects (3D models/primitives) that have different geometry resolution? All objects in the Boolean have to have the some resolution. And since you most likely cannot increase the resolution of existing geometry, all objects are lowered to match the lowest. Through the lifecycle of the 3D model geometry, the trend in geometry resolution will always be in the wrong direction.

But who really cares? Right? It’s solid and looks good on the screen. Perhaps my next article: “Geometry Resolution and Why You Should Care” :-)

Vada said...

This is cool!

Maarten said...

Amazingly clear discussion; very informative!
Thank you all - especially Paul !
I feel like I have a better understanding of kernel problems - as well as a little insight in accuracy-problems, since I'm not used to changing a lot in them (only before I export to STEP-files ;) )