classifying and annotating visualization materials in iTwin

[MichaelBelousov]

What's the best way to "classify" the "visualization material" of geometry in iTwin?

I remember some discussion a while back but I don't know what the result was and can't find where it was.

Would it be like the name/label/code of render materials element in the geometry streams?

I want to automate classifying materials of geometry in iModels and I'm wondering if there's a standard in iModel/ECDb I could use

Also, if I want to allow users to add material metadata themselves, is there any standard convention to layer some material metadata on top of existing iModels? Would it present a problem if I started adding my own Element Aspects into the iModel, pushed changes, and then in the future a user's iModel was trying to merge with upstream work from another iTwin editing application which encountered unknown aspects?

It would also be useful if there were like a standardized list of aesthetic materials like "shiny_gold", "dirty_concrete", etc. I can see that PBR or other textured shading model support in RenderMaterial is probably sufficient but in my use case having a more general list of common materials so I can swap in higher-fidelity textures would be ideal.

[ben-polinsky]

@rschili @diegoalexdiaz any thoughts here?

[diegoalexdiaz]

Re: What's the best way to "classify" the "visualization material" of geometry in iTwin?

The "name" (typically captured as a Code) assigned to a render material depends on each data-writer. For Connectors, they typically just bring the name assigned on the external source for each format. Thus, the semantics that would enable classification of render materials is not captured by the original app. One could go by inferring it from its assigned "name" but it will not cover all cases.

In the new generation of authoring iTwin Native apps (e.g. OpenSite+), the app captures both RenderMaterial and PhysicalMaterial (via one of its subclasses - e.g. PhysicalMaterial:Concrete) and associates them via the BisCore:RenderMaterialSupportsDisplayOfPhysicalMaterial relationship. That enables such classification downstream.

Re: is there any standard convention to layer some material metadata on top of existing iModels?

Augmenting data in an iModel by using Aspects runs into the problem you described. They will likely be dropped next time the Connector synchs data that involves such Element. Also keep in mind that authoring iTwin Native apps use Channels to prevent unintended editing of their data.

I presume you're building an iTwin Native app that will write this material metadata. If that is correct, it should probably do so in its own Channel, by storing instances of a subclass of BisCore:InformationElementRecord that carry such data (e.g. in the form of first-class properties, or by using Json in its JsonProperties column). Such Element instances can then be associated with any RenderMaterial instances in the same iModel.

If one of those Element instances can only be associated with one RenderMaterial instance, you could use a navigation property. Or, in the more general case (which supports being associated to multiple), you could introduce a subclass of BisCore:ElementRefersToElements and use it for such association.