Distinguish between missing vs. default VisualAspect color

[mkoval]

There is currently no concept of having a VisualAspect with no color information. If the user does not set the color, then it defaults to blue. This is problematic when working with textured models where the information in the VisualAspect is most naturally used to tint the existing texture.

There is no way to distinguish between the default color (which should correspond to "no tint") and the user explicitly setting the VisualAspect to that color (which should correspond to "blue tint"). I see three possible solutions:

1. Always treat the color of as a tint, which results in textured models being tinted blue.
2. Change the default color to white, which is a poor default for non-textured models.
3. Distinguish between a missing color and one that has been explicitly set, which allows the renderer to inspect the Shape before choosing which default to use.

I suggest (3). This could be implemented by adding an isColored flag to VisualAddon or replacing the current member variable with something similar to a boost::optional.

For an example of what (1) looks like, see below. Notice how the entire model has a strong blue tint.

[mxgrey]

(3) makes the most sense to me. It's a shame that std::optional won't be available until C++17, because neither an extra flag nor additional boost dependency is very appealing to me. But for lack of a better solution, I'd be okay with either.

[jslee02]

I would also prefer (3) and using flag rather than boost::optional unless we want to keep boost dependency for the long term.

[psigen]

I would possibly propose: (4) Ignore color values if a texture is provided.

It seems like if you were actually trying to tint things, using it this way would lead to very bad behavior if you had one textured model and one manually colored model. The textured model would get tinted, but the colored model would completely change color regardless of the original colors.

If you actually want tint to behave consistently, it would need to be multiplicatively composed with the diffuse color of the model.

If we want this somewhat inconsistent behavior just to make some simpler use cases easier, we should probably do it with (3).

[mkoval]

I agree with @psigen's point.

The one exception is transparency, which behaves the same on both colored and textured meshes. I often want to make a model semi-transparent for visualization purposes, e.g. to geometry that would otherwise be hidden. This is currently only possible by setting the color to white with non-unit alpha.

Perhaps we could implement (4) and split transparency out into another field?