Academic Facets: News and Views from Spatial's University Community

[#1]

Long ago when the B-rep architecture was invented (by Braid and Baumgart) it was universally agreed to be a “good thing” that the representation incorporated a strict separation between topology and geometry. The idea being that by having FACE objects independent of their geometry one could easily extend the geometry (e.g. add new surfaces types) with the addition of only a relatively small amount of new code. This principle is clearly implemented in the ACIS architecture where topologically entities (e.g. FACEs, EDGEs, SHELLs etc) refer to geometric entities (e.g. PLANEs, SPHEREs, SPLINEs) but never assume any particular underlying shape.

I have always accepted this orthodoxy unquestioningly until last week when I spent an interesting day at Bath University talking about the annotation (i.e. “mark-up”) of CAD data and wondered (on the way home) if the classic B-rep rules needed to be relaxed to support this sort of application.

The Bath researchers envisage many layers of data attached to 3D CAD models (any type not specifically an ACIS B-rep) ranging from “traditional” feature data for machining and FEA boundary conditions to arbitrary bits of global “design for X” rational (that are harder to associate with individual entities in the model). An example of such generic mark-up would be adding an XML annotation (i.e. string) to make the functional reason for the draft angle on a casting explicit.

 Like lots of machine intelligence problems this is simultaneously elegantly simple and mind boggling complex! Simple because its analogous to the established engineering practice of marking up drawings with non-geometric notes (e.g. “Remove all sharp edges”);  but mind boggling complex because lurking behind the concept are all the issues of semantics and maintenance associated with any feature based CAD.

The Bath researchers are focused on the semantic issues (inspired by Semantic Web ideas), but to be truly useful any annotations (whether it’s a dimensioning scheme, machining features or a constraint system)  must be robustly exported to different systems and respond appropriately to changes in an object’s shape. 

There are two main obstacles to doing this: first there is not always a one to one mapping between the properties you want to label and the entities of a B-rep; Second is the persistent naming problem (PNP), see 2002 survey by David Marcheix Guy Pierra
 

The PNP problem appears in lots of different context but in a nutshell it is this “when shapes change how you do correctly transfer entity attributes to the new topology?”

 

Figure From survey by David Marcheix Guy Pierra

For example in Figure 1 a C shaped block has a slot feature (2) and blend feature (3) added. If the dimensions of the slot feature are changed/re-evaluated the slot can break the edge supporting the blend into two segments.  Creating the question  should one, or both, of the new edges be blended?

 From very early days ACIS has had functionality (through its attribute mechanism and non-manifold cellular modelling) that have supported various schemes for representing and maintaining such “feature” data as a model’s shape was edited. See for example Bidarra’s system that represented features as non-manifold, cellular  volumes.

So for the ACIS modeller,  the problems of splitting EDGEs that support ATTRIBUTEs has never been a big deal, but there are other examples where the solution is less clear. For example if chamfers or blends where added to the EDGEs of F1 below it would take a lot more thought to decide what the user would “intuitively” expect to happen when the slot is re-orientated.

 Figure From survey by David Marcheix Guy Pierra

It was while I was looking at pictures like these that I wondered has anyone tried attaching the ATTRIBUTES to the SURFACE rather than the FACEs?

The obvious problem is that although SURFACE objects can support the addition of ATTRIBUTEs (because they are derived from the ENTITY class), the split/merge notification methods have no default meaning for them.

However geometric entities like SURFACEs and CURVEs hold explicit reference to the topological entities associated with them (through the “get_owners” member function). In other words given a SURFACE entity one could access a list of the FACEs on that surface and likewise curves (ie. given a CURVE object one could find all the EDGEs on it).

So could one implement meaningful “split” and “merge” notification methods for updating ATTRIBUTEs associated with SURFACEs and CURVEs on the basis of changes to their owners? What I mean is that while a SURFACE entity itself will never split, or merge, the FACEs “on” it could.

Would allowing a SURFACE to hold, and manage, certain types of feature, or constraint, ATTRIBUTEs be a more elegant solution than assigning them to individual FACEs?  

I don’t for a moment think that attributes on geometric entities (which have notifiers invoked by changes in the topology they support) would resolve all persistent naming problems but my speculation is that they would be useful tools for applications wrestling with these issues.

So has anyone implement SURFACE or CURVE ATTRIBUTE classes with interesting notifiers? I’d be interested to hear……………..or is this a dumb idea, and if so why?

Links

2002 PNP survey by David Marcheix Guy Pierra   http://www.lisi.ensma.fr/ftp/pub/documents/papers/2002/2002-SM-Marcheix

Bidarra’s thesis http://graphics.tudelft.nl/wwwcc/publications/

B-rep architecture history http://en.wikipedia.org/wiki/Boundary_representation

[#2]

I have not used surface attributes, but I doubt it will solve your problem. One typical and simple example of the PNP problem is finding a circular edge of a donut (a toroidal surface) cut by a plane passing through donut's main axis, revealing two circular sections. The two circular edges share the same geometry (a plane, hence the same attribute) and how can you distinguish one from the other? You will find as many pathological cases as you can find in the topology attributes. Maybe I didn't understand your intents correctly.

I think most of the naming problems are not critical, in my opinion. Yes, they are problems, but not a show stopper in practice. Most of the cases, even a  human cannot exactly give a unique answer as some of your examples shows. We can find a "reasonable" solution most of the time within a "reasonable" change of the model. If it doesn't work, fixing is simple most of the time. Comparing with the severity of the problem, nobody has yet found a "universal" solution to the problem that works for all pathological cases so far. You may find a "partial" solution that works for some, but you can always find cases that don't work.

Yong Suh

Message Edited by gadget on 03-22-2008 10:10 PM

Message Edited by gadget on 03-22-2008 10:11 PM

Message Edited by gadget on 03-22-2008 10:22 PM

Message Edited by gadget on 03-22-2008 10:24 PM