Question about semi-transparent fragments in front of other fragments in shader material

Questions
1

i’m hoping to use many planes inside a single geometry and move them around by modifying the vertex information inside a vertex shader. i’m using a radial gradient for each plane calculated in the fragment shader that goes from a color to transparent. in the semi-transparent parts of the gradient on the planes, i’m seeing it hide the fragments behind the other planes completely. i have tried fixing it from similar issues on this forum i saw by adding logarithmic depth buffer shader chunks, and also experimenting with the premultiplied alpha settings, but haven’t been able to figure it out yet :confused:

i created an example of the issue i’m having here:

i know this is not a bug but i’m probably just not implementing this properly. hoping someone could help point me in the right direction to get it so the fragments on the planes show up behind the semi-transparent fragments and don’t get culled completely by the front planes?

thanks!

2

You’re close! I would add depthWrite: false on the material.

Ideally transparent triangles would be drawn in order from furthest from the camera to nearest. Sorting would also be an option here, but at some scale sorting individual triangles every frame becomes too costly, and just disabling writes to the depth buffer is easier. Without that, once a closer triangle has been drawn, three.js will not draw anything behind it – that causes the clipping you see.

3

thanks for the info!

sorry i couldn’t reply until now, yup depthWrite: false does work, but only for a situation like in the example above where it doesn’t really matter whether each plane in the geometry overlaps in front or in back of each other. if I throw a texture map into the fragment shader uniforms for the planes to draw (instead of just drawing a gradient), the clipping still goes away but you’ll notice the planes not being drawn in the correct depth order.

i guess the only way to do this while using a texture map for the planes will be some kind of solution like you mentioned. which i guess would require some kind of javascript sorting method run on every frame. unfortunately i’m hoping to get this going with texture maps and at a scale of 1000s of planes, so not really sure that will work out for me performance wise.

i’ll definitely need to come back to this at some point. so if any other suggestions come up, please let me know too :slight_smile: for now, i need to put this on hold and revisit it later.