solid modeling kernel

How do you design an interface that returns the result of some calculation when 99% of the time the result is simple (for example a single point) and 1% of the time the result is complex (an arbitrary set of points)? How do you signal to the customer that he needs to be careful of the 1% cases? How do you protect the customer from accidentally ignoring these cases, while not forcing him to write cumbersome code? That is the topic of my next few posts.

One of the standard functions in any solid modeling kernel, such as ACIS or CGM, is FindClosestPoint, which, given a test point and a surface finds the closest point on the surface (as pictured below) and returns it – this closest point is sometimes called the projection of the point onto the surface.

A customer who wants to do something with the projection of a particular point might write code like the following: 

- where the declarations labeled “modeler” come from the modeler’s header files.

Looks pretty straightforward, eh? I would ask if you’ve noticed the subtle mistake in the modeler interface, but you’ve probably already glanced at Figure 2 and seen the failure mode:

The failure mode is that, for certain geometric configurations of the input point and the surface, the closest point is not unique. Typically, the failure will be that there are several isolated closest points (rather than just one) on the surface, but I’ve chosen a moderately nasty case for Figure 2 – the test point is at the center of a spherical surface, in which case all the points on the sphere are “closest”.

The root cause of this issue is that the interface designer of FindClosestPoint fell into “The Happy Path Trap” (a name that I just made up). The designer was imagining Figure 1 (the happy path case) when the function was created, and didn’t think of the “what if there’s more than one closest point” case in Figure 2. The typical behavior of FindClosestPoint in the non-happy-path case is to return an arbitrarily selected point from the set of all closest points, as illustrated in Figure 2.

The reason this interface error is so insidious is that it leads to a rare and subtle contract violation: in almost all the cases, the function returns all (one) of the closest points. Only in the rare Figure 2-type cases will this not be true. If it’s important that DoSomething processes all of the closest points, then the customer will have a rare and subtle bug in his application – these are the worst sorts of bugs to protect against and the hardest to track down.

So now we’ve recognized the problem: most of the time the answer is simple (an isolated point), but occasionally the answer will be complex (a general point set). How do we design a better interface that signals to the customer that there’s a subtlety here, so that the customer doesn’t fall into the same trap that we’ve just found?

The wrong answer is to simply document the subtlety. The reason is that this puts the burden of finding (in the docs) and understanding the subtlety on the customer. In isolation, this might not seem like a large burden, but there will be hundreds or thousands of such subtleties in a solid modeler’s interface, and expecting the customer to remember them all is a recipe for bugs. That’s not to say the subtlety shouldn’t be documented; of course it should. We just shouldn’t count on the customer reading and remembering the documentation.

A better thing to do (in addition to documenting the subtlety) is to simply change the name of the function from FindClosestPoint to FindAClosestPoint. In this case, we haven’t changed the behavior at all, but we’ve signaled to the customer, in his source code, that there’s a subtlety. The hope here is that the customer will notice while coding (or, more importantly, cutting and pasting) that the name is a bit funny, which will lead him to read the documentation for the function. In essence, we’ve changed the name of the function to reflect the true contract that it obeys. The problems with this solution are that the customer doesn’t have a simple mechanism for testing whether he’s on the happy path or in the complex case, he’s still in a situation where he can accidentally ignore the subtlety (if he doesn’t notice the funny name), and he has no way of getting the “full” answer. I’ll talk about techniques for solving these problems in my next post. 

Anyone care to guess what I'll propose?

Its blog time and I can’t stop myself from writing about the work Spatial engineers have been doing on Spatial Labs. We’ve presented some of the technology this year at Spatial’s 3D Insiders' Summit here in Colorado and at our European Forum in Frankfurt. Nonetheless, this seems like a good place to discuss our thoughts on where the technology might be going, what we’re looking at next and some of the industry feedback. I actually hope to write several blogs on this topic so let’s start with an introduction here.

As you might know Spatial Labs is our effort to explore the different technologies available to bring classical Solid Modeling technology to a zero deployment (browser based) architecture. This necessitates a definitive client / server architecture where we run the modeling kernel (and we’ve coded against both ACIS and CGM) on the server and the graphical interface (both the GUI and viewport) on a thin client. I can cut to the chase and tell you that Spatial Labs is actually a web site developed and hosted by Spatial (http://web3d.spatial.com). No login is necessary but it does require a plug-in for the graphics (small download / 4.5 m) so we’re not quite zero deployment at this time. (Look for future discussions on html 5 for our attempts to go completely zero deployment). Oh, and you currently need MS I.E. running on version 7. (You wouldn’t believe the work you need to get cross browser compatibility even on simple websites!)

Once you hit the site you’ll see pretty simplistic applications to execute basic Solid Modeling functionality. We have an ACIS application where you can work with three ACIS operators; Remove Face, Blend Edge and Offset Faces. In addition we have the same operators for CGM in an application dedicated to that kernel and two more applications showing Hidden Line Removal and other Spatial R&D work on multi-processing Solid Modeling operations. All applications should be accessible from the main page. I’ll go into more detail in a future blog about some of these apps, especially the multi-processing app.

But, to get into some technical detail in this first blog, we should discuss the graphics. Almost all the first inquires we have on the technical side are in regards to the mechanics of placing the graphics in the browser. Today I realize its only one of several compelling questions. There is so much more to the server side then we initially expected; but it’s a good one to start with.

At a high level we saw two definitive approaches. With the kernel being on the server we had two options; send polygonal/polyline viewing data to the client or stream simple images; almost like video, to the client. The latter goes by the term “screen scraping” although what I have read on the net it might not be precisely the correct use. (You can see AutoDesk Labs; Project Twitch . . . a screen scraping version of Inventor.) Undaunted by the path of AutoDesk; we went with the polygonal approach.

There is a lot to consider when contrasting the two. The polygonal approach struck us as being more open. At the core of the technology is a web service and the interface of the web service is the interface to the Solid Modeling kernel . So one can make very typical functional calls such as loading a model and performing, say a filleting operation. Although right now, just our web pages have access to the web service, the design supports the ability for anybody to interact with the web service; hence writing their own application in some form of a web mashup. The core on the client side is a Javascript library that supports the graphical viewport and accesses the web service. We can easily distribute the Javascript libraries allowing anybody to write their own web pages, basically calling our web service as a utility in an application that they create.

The screen scraping route seems more rigid. Effectively you take an already existing application and stream it, video-wise, over the net; essentially just turning your browser into a T.V. Now, it might be quixotic on my part, but there just doesn’t seem to be anything technically noble about screen scraping. It’s nice if you just want people to use your application as is. But something tells me that there is a grander destiny here, especially when considering how the internet will evolve as web services and mashups continue to become much more ubiquitous.

So, we’re forging ahead waiting to see how the industry breaks. In the next blog I’ll discuss how we use an AJAX pattern for the polyhedral approach and the different technologies we’ve explored in this area.