Face stitching is a problem which occurs when the facets of one object lie in the same plane as facets from another object which is in close proximity. Due to z-buffer approximations various pixels in each object appear to be in the same location and consequently exhibit severe face stitching problems when drawn. This behaviour can be seen in the first image below. Data which originates from the GIS/Mining and Microelectromechanical Systems (MEMS) typically suffer from these kind of problems. The only way to eliminate face stitching is to force a drawing order on the geometry. Though HOOPS/3dGS does provide both the Priority Hidden Surface Removal Algorithm as well as the Bring_To_Front to provide this kind of functionality they were primarily designed for 2D scenes and consequently don't take full advantage of the underlying graphics acceleration.

To understand the problem we need to understand how frame-buffer rendering works. When 3D geometry is rendered using a frame-buffer technique each piece of geometry is dealt with independently and is broken down to a series of pixel locations and a z value. This z-value is a depth-value on the frame-buffer of the graphics card. When you have geometry which are co-planar and in close proximity you can run into precision errors and have pixel locations from different geometry have the same z-value which will result in face stitching when the complete scene in rendered. A frame-buffer system works by firstly initializing every value in the frame buffer to zero and then as it processes each object it comes up with a pixel location and z-buffer value for each object in the scene. To draw the object the renderer looks at the z-value of a specific pixel location and only overwrites it if the z-value of the geometry currently being processed exceeds the value that is already in the frame-buffer. The important point here is that it only overwrites the value if it exceeds the existing value. Now if an object is wholly behind another, as is the case when you have layered object, the imprecision may cause for the same pixel location for two objects to have the same z-value however it will never lead to the object in the background having a z-value greater than the object in front. Thus the problem of eliminating face stitching is to simply ensure that the objects are dealt with each other in order so that we deal with objects sequentially from bottom to top.

Doing this is fairly easy with HOOPS/3dGS. When 3dGS traverses a segment tree it starts at the top-most segment and processes subsegments in alphabetical order. So the job of eliminating face stitching simply comes down to alphabetically ordering your segments so that the back object is dealt with first, the second from bottom second and so on. While this is easier to do if you are dealing with sibling segments the logic can be easily extended to generalized segment trees if you just keep in mind that 3dGS will process complete segment trees alphabetically. So for example if you have a segment tree consisting of two segments in the top most node call A and B (say), with A containing segments Z and G and B containing a segment A, then the drawing sequence would be. All geometry in A, then AG, AZ, B, BA and finally BAA.

Note, though this approach could work if the geometry is truly co-incident this method will show best success if there is a little difference between the layered objects.

Below is the layout of a Chip. Here the user is using unnamed segments and so the objects are drawn in random order causing face stitching to occur because of z value approximation errors.

In this case the scene graph was changed so that the top level segments that each layer was residing in were renamed so that they were alphabetically ordered. Face stitching completely disappears.

In summary by using a fairly simple naming convention you should be able to eliminate face stitching except in the cases where the geometry residing in the exact same location in space.