How to replace an existing RenderMaterialElement?

[PeterJBassett]

The RenderMaterialElement class (https://www.itwinjs.org/reference/core-backend/elements/rendermaterialelement/)
has an insertfunction to add new materials to an iModel.

Is there a way to update or replace an existing material?

For example in my connector application I would like to be able to change the texture material, or color of an object.

[pmconne]

Hi Peter,

Currently the only option is to use IModelDb.Elements.updateElement which accepts the JSON representation of the element. The JSON representation of material elements is kind of ugly, which is why RenderMaterialElement's insert and create methods instead accept the more user-friendly RenderMaterialParams - if you use updateElement it will be up to you to make sure you get the JSON fields right. We can add a better API for changing the properties of a RenderMaterialElement and updating it in the database.

Note: the "old" tile generation logic will not detect a change to a render material, so it may continue to reuse cached tiles that were produced using the old version of the material. The "new", faster tiles produced by mesh export service will detect the material change and produce updated tiles. I believe the folks who are using your connector have migrated to the new tiles, in which case this shouldn't pose a problem.

[PeterJBassett]

Hi Paul @pmconne Thanks very much for your answer.
One other question, is it possible to delete an existing render material from the iModel?
Then my connector could delete the existing material and create a new one.

[pmconne]

Yes, deleteDefinitionElements will delete a material element provided it is not referenced by any other elements. Otherwise, you would need to insert a new material, find and update all references to the old material to point to the new one, and only then delete the old one. Seems easier just to update the existing material.

[PeterJBassett]

Hello Paul (@pmconne) In your previous reply you mentioned

Note: the "old" tile generation logic will not detect a change to a render material, so it may continue to reuse cached tiles that were produced using the old version of the material. The "new", faster tiles produced by mesh export service will detect the material change and produce updated tiles. I believe the folks who are using your connector have migrated to the new tiles, in which case this shouldn't pose a problem.

Currently I am trying to update the method of setting colours in the iModel geometry for the 3D assets in our model.
I am noticing that if I change a colour in the connector (by hardcoding a value), and then re-sync the iModel, that the 3D object colour is not changing in the iModel, (or some objects are changing and others are not)

Is this problem caused by the caching you mention?

How can I determine if I am using the new tiling method or not? I used to have a "Try It" option, but this no longer appears in the UI?

[PeterJBassett]

I am using https://plantsight.bentley.com/d4068c50-74e9-4002-89b1-1a9174cc7970/viewer

[pmconne]

Peter, please reach out to Rob Harper, Sameer Purandare, or Darrin Dehorty at Bentley to get the new tiling method enabled in PlantSight.

[PeterJBassett]

Hello @pmconne thanks again for your help. The situation is that the client Shell has an iModel, where the cached colours are stuck with the incorrect colour and they cannot rebuild the iModel from scratch. So we are looking at how to recover the situation.

I am not sure whether Shell are using the new "Tiles" version of iTwin for their production projects yet. If they are still using the older version of iTwin, do you know if there is any way to fix the problem to clear the cached colours, so that the part of the iModel can be resynced to re-apply the correct colours?

[pmconne]

There is not currently a direct, self-serve way for a user to invalidate the tile cache for a given iModel. A Bentley colleague can do it on their behalf if provided with the iModel Id. Obviously that's not ideal.

The self-serve alternative - also not ideal - is to do it indirectly. Cached tiles associated with a particular model become invalidated when you alter a geometric property (placement, category, or geometry stream) of at least one element in that model, or add/delete a geometric element from the model. So if you make+save a geometric change to the model, make+save the inverse change, and push the resulting changeset, this will invalidate cached tiles for that model. E.g., add and then delete an element with a non-empty geometry stream, or change an existing element's placement origin and then change it back.

Sorry for the inconvenience this imposes. The "new" tiles don't suffer this limitation.

[PeterJBassett]

@pmconne Thank you very much for your help. I have tried the indirect method, by deleting the elements from the iModel and re-syncing, and this has worked to restore the colours.