elementOverride with modelOverride

[candcconsulting]

I have overridden the colors of models ... which works well ... using

export function colorModels(vp : any, elementId: string, colour = {r: 255, g : 0, b: 0}) {
        
    const featureAppearance = FeatureAppearance.fromJSON({ rgb: colour } as FeatureAppearance);
    // HideIsolateEmphasizeManager.overrideModel(vp, elementId, featureAppearance);
    vp.overrideModelAppearance(elementId, featureAppearance);
    vp.addViewedModels(elementId);
    vp.changeModelDisplay(elementId, true);
  }

However, when I try and override an element within one of those coloured models, this does not work

`export const colourElements = (
  vp: any,
  elementSet: any,
  clear?: boolean,
  colour?: any
) => {
  const emph = EmphasizeElements.getOrCreate(vp);
  if (clear) {
    emph.clearEmphasizedElements(vp);
    emph.clearOverriddenElements(vp);
  }
  if (!colour) {
    colour = ColorDef.fromString("red");
  }
  //const allElements = ecResult;
  let allElements = [];
  if (typeof elementSet === "string") {
    allElements = elementSet.split(",");
  } else {
    allElements = elementSet;
  }

  emph.overrideElements(
    allElements,
    vp,
    colour,
    FeatureOverrideType.ColorOnly,
    true
  );
  emph.emphasizeElements(allElements, vp, undefined, true);
};`

Can I only have one override ...
my requirement is to color requested models then further show colors of elements based upon a status.

I could uncolor the model and then color all elements of the model and then override ... if that is what I have to ... I just figured it was moving a lot of elementIds around.

Not sure who many elementIds will be in the target models as yet so looking to do this efficiently.

I did try and build a sandbox of the code ... but the sandbox kept crashing when coloring the models in the widget (or did not color them at all if I did not use a widget ;))

[pmconne]

You can override different aspects of the appearance based on different criteria. Conflicts between multiple overrides attempting to override the same aspect are resolved using a defined priority order:

It is possible to override multiple aspects of a feature on different bases. For example, you might specify that all features belonging to subcategory "A" should be drawn in red, and that all features belonging to model "B" should be drawn 50% transparent. In this case, a feature belonging to both subcategory "A" and model "B" will be drawn as 50% transparent red - the separate overrides are combined to produce the feature's overall appearance.

In the case of conflicts, there is an order of precedence:

• Model overrides take highest precedence.
• Element overrides are of higher precedence than subcategory and animation overrides.
• Overrides applied by a RenderSchedule.Script's ElementTimeline are of higher precedence than subcategory overrides, but can be suppressed on a per-element basis via ignoreAnimationOverrides.
• Subcategory overrides have lowest precedence.

You're correct that given the current implementation, you would have to individually override every element in the model. That would be unacceptable performance-wise. To avoid that, we would need to give you some control over the priority of your overrides.

[candcconsulting]

Hi @pmconne
I changed the code to try and colour the elements inside the model ...
In this instance there are only ~1800 elements .... in an array ...
this is the call ... I am using this
https://www.itwinjs.org/reference/core-frontend/rendering/emphasizeelements/overrideelements/
rather than this
https://www.itwinjs.org/reference/core-common/rendering/featureoverrides/overrideelement/

  emph.overrideElements(
    allElements,
    vp,
    colour,
    FeatureOverrideType.ColorOnly,
    true
  );  
};

This is the error that happens in my viewer ... not immediately ...

😞 Oops, something went wrong - please reload the page.
In case you're interested in the details:
TypeError: Cannot read properties of undefined (reading 'length')
at Object.getLowerUint32 (http://localhost:3000/static/js/bundle.js:102706:24)
at Overrides.override (http://localhost:3000/static/js/bundle.js:113048:76)
at EmphasizeElements.addFeatureOverrides (http://localhost:3000/static/js/bundle.js:148016:31)
at ScreenViewport.addFeatureOverrides (http://localhost:3000/static/js/bundle.js:163516:22)
at Overrides.initFromViewport (http://localhost:3000/static/js/bundle.js:176544:22)
at new Overrides (http://localhost:3000/static/js/bundle.js:176514:26)
at ScreenViewport.renderFrame (http://localhost:3000/static/js/bundle.js:164342:25)
at ViewManager.renderLoop (http://localhost:3000/static/js/bundle.js:159605:16)
at IModelApp.eventLoop (http://localhost:3000/static/js/bundle.js:151016:28)
at http://localhost:3000/static/js/bundle.js:150978:44

If I do not try and render the elements then that is OK ... if I use emphasize that can work ... I was using a similar technique for some reference models ... but can easily change the colour ...

I am not reliant on making the above work ...it is more feedback for yourselves.

Note if the precedence was

Element overrides are the highest precedence
Model overrides take next highest precedence over animation and subcategory
Overrides applied by a RenderSchedule.Script's ElementTimeline are of higher precedence than subcategory overrides, but can be suppressed on a per-element basis via ignoreAnimationOverrides.
Subcategory overrides have lowest precedence.

Then this conversation would be moot ... but I am not sure which other requirements are driving the current implementation.

[candcconsulting]

... looks like there are some rogue entries ... investigating

[candcconsulting]

Apologies ... there were some rogue elementIds ... which were causing the crash ... they are now filtered ... but the swap of the precedence would still have helped ;)

[pmconne]

Note if the precedence was

Element overrides are the highest precedence Model overrides take next highest precedence over animation and subcategory Overrides applied by a RenderSchedule.Script's ElementTimeline are of higher precedence than subcategory overrides, but can be suppressed on a per-element basis via ignoreAnimationOverrides. Subcategory overrides have lowest precedence.

Then this conversation would be moot ... but I am not sure which other requirements are driving the current implementation.

Yes, and an argument could be made that element taking precedence over model would be a more natural default - but we can't change the default now without breaking existing users.

Thanks for raising the topic. I filed issue #7433.