Well, the algorithm and the approach are a tradeoff. It has upsides and downsides compared to other transparency rendering approaches.
But, allowing users access to the targets render buffer is a different thing. Three.js has many places where this pattern happens:
_private_object = public.foo || _private.foo
Which is awesome! For example
customDepthMaterial works like this. It’s not really documented, it’s not really explained how it works, but it works. Somewhere deep inside
WebGLRenderer you have:
result = customMaterial || materialVariants[ variantIndex ];
So, if you don’t provide
customMaterial yourself by slapping it onto a mesh:
mesh.customDepthMaterial = myDepthMaterial
It will just use something internal.
When we work with
THREE.WebGLRenderTarget three.js creates a render buffer for each target and does not give you any access to it.
My approach requires two different targets to use the same render buffer. Following the pattern present in so many places in three.js you could do.
myRenderTarget = new THREE.WebGLRenderTarget() // render buffer created and you cant access it
myRenderTarget.renderBuffer = myRenderBuffer
myOtherTarget.renderBuffer = myRenderBuffer
As a result, my example could work, but so could many others that we don’t know or that are yet to be written.
I have no idea why this is pattern is selectively applied in some areas but then not in others.
Perhaps you could add a comment here and we could both figure it out