Rendering opaque object inside transparent one

Hi again @caroline :grin:,

I’m trying to render an opaque object inside a transparent one.
img img2
My approach is:

  1. First a draw call with the opaque object, with not blending enabled and with depth compare function set to less.
descriptor.depthCompareFunction = .less
  1. A second draw call with the semi-transparent object, with blending enabled and with depth compare function set to always
if !opaque {
    pipelineDescriptor.colorAttachments[0].isBlendingEnabled = true
    pipelineDescriptor.colorAttachments[0].rgbBlendOperation = .add
    pipelineDescriptor.colorAttachments[0].sourceRGBBlendFactor = .sourceAlpha
    pipelineDescriptor.colorAttachments[0].destinationRGBBlendFactor = .oneMinusSourceAlpha
 descriptor.depthCompareFunction = .always

But I get undesired blending with the opaque object and the faces of the transparent object behind it… And if I set both with less not all visible primitives of transparent object are rendered…:slightly_frowning_face:

Can you give me some advice or key-word to search?

Thanks in advance!!!

Transparency is hard.

The theory is that first you render all opaque objects, then you render all transparent objects, setting your blending accordingly.

However, if you’re rendering blended fragments on top of blended fragments, to get the blending equation working correctly, those fragments need to be sorted from front to back.

This is a good tutorial on transparency: Tutorial 10 : Transparency. It’s OpenGL, but the concepts are the same.
Answer to a question on the Khronos forum: OpenGL Depth Buffer with transparency - #3 by GClements - OpenGL: Advanced Coding - Khronos Forums

You might see whether you can get away with culling back faces. That way you don’t get weird blending of isosphere faces.


Screen Shot 2020-10-07 at 9.16.56 am

Otherwise I think you’d have to sort your isosphere vertices front to back. Not something I’d recommend if you’re moving the camera, as they’d have to be re-sorted when the camera moves. (Also I’ve never done this!)

As for searching for solutions, you (probably) won’t find a Metal one. I generally prefix my searches with (1) DirectX, (2) OpenGL, (3 as a last resort and hardly ever!) Vulkan. DirectX is closer to Metal than OpenGL is.


Wowwww! Awesome answer! Thank yo very much. Certainly I will incorporate Direct X and OpenGL to my searches… See you :wink: