jit.gl.node and transparency

    Apr 07 2020 | 4:10 pm
    Hello, Could anyone help me understand why the background color coming out of jit.gl.node is black? Its @erase_color is 0 0 0 0 and the jit.world erase color is 1 1 1 1. Shouldn't the background color be white if gl.node is preserving transparency?
    thanks Florent

    • Apr 07 2020 | 4:25 pm
      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.
    • Apr 07 2020 | 5:33 pm
      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?
    • Apr 08 2020 | 3:00 am
      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.
    • Apr 08 2020 | 5:21 am
      excellent! thanks a lot
    • Apr 10 2020 | 3:04 pm
      any idea of why it stops working as soon as jit.world is encapsulated in a subpatch?
    • Apr 10 2020 | 4:24 pm
      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.
    • Apr 10 2020 | 5:02 pm
      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