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!

Answer: when it’s a 'HappyPathPoint'.

Happy New Year everyone! I left off my last post with a dilemma: I wanted to design the interface for a function that people will call when they want to find the closest point on a surface to a test point. The problem is that the answer to this question is only usually a single, isolated point. Every now and then the answer is a set of (more than one) points. For example, all the points on a spherical surface are 'closest' to its center. So how does one design the interface so that the person writing the client code naturally accounts for this subtlety, while not forcing him to deal with an awkward interface?

I already stated that the wrong thing to do is to simply document the subtlety and hope the customer will notice it. A better solution is to (in addition to documentation) make the name of the function reflect the subtlety: prefer 'FindAClosestPoint' over 'FindClosestPoint'. The problem with this idea is that it doesn’t actually deal with the problem – how is the customer to tell if he’s on the happy path, or has run into the complex condition? And again, it relies on the customer noticing that something is up (rather than having the compiler tell him).

My preferred solution (which we first thought of while working on an ACIS project to make our internal interfaces more robust) is to introduce a new object called a 'HappyPathPoint'; the idea is that the function returns this object rather than a raw point:

As you can see, HappyPathPoint encapsulates both possible answers: if IsPoint() returns true, then the answer is (the typical case of) an isolated point and it’s safe for the customer to use the Value() method to get the point. If IsPoint() returns false, however, then the answer is (the extremely rare case of) a more general point set, and the customer should use a different branch in his analysis code:

In reality, the customer’s initial implementation for the branch where IsPoint() returns false will simply be to throw an error (and put a project in the backlog to think about what his algorithm should do). This is still a big improvement over the case where the customer’s code ignores the subtlety – what was previously a subtlety is now simply an extra question about the answer, and the code for dealing with the atypical case is isolated at the point where that case is first introduced.

One interesting question in all this is "What should the behavior of Value() be if it is called before IsPoint() has been called?" I see three possibilities:

A) Silently return an arbitrary point in the point set B) In release builds, return an arbitrary point. When contract checks are on, throw. C) Always throw

My preferred answer is B, especially if it is used in conjunction with a code coverage tool that ensures that you test suite will always hit the (invalid) call to Value() (with contract checks turned on, of course). The reason that this works is that the question I asked was NOT "What should the behavior of Value() be if it is called when IsPoint() is false?" That case will only show up in the atypical situations, and so typically won’t be hit in customer testing. The contract is that the customer must validate that the HappyPathPoint truly represents an isolated point before calling Value(), even if the HappyPathPoint happens to be an isolated point. This ensures that the client code is correctly written, even if none of its test cases hit the atypical case.

For those of you who speak C#, you should see similarities with the 'nullable' class that allows one to wrap a value class up into something that can be tested against null. As with nullable, the compiler will warn you if you try to use a HappyPathPoint where a Point is expected. HappyPathPoint is more powerful than nullable, however: nullable doesn’t protect (as a contract check) against an untested call to Value(), and it doesn’t provide an alternative answer.

I hope that I’ve convinced at least someone out there that this is a good idea. I don’t think it’s overly burdensome, and it makes the subtlety obvious in the interface. It is important not to adopt this idea as a one-off, however – if you’re going to use it, it should be implemented uniformly across your interface. The code snippets above are just an example; an interesting thing to try might be to write a HappyPath template class.

The last thing I want to say is that we’ve been thinking about this idea for years, and still don’t have a good name!! Any ideas for a better one? 'PointCandidate' maybe?


Twitter Facebook LinkedIn YouTube RSS