Bug: Glance doesn't respect "ColorBy" property when loading STLs from URL

[hbraunDSP]

My team is encountering a very similar bug to #408 but the work-around proposed there isn't adequate for us: https://discourse.paraview.org/t/glance-file-generation-colorby-not-loading-solid-color-for-stl-files/15180

We need to programatically generate state.json files, to be opened by Glance, with meshes loaded from URLs in STL format and colored with a solid color of our choice. In the current version of Glance, we get the "attempt to set zero width color range" error mentioned in #408 and all loaded models show up in dark blue (minimum value of the "cool to warm" colormap).

Interestingly, in v3.5.10 of glance (hosted on https://pvw.kitware.com/glance/) the colorBy property is respected, but we encounter other bugs which make it unusable for us. We are currently looking at past releases and trying to find one that works for us.

I am attaching two .glance files. TieFighter.json is an example we found which works with both v3.5.10 and "nightly" versions (hosted at https://kitware.github.io/glance/app/) while colorby_bug.json only works with v3.5.10. The only difference is that TieFighter.glance loads a .obj file, while colorby_bug.glance loads a .stl file from a different url.

colorby_bug.json
TieFighter.json

[floryst]

Just a heads up, I might not be able to get to this in the next week or so depending on how complicated the issue is.

[hbraunDSP]

We've done a little work on our end and found out that v4.17.1 doesn't have the problem behavior, but the bug was introduced (or re-introduced) in v4.18.0. Given that information, Commit efac31c is the likely culprit.

What is the desired behavior of the colorBy property? Do we set colorBy: [] to get a solid color? This appears to be the case until v4.18.0. Or do we set colorBy: ["solid"], or is it something else I haven't thought of? If you can tell me what is supposed to be happening we may be able to contribute a fix ourselves.

[hbraunDSP]

A short update: After forking Glance and reverting the efac31c commit, the problem is solved for us. However, I assume the commit was made for a reason, and without knowing what your goal was we aren't able to contribute a fix.