Added per-instance visibility attribute to the instancing_modified example

[WestLangley]

As suggested by @mrdoob.

TBH, I think the demo needs improvement.

I'd be just as happy to remove it, but I think the code-injection pattern is informative.

[WestLangley]

I don't like it either, but perhaps someone can suggest a better demo.

[Mugen87]

Sorry for the late feedback but how about controlling the instance visibility like so:

• Maintain an array of 3D objects with a custom visibility property in userData. These "dummy" 3D objects represent the instances.
• Set the transform, color and visibility.
• Sort instances in the order visible/not visible and update the attributes of InstanceMesh accordingly.
• Use InstancedMesh.count to determine the number of instances that should be rendered (determining the draw range).

The downside of this approach is you need a 3D object per instance to keep track of the instance state. However, it's not necessary to discard fragments so you only render what's actually necessary. Overall, it should the more performant approach. And it already works without enhancing built-in shaders.

I agree it would be more interesting to have texture offsets per instance. But instead of using the code-injection pattern, I would favor a setUVOffsetAt() method in InstancedMesh.

[WestLangley]

instead of using the code-injection pattern

If we are going to avoid recommending the use of code-injection via onBeforeCompile(), we should remove the example, because the example uses it.

Your suggestion is a work-around to control instance visibility, but it is not a replacement for the example, IMHO.

[Mugen87]

I've revisited this PR since I have seen a community member using the example's code for having colors per instance. The dev was not aware about setColorAt(). Maybe is better to remove the example to avoid such confusion.