Transparency with multiple shapes

[robert-lipman]

I have an example of an assembly with multiple shapes. Only one of each shape is DEF'd and the others are USE'd. For example, there is one blue bolt, that is grouped in an assembly of three bolts with nuts. There are two of the bolt/nut asssemblies that are part of a bracket assembly.

Here's the example. https://pages.nist.gov/CAD-PMI-Testing/bracket.html I'm using a local copy of x3dom 1.8.3 after the problems with the x3dom server.

Use the transparency slider and then rotate the model around. The blue bolts are sometime very blue and other times take on the color of whatever surfaces are in front of it. Switching off the plate and rod-assembly makes this even more apparent.

Is this a bug or a feature? If it's a bug, can it be fixed?

[andreasplesch]

Thanks for considering a transparency option.

The popping of the blue bolts and also other components comes from depth sorting of the shapes by the center of their bounding boxes. When the relative sort order between two shapes changes, the rendering changes. This is a problem when the center of the bounding box is misleading or unusable which is often the case for intersecting, enveloping, or L/complex shaped objects.

I also noticed that with high transparency levels (0.9) the popping effect is much less pronounced, presumably due to how transparent colors are blended together. So this may be a simple workaround, eg. just offering a fixed transparency option rather than a slider.

Another workaround is to disable the depth sorting by fixing the sort order with an explicit sortKey:

https://andreasplesch.github.io/Library/Viewer/index.html?url=https://gist.githubusercontent.com/andreasplesch/4324f541f03e7f0dfd1e95e67979765a/raw/4e57a07a4d7e6e649eb838557f859d7f48499502/STEP_bracket.x3d

It is not clear what the appropriate sortKeys should be but it gets rid of the popping since the blending happens always in the same way. For opaque rendering the sortKeys would need to be removed since then depth sorting is necessary.

This may suggest that dynamic sorting by depth may be generally disabled for transparent shapes or perhaps for scenes without opaque shapes. Let me perhaps check other X3D browsers.

The proper solution would be accumulating color in many render passes instead of just one pass but this is expensive for large scenes and a large new feature to work on.

So this is a lack of functionality or a non-feature rather than a bug.

Do other X3D browser deal better with the transparent STEP bracket ? If so, perhaps their solutions could be adopted.

[robert-lipman]

I haven't tried any X3D browsers, only x3dom in a web browser. There will be a disclaimer in my software about the popping effect with the colors of parts in an assembly. If there are hundreds or thousands of parts in an assembly the popping effect is much less noticeable than the bracket assembly.

[andreasplesch]

Thanks for the extensive testing. Here is more background: https://en.wikipedia.org/wiki/Order-independent_transparency Please feel free to reopen the issue for any reason.

[brutzman]

This is an interesting issue that seems to have broad implications.

I think that depth sortKey is interesting and a worthy technique in its own right. However we should remain aware that such a sort indicator is relative to other objects, which might change (or get removed or get replaced) as models are modified. Recalculating sortKey values seems like author (or tool) logic that cannot be easily replicated. Using a relative heuristic is certain to be suboptimal and sometimes incorrect.

First, wondering, does STEP have a construct for such a property?

Second, wondering, might more deliberate computation of an actual object center help? For bounding boxes, bboxCenter must correspond to bboxValue so that the bounding box itself is positioned correctly. Thus we should look at alternative solutions to this challenge. For example, we might instead define a metadata field for centerOfGravity (or somesuch) that was required to be inside the rendered object geometry itself, just as for real objects.

For that to work, L-shaped or irregular objects that had external centerOfGravity might instead lead us decomposing them into multiple concave subshapes... centerOfVolume perhaps... complicated.

The centerOfGravity field, if present, might then supercede more-ambiguous bboxCenter values when sorting.

If centerOfGravity field (or a conceptually different field) works as an absolute spatial reference, then we can promote the use of such metadata as a suggested practice. With experience and effective results, we might then promote it further someday as part of X3D 4.1. Pushing this conversation to x3d-public mailing list would then be a good idea.

Thanks for careful scrutiny of this problem and considering possible general solutions.

[andreasplesch]

Thank you for engaging here. Good transparency is interesting because it is something users may take for granted but is a difficult computer graphics problem to address in a general way.

As mentioned, solutions offered by years of research are often presented under the topic of "order independent transparency". It is sometimes cautioned that a better representation of the physical process of light making its way to the observer is needed for an accurate and general solution which requires ray-tracing. Luckily, we do not have to consider polarized light sources (https://www.youtube.com/watch?v=MzRCDLre1b4) which have their own peculiar properties of superposition.

An explicit sortKey is specific to a scene and relative to sortKeys of other Shapes in the same scene. https://github.com/x3dom/x3dom/blob/1e8c8b5e39dd5769a4ca07b7ce652cea0dde9f28/src/util/DrawableCollection.js#L312 has the algorithm of how x3dom is sorting. If any Shape has a sortKey other than 0, sortKey sorting is used throughout. If two sortKeys are the same, sorting falls back to sorting by depth of center of bbox (transparent) or coverage (opaque). All transparent objects are always drawn before opaque objects.

Shapes from Inlines are treated as if they are in a Group in the scene, eg. sortKeys in Inlines also would trigger sortKey sorting.

I believe STEP is not concerned about rendering in itself and probably does not have a concept of depth sorting. It probably does have metadata.

This is all not suitable for sharing and reuse, and meant to be used only for specific use cases. Perhaps separating sortKeys from Shapes into a Scene property or Environment node would help but is not very practical.

The idea of enabling a user provided location to be used for sorting rather than the bbox center could work for some situation, a SFVec3f "sortCenter". Since calculating a center of gravity would involve volumetric tesselation, and checking for closed volumes vs. open surfaces, it would be left to an author to provide such a location.

I am not sure if it would help for intersecting of enveloping situations. Also I am not sure if many authors would spend the effort to determine suitable sortCenter locations although this could perhaps be accomplished by preprocessing with dedicated tools.

[robert-lipman]

You are correct that STEP does not know anything about rendering or depth sorting. It's all about modeling many different aspects of manufactured parts and assemblies.

I tested several free STEP file viewers and most do not have any type of part transparency. One can make individual parts transparent by selecting them one-by-one. None have the overall transparency like in my viewer with a slider bar. Overall I think x3dom does a decent job if you can ignore the colors popping when rotating a model.

I test my viewer with many STEP files that I download from GrabCAD. The largest being 1.5 GB and the transparency works well.

[tsturm]

In instant3Dhub we use an OIT approach based on Mc Guire's Weighted Blended Order-Independent Transparency technique with a modified weightening function. In the future, this could be an option for x3dom as well.

To get an impression how it would look:

1. Open the following Link Bracket visualized with instant3Dhub
2. Inside the TreeView -> Right click the root node to open the context menu
3. Select Appearance->Change Appearance
4. Only move the transparency slider inside the new dialog
5. Press confirm