add per-instance opacity

[trusktr]

#29

[trusktr]

In the demo, the materials need transparent: true.

Should we add an opacity boolean to the constructor, like colors, and use separate shader #define for that? Would the define even save on performance if opacity is false?

Is a material's transparent property something that we should enable by default so that the user doesn't have to? Or maybe we just document that the user should make sure the material has transparent: true?

EDIT: I was using my fork in another project, and I totally forgot to set a material's transparent option to true, which wasted some time while I was trying to figure why it wasn't working.

[pailhead]

I've sent you some gists, my concern with this is that it will require a sorting step, which may turn things upside down. Since the matrices are computed on the gpu, i don't think there is a way to sort them just based on their positions without duplicating the work. We end up transforming the origins both on the cpu and the gpu in that case.

It may be that three's default mesh is better suited for this, since it does the transformation on the gpu regardless. But it would also require the buffers to be shifted which can be a lot of work.

Three's own instanced mesh has gone a long way, but I think this may still be worth keeping around (but fixing) because it takes a bit of a different approach AND it should work with many older versions of three.

So the idea that i have:

IF transparent is set to true (either on the mesh itself, or through the material) a different instancing mode kicks in:

position, rotation, and scale are put into a texture, instead of a buffer. These are always indexed linearly, so instance 0 is always the first pixel of the texture.

There is an additional aIndex buffer, which can be shuffled to order the instances.
Without ordering it would be 0,1,2,3,4 for 5 instances. After being sorted, it could be 3,2,4,0,1.

This buffer is then updated, and the instanced mesh does what it would normally do, except the instances are drawn in depth order now.

Thoughts?

[pailhead]

Just to add, imagine that you have 2 views, or 4 like in 3d studio max. All of them need to draw the same instanced struct, but each will have to draw them in a different order. Each would use the same texture of transformations, but access them with different indices. Each view would have to do its own sorting :(

[trusktr]

All of that is fairly advanced for me. It seems what you describe is good for, for example, multiple of the same item in a game spread through out a scene, and we would want them to be properly in front or behind all other objects, as if they were individual Meshes.

That would be neat.

My particular use case does not require that. Let me describe what I am using it for:

I am making a quad (PlaneGeometry) and rendering to that as a renderer target in scene1. The thing that I am rendering to the quad is a grid.

I make the grid (with its cells) in scene2. Each grid cell is a PlaneGeometry in an InstancedMesh. I need to give each cell a different color and opacity.

scene2 contains nothing but a grid (an InstancedMesh with PlaneGeometry instances), so it does not matter if the opacity would interact well with other objects or not because there are no other objects. Furthermore I blur scene2 a little with postprocessing.

I render the grid from scene2, then place scene2's result as a texture on the quad in scene1.

So basically, sorting does not matter at all for my current use case. There is never anything behind or in front of the grid cells in scene2.

As is, I think this implementation is perfectly fine for certain use cases.

[trusktr]

@pailhead I am going to fork and publish on @lume scope on npm so I can move forward. I am adding an HTML API to LUME to enable automatic instancing of objects in a subtree where instancing is applied.

I believe that this opacity feature can be merged as is, then a followup opacitySorting option can be added later if someone needs it, but I don't think that it blocks this initial feature from being put in.

[AnweshGangula]

This is discussed in following issue: mrdoob/three.js#20431