Element exhibits incorrect transparency

[Adnan-Ulhaq]

Transparency of element is not visible if you look into this top slab. See below snapshot from MS and Design Review.

See 'Nako-Image1.PNG' and 'Nako-Image2.PNG'.

Steps:

1) Open LBE Model2 from OpenBuildings - L21561_R2UU04A21 file from the NAKO 2) Synchronize the dgn to iModel with ITS-DT 3) Notice that the slab form in not transparent as it was in MicroStation

[pmconne]

Steps 1 and 2 don't mean anything to us. Please provide the .bim file and the .dgn file.

[pmconne]

@Adnan-Ulhaq please provide the .bim and .dgn files.

[pmconne]

Original bug.

[pmconne]

TestCases.zip contains the original DGN, an iModel produced from it, and a simplified DGN containing only two elements, only one of which has transparency.

The contention appears to be that in mstn, element transparency takes precedence over material transparency, while in iTwin.js it is the reverse. I disagree -- my understanding is that in both contexts, the two transparencies are multiplied and both should be drawing the slab as 50% transparent. (material is 100% opaque, element's level is 50% transparent). Evidence.

[pmconne]

MicroStation does indeed multiply the transparencies. iTwin.js only does so for texture transparency; for materials, RenderingAsset claims:

//! A material *always* overrides element transparency as a value from 0 (fully opaque) to 1 (fully transparent).
//!     If RENDER_MATERIAL_FlagHasTransmit=true, then RENDER_MATERIAL_Transmit holds that transparency value.
//!     Otherwise, the transparency value is 0.0.
//!     If the material has a pattern map, the alpha of the sampled texture will be multiplied by the material's alpha (inverse of its transparency).
//!     ###TODO Revit wants to be able to *not* override element transparency. This should be doable.

Handling of material transparency has been wrong from the start. We used to make the material's transparency override (not multiply with) the element's transparency IFF it was greater than zero, which was wrong according to MicroStation. This was later "fixed" by making it override even if it was zero, which was at least consistent but still wrong according to MicroStation.

MicroStation's behavior is not necessarily ideal -- it provides no way for a material to ignore element transparency entirely. We can fix by either:

• Doing like MicroStation does and always multiplying element and material transparencies. This can satisfy Revit's requirement as well -- a material transparency of 0 will mean all transparency comes solely from the element.
• Adding some new flag indicating the material's transparency should multiply instead of overriding. This is more flexible but also more complicated and we know of no real use cases for it, though it's possible some people have been unwittingly relying on the current behavior and will complain if it changes.

[pmconne]

@nerijusJakeliunas what version of iTwin.js are you using to view the iModel?

[nerijusJakeliunas]

@pmconne I open iModel in Design Review with my web browser (Edge) so I do not know what version of iTwin.js is used

[pmconne]

@nerijusJakeliunas that'd be 3.2.4. Thanks.

[bbastings]

Seems reasonable to follow MicroStation on this...not ideal, but at least a behavior MicroStation users are used to, and it also solves the issue for Revit use case.

[pmconne]

This feature will be included in iTwin.js 3.3.0.

[pmconne]

I am reverting this change. Apparently, I figured out how all this works in MicroStation a few years ago, which led to how it currently works in iTwin.js.

In MicroStation, transparency can come from the element, the reference attachment, the level, and/or the material. If it came from the reference or level, it gets multiplied with the material. If it came from the element, it gets replaced by the material.

We're not going to propagate that into iModels. The material's transparency overrides the element's transparency.