Check for the possibility that a TextureId is a number while cloning it.

[nick4598]

[nick4598]

Should team responsible for Revit Connector be contacted and ask that they bring TextureIds over as hexadecimal strings?

[pmconne]

Should team responsible for Revit Connector be contacted and ask that they bring TextureIds over as hexadecimal strings?

100%. It is never correct to store element IDs in JSON as numbers, JavaScript represents them as doubles which lack sufficient precision. @timlawrence-bentley @jffmarker

[nick4598]

Add more commits by pushing to the [nick/rendermaterial-enhancement](/iTwin/itwinjs-core/tree/nick/rendermaterial-enhancement) branch on iTwin/itwinjs-core.

I will reach out to them with more details, i.e. iModel this was observed in

[nick4598]

It was recently discovered that another iModel has textureIds as numbers instead of hexadecimal strings, and there was no revit connector involved. The two mentioned to me were the Mstn and Navisworks connector. So one of the two, or both may also be bringing textureIds over as numbers.

This has caused crashes in transformation, so I've made a change to map these ids to invalid instead of erroring out on them. The reason for the crash is that findtargetElementId expects a string and not a number.

@jffmarker @timlawrence-bentley Could you have someone look at both connectors to see which is bringing textureIds over as numbers? I don't have access to the iModel this was found in, but we could likely get that access if necessary. Let me know.

[jffmarker]

It was recently discovered that another iModel has textureIds as numbers instead of hexadecimal strings, and there was no revit connector involved. The two mentioned to me were the Mstn and Navisworks connector. So one of the two, or both may also be bringing textureIds over as numbers.

This has caused crashes in transformation, so I've made a change to map these ids to invalid instead of erroring out on them. The reason for the crash is that findtargetElementId expects a string and not a number.

@jffmarker @timlawrence-bentley Could you have someone look at both connectors to see which is bringing textureIds over as numbers? I don't have access to the iModel this was found in, but we could likely get that access if necessary. Let me know.

From skimming source, I think NWD is the culprit. I'll file a bug on the internal backlog.

[nick4598]

It was recently discovered that another iModel has textureIds as numbers instead of hexadecimal strings, and there was no revit connector involved. The two mentioned to me were the Mstn and Navisworks connector. So one of the two, or both may also be bringing textureIds over as numbers. This has caused crashes in transformation, so I've made a change to map these ids to invalid instead of erroring out on them. The reason for the crash is that findtargetElementId expects a string and not a number. @jffmarker @timlawrence-bentley Could you have someone look at both connectors to see which is bringing textureIds over as numbers? I don't have access to the iModel this was found in, but we could likely get that access if necessary. Let me know.

From skimming source, I think NWD is the culprit. I'll file a bug on the internal backlog.

Could you send me a link to that bug so I can track it?

[nick4598]

@mergifyio backport release/4.8.x

[mergify[bot]]

backport release/4.8.x

✅ Backports have been created

• #7064 Check for the possibility that a TextureId is a number while cloning it. (backport #6933) [release/4.8.x] has been created for branch release/4.8.x but encountered conflicts