node erase_color overrides its parent context erase_color. if you want to see the parent context erase_color then don't set the node erase_color.

thanks again! that makes sense If I apply a vz.embossr after the jit.gl.node, it affects the background color as well. Is it because the cf.emboss.jxs does not preserve tranparency, or am I doing something wrong?

ah, in this case yes you want to zero out gl.node's erase_color, but you also need to enable blending in order to get your expected results. jit.gl.layer will do the trick.

excellent! thanks a lot

any idea of why it stops working as soon as jit.world is encapsulated in a subpatch?

your jit.gl.layer needs to be bound to the jit.world via the drawto argument. if it's in the same patch as the jit.world it will happen implicitly, but if you more the jit.world to a sub-patch the jit.gl.layer will bind to the first context it finds (in this case the jit.gl.node), and therefore you need to explicitly provide the drawto arg.

the patchcord connected from the jit.gl.layer to the subpatcher inlet isn't doing anything BTW, as matrixoutput of the gl.layer object is not enabled, and even if it's enabled it will output the geometry of the layer (a simple rectangle) and not the pixel contents.

either include the layer into the sub-patcher with the world, or give it the world name as an arg and remove the patchcord.

thanks!! that totally makes sense

for some reason I thought connecting the patch chord was similar to the "draw_to" argument and I was wrong