Here’s a quick poll:  How many of you have figured out by now that 16,777,217 = 2^24+1, and that the "24" refers to the 3 RGB bytes in RGBA32?

An alternate title I considered for this post was "NoColor is a color", which would have been an inside joke for people who go to science fiction conventions.  Considering the audience, I decided to stick with the computer science reference :)

So, what am I talking about?  The fact that, for 24-bit RGB colors, there are actually 2^24+1 possible states, since the absence of color is itself a state.  This in turn causes problems because it’s very difficult to jam 2^24+1 states into 24 bits.  The more subtle problem here is that people often aren’t thinking about the extra state when they write their code, which can lead to "Happy Path" algorithms.  So the question is, "How do we provide an interface to customers that manages the NoColor issue in the best way possible".

Let me give a concrete example.  In our CGM product, we provide the ability to attach "properties" (such as color) to geometric objects – basically we provide SetColor and GetColor methods.  If no color is present, then the object takes on the color of its parent object (or the default color if it is a root object).  The problem we had to deal with was how GetColor should indicate the absence of color.  More precisely, what should the signature of GetRed be, and what should it do when color is absent?

First, the evil answer: int GetRed() returns a “magic (invalid) value” such as -1 when no color is set:

The reason this is evil is that the server (the Color1 class) is intentionally returning an invalid result, and relying on the person writing the client code to remember he needs to check for a special state, then go down a different code branch in that case.  I remember reading somewhere (but can’t find the reference) the "Tiger Trap" principle of interface design: that using the interface correctly should be like a tiger trap – consumers of the interface naturally fall into it.  With this interface choice, the tiger trap is in the direction of using the interface incorrectly.  An insidious variation on this design which might even be worse is to return a valid value for red in the NoColor case.  The reason this might be worse is that an invalid value can be detected by a contract check (in DisplayRedValue() in the example).  A valid (but arbitrary) value is undetectable, and can lead to weird results that are difficult to track down.

Next, the answer from my last post:  create a Nullable<T> template class and have the GetColor query on an object return a Nullable<Color>:



















There are several nice things about this approach:

  • The color class is now responsible for only 2^24 states – the NoColor state is managed by the Nullable class.
  • The Nullable class is designed for exactly this situation, so the approach is intuitive.
  • The tiger trap is now in the correct direction –the compiler won’t let the customer call GetRed() on a Nullable<Color>.

In fact, this is the approach that we use our sample scripting application for CGM – the javascript objects returned by GetColor() wrap a Nullable<Color> object. 

Although the Nullable approach is appropriate in certain circumstances, it still has a drawback: the client still needs to write an if statement when actually getting the RGB values.  This problem is solved by the last approach: pass the RGB values by reference, and don’t change them if the color is unset:










The nice thing about this interface is that it caters to the client’s workflow.  Basically, the client calculates the RGB values that will be used if the color is unset (typically by looking at parent objects and/or the default color).  The client then calls GetRGB – if the color is unset, then the previously calculated colors are left alone, otherwise they’re overridden.  This is the interface that we chose to use for color (and other, similar) properties in our CGM product.

We have found this signature idiom to be really useful in a lot of places.  For example, it’s a natural fit for a chain-of-responsibility pattern:





(Yes, I know I could reduce this to a single line, but I’m conservative about these things J )  I’m sure many of you are already using this one in your code, but for those of you that aren’t, I hope you find it useful as well.

One last thing: if anyone out there knows the correct tiger-trap reference could you please post it in a reply?  I’d really like to track it down for proper attribution.


Contributed by Linda Lokay, VP Marketing and Business Development

It is so exciting to talk with people when they have an experience that lets them finally understand what you do. Today was one of those days. My husband, a musician, had to go to the orthopedist to be fitted for orthotics. His doctor gave him special socks to wear and explained how he was going to record his movement as he walked and ran. He got to see images of his feet in motion and was shown how all of this would be sent through a program to analyze his gait and finally with a press of a button, his orthotics would be made, right there in the same office! 

When my husband came home he was so excited to tell me about this amazing process and how this doctor, who built this system himself, must have something revolutionary. He asked me what seemed like a million questions about how someone could make a sock to gather information and then produce the final product with one click of a button. In fact, he said it reminded him of being able to print, but it was 3D.

For those who are familiar with the technologies, the story is not so surprising. Scans producing point cloud data are sent into specialized analysis programs, files are saved and the results are sent to a 3D printer. To be able to explain how one can go from a set of what seemed to be random points on a screen to produce custom orthotics gave me the perfect opportunity to explain how different components (point clouds, modeling/analysis engines, data exchange, etc) are all brought together by a very creative individual, to be able to create custom solutions for every patient. After many years and too many technical ways of trying to explain what Spatial does, all it took was one very personal experience and he FINALLY got it!

I would love to hear other stories about when or how your friends, family, or associates really grasped what you do.

Do you have a real life 3D Experience?

Jeff Happoldt

By jeff

Year Started with Spatial: 1996
Title: Principal Software Engineer

I discovered my passion for geometric modeling in the late eighties while working on a project at IBM that required the use of a high-end 2D CAD application called CADAM. Although it only lasted a few years, the experience had a significant impact on my career. Directly thereafter I joined a start-up to help develop a commercial application to serve the metal construction industry. I didn’t think much about it at the time, but the product was actually based on ACIS!  From there, fate led my family and me to Boulder Colorado, where my career at Spatial began a few short weeks after the release of ACIS 2.0. Initially my projects varied widely, from developing the installation program used for our products in the 3.x timeframe, to developing the memory manager in the 4.x timeframe, to porting the product to 64 bit architectures in the 5.x timeframe, and of course to my share of bug fixes throughout the years.  My most enduring project however, has been thread-safe ACIS.  This project has become a journey, one that now also includes the responsibility for the multiprocessing infrastructure in CGM. I spend most of my time working on these technologies, which may explain my blog posts.

On a personal note, my wife and children are my pride and joy. I also like hot summer days, Kawasaki motorcycles, and German automobiles.

I recently found a really interesting technical article describing the difference between semantic and visual PMI.

First some background . . .

For the first few years that Spatial 3D InterOp offered PMI, there was one topic that really confused me: semantic PMI.  What did the term semantic mean when applied to dimensioning?  Actually my lack of understanding went deeper than that, what was the big deal about dimensioning and PMI anyway?  (I'm no ME) -- I had to do some catch up to understand what on earth a geomtol was and why it was important.  Prior to then, I thought PMI was just +/- some tolerance on the length of an edge, right?

So I learned that it is more complicated than that and that there wasn't even a standard way of representing PMI.  In fact, not only wasn't there a standard, but there wasn't even a common ideology on the structure.  There have historically been two competing ideologies: semantic and graphical.  Spatial started offering semantic initially to meet the automation needs of our CAM and measurement customers, while graphical PMI was more popular at the time.  In more recent years, these two ideologies are starting to merge together, as we'll show in upcoming releases (sorry for the marketing, hard to talk about this topic without discussing our product line).

So about the article . . .

As Fischer nicely explains, "semantic data captures the meaning" whereas graphical is presented "for human consumption."  In computer science terms, you get a class structure in memory which represents the PMI , providing access to its specifics, such as geometric tolerance type or magnitude through a class method or property - this enables automatic creation of machine paths and test plans.  The article also discusses some of the inherent difficulties with semantic PMI, which we struggle with too, by the way, stemming from the lack of a common standard.  

 An example of this that we've seen is in ProE/Creo, which allows you to put tolerances on driving dimensions.  Driving dimensions are the various dimensions defining the features which ultimately result in the final solid, but they may not necessarily be dimensions that are meaningful to the final solid.  See the example below in which I've created a geomtol between the solid and a construction plane.  Ok, this is a very simple example of a feature, but the significant point is still illustrated: unless you understand the relationship between that plane and the solid (i.e. the feature, i.e. ProE's "secret sauce"), that dimension and geomtol are meaningless.  This is an inherently different style of tolerancing than what is used in either UG/NX or V5, which makes standardizing the data between them difficult.


Anyway, to make a long story short, in my quest to understand a topic that confused me, I found out that there is general confusion and inconsistency on the topic . . . but people are working on it.


Contributed by Paul Cardosi, CFO, Spatial

Are you old enough to remember 1986? If you are reading this blog it has more significance in your life than you realize! In late 1986 three aspiring entrepreneurs flew back to Boulder, CO from New York after pitching their new idea for a 3D software company to an investor.  Once back in Boulder they settled into their routine of coding all day in their ‘office’ above Murphy’s Pub and later heading downstairs for some brews while convincing each other of future success.

The second part of this is routine would soon change!  An investor called and wanted to fund their company which they named Spatial Technology, laying the foundation for the first commercial 3D geometric modeling kernel – ACIS.

In 2011 Spatial celebrated 25 years in business which is a great achievement for a venture-backed software company.  In 2000 Spatial got a new owner (Dassault Systèmes) but many aspects of the startup culture remain at Spatial like cheap soda, bagel Friday and free old-school Pac-man machine (the R&D guys always seem to have the high score). Unfortunately there isn’t a pub downstairs!

For the record I was still at ‘college’ in the UK in 1986 so I have a good excuse for having a vague memory. I think Talking Heads, Space Hoppers and Top Gun were all the rage!

I met one of those 1986 aspiring entrepreneurs recently who told me of Spatial’s UK influence. Three early employees played a key role in Spatial’s ACIS product - a cornerstone to Spatial’s longevity. They were called Alan, Charles and Ian (the ACI in ACIS) who joined Spatial from a UK solid modeling development partner called Three Space, Ltd. They were instrumental in getting Spatial on the right path to success.

I would ask that you join me and raise a virtual glass to say Happy 25th Birthday Spatial!

Twitter Facebook LinkedIn YouTube RSS