eBook - Top Ten Reasons to Embrace Spatial Components
Free eBook - How to Successfully Develop, Deploy & Support 3D Applications

Receive Posts by Email

Enter your email address:

Subtleties of B-rep Translation (Part 1); Why Sharing Matters

In my last post, I introduced our idea of B-rep Health and the notion of "legal" but bad B-rep modeling data. Literally, the day after publishing that post, a beautiful, classic case came into development where a "remove face" operation failed due to unhealthy B-rep data. And again, as we see so many times, the culprit was bad translation (unknown third party translator). It’s a nice example. But it’s not that the pathology can be described so conceptually (it can - you will see), more, it shows the subtle, implicit information that is maintained inside a B-rep data structure; information you might not know is used. And lastly, it shows why the fundamentals of B-rep data translation are so important.  

So consider a modeling scenario like this; start with a basic shape that we call a wiggle. It’s a block with a free-form (b-spline) as the top face (picture 1). Fillet one of the edges along the top, creating a filleting surface as shown (picture 2). Now build some form of a feature that cuts the filleting surface in two. Here we simply build a notch in the body (picture 3).


Now translate the part to IGES and import it into a different modeling kernel, like ACIS or CGM. From here, it’s not uncommon that one would "defeature" the part, perhaps for a CAM operation. This involves taking the notch and removing it. This should produce the original wiggle with the filleted edge.  Of course, I wouldn’t be writing this blog if something didn’t go wrong. One would expect for this to always work. Well, there can be trouble; but first, let’s take a quick look at how the remove algorithm works.

The remove algorithm is simple; you unhook and delete the input faces (the faces which are to be removed). You extend the neighboring faces (called the moat ring) intersecting them with each other and using the curves generated from the surface / surface intersections to heal the gap and build the needed edges. So in this case, we will intersect (and possibly extend) surface A and surface B shown below.


Now, we are at the key point of the analysis. Surface A and surface B are the exact same surface. It’s ill-fated to try and intersect a surface with itself (this should be self-evident). Before translation – in the original B-rep - the face presiding over surface A and the face presiding over surface B are different, but  they both point to the exact same geometric surface underneath. This is called "sharing". Now if shared, the remove algorithm knows they are the same and doesn’t do the ill-fated intersection. Everything is taken into account and the remove operation works with the original B-rep. Ok, but what happened during translation? And here is where good translation matters. Let’s now look at how this model got translated.

If you have weak translation; you might do something like this. (And this, I believe, is the scenario behind this bug.)  The translator had some method of processing faces (and this could have been done when writing to IGES) that went face by face writing out each face and the surface underneath it. If two different faces pointed to the same surface, it didn’t care. It just processed the surfaces as if they were unique. Basically, the translator didn’t bother to share. Now the future remove operation "thinks" they’re different surfaces and this causes the intersectors endless grief. I suppose you could go back to unsaid company and tell them this is bad, please fix it. Perhaps they will tell you they get sharing correct in some cases but not all (after all sharing is not a complex topic, it’s a concept that was built into even the first B-Rep technologies). But for them it’s simply a performance benefit to reduce size and processing time. The model’s OK without it. Maybe they will get to fixing it, maybe they won’t. After all, even if you don’t have precise sharing, the model got translated and passes any industrial checker. But performance and checking!? That’s not the point. If you’re modeling, it’s an entirely different story. Modeling operations will not work, as you are removing key information from the B-rep that these operations need. [1]

Ok, so maybe this turned out to be a rant; and having a rather intense, five-year-old son, I can’t believe I have to come to work and talk about "sharing". But these things matter, along with so many other fundamental principles that need to be taken into account during translation (future blogs).  I’ve learned that working in a company that has both a modeling product and a translation product greatly helps with the insight (and motivation) you need to get translation right. As I said in my last post, choose your translation solution wisely.



[1] I should follow up by saying, in ACIS we could add a check to always see if two surfaces are the same prior to intersection (comparing data definition, i.e. knot vectors, control points, etc). But the next billion surface / surface intersections will not have identical surfaces and you now introduced an unneeded check that always has to be done. We don’t want to go there!



Interesting article, but one bit caught my eye as a bit hypocritical...you seem to be arguing that it's unacceptable for the unsaid translation company to generate separate surfaces instead of using sharing (for performance reasons), but it's OK for ACIS to avoid an equality check which could also have avoided the problem (for performance reasons).

Ian, thanks for the comment. I would say hypocritical might be a bit strong, but yes; I agree, your point holds and illustrates the quandary the modeler gets left in. As I said, we could introduce the check, but for all our modeling customers that purchased quality translation products, they get unfairly taxed on performance. In short, we have many technical / business pressures pulling on us in many different directions and these all interplay in how development gets executed.

Again, thanks for the comment as I had no idea if anybody out there in the world had interest in such things (blogger's insecurity). I go home and tell my wife these stories and she just stares at me.

Ian, I think I missed your point. I wasn't saying that translators skip sharing for performance reasons. I was trying to state (maybe not clearly) that they saw sharing as a means for performance but nothing else. To the modeler, sharing is more than performance; its design intent.

I think for the translator sharing would be a good for their performance. But as software development goes, you work tend to work on "getting it working"
first and performance second.

Ah, OK, that makes more sense - I thought you were trying to say that the translator was skipping equality checks because those checks are expensive.

I'm still a bit unsure about how expensive it would actually be to do an equality check - doesn't ACIS do this every time a Boolean operation is performed? For instance, if I try to take the union of two solid objects with overlapping faces, that would work just fine in ACIS, so in that case it must be doing an equality check on the overlapping faces instead of trying to intersect them.

See comments

Request an evaluationREQUEST AN EVALUATION

Download technical whitepapersDOWNLOAD TECHNICAL WHITEPAPERS

Read the Spatial Blend newsletterREAD SPATIAL BLEND NEWSLETTER

Watch technical webinarsWATCH TECHNICAL WEBINARS

Featured Video

Featured Video

Learn more about Spatial's products and services.

Click thumbnail to watch video


Build IT

eBooks & Whitepapers

eBooks & Whitepapers

Download technical eBooks and whitepapers on topics including industry challenges and product solutions.

Spatial Facebook Spatial Twitter Spatial LinkedIn Spatial YouTube Spatial Blog RSS


A quarterly e-Newsletter highlighting industry trends, and includes articles from Spatial developers. Sign up to receive The Spatial Blend.