Color Swap Highlighter does not restore color, if (shared) material is modified at runtime
See original GitHub issueHappens if you have gameobjects / interactibles which dynamically change their color at runtime.
E.g. a random color is assigned to a cube in the Start()
method using material.color = myColor
). If afterwards a controller touches the cube, it will correctly adopt the selected highlightColor but will never go back to its initial state.
The reason is that on the first occasion that the material of a renderer is modified, it is cloned (if it is also used by other renderers) and from then on, this copy is being modified. As such, the StoreOriginalMaterials
method already gets a reference to the cloned material and the ChangeToHighlightColor
method will modify the same instance, thus overwriting the initial state.
The solution would be not to backup the references to materials but to make actual copies (new Material(oldMaterial)
).
Issue Analytics
- State:
- Created 7 years ago
- Comments:13 (12 by maintainers)
Top GitHub Comments
There may be another solution. Someone did a PR a while back using MPB to do the colour swapping and apparently that way doesn’t break batching.
I never got chance to look at the PR but it may be a solution?
https://github.com/thestonefox/VRTK/pull/704
I applied the fix from earlier in this thread but I’m still hitting the issue. Does the fact that I’m using drop zones change anything here? I also have multiple interactable objects nested within another.
Essentially I’ve built an experience where the user builds a model. There are a bunch of GameObject that the user picks up and snaps together (like lego blocks). When placing some of these objects, the highlight color gets stuck.
The issue is intermittent…