nope, to_texture is old technology. the recommended approach is capture with jit.gl.node (or jit.world). any reason why that won't work for you?

Thanks for your answer Rob. Yes, that won't work for me because I need to render the depth of some objects into a texture and in the same frame access that texture from a shader attached to another object. I've experimented and discovered that I cannot do that, the texture will be always relative to the past frame. Here's an image of the setup I wish to accomplice:

can you delay everything by one frame, and copy the depth texture into a slab that you use in the next frame pass?

This looks like the right approach Rob, but how can I delay everything by one frame in the context of jit.gl.node?

hey federico, before we go much further, i want to make sure you've seen the "pass.rebuild.depth" example file (and mrt.depth.jxs shader). this might be some functionality you are looking for. here's a more basic example:

in any case, your patch doesn't run for me due to shader errors that I assume are the result of lack of driver support for certain glsl language features. can you explain what you need using the patch below. here the depth values of objects in a node are used as the diffuse values for another objects's shading.

Thanks so much Rob! I've seen the pass.rebuild, and it's really super cool. I'm not sure it can help me with this particular issue but I'll definitely use it in the future. But maybe I'm wrong, maybe I can use it also now, have to experiment with it. The second patch indeed seems to work as expected, using the depth from the same frame. In my patch however I'm accessing the depth from a texture inside the "depth_comparison" shader, and this seems to give me the texture from the previous frame. If you tell me which errors you get I can strip the shader and keep only the bare bone example. Thank you again

errors below, not sure if it's worth sorting through. I imagine the main culprit is the "no available implicit conversion" error.

if i understand correctly the problem, you want to pass the depth texture from a group of objects in rendering another object, but both objects are in the same node.

i guess my suggestion is to bind the "renders-depth" objects and the "needs-depth" objects to separate nodes.

node A (@layer 1) draws the "renders-depth" objects and outputs the depth texture. node B (@layer 2) draws "needs-depth" with the depth values from node A.

AFAIK, that should work without a delayed frame. the layer attribute will ensure that A draws first, and that B's depth texture is up to date.

Thanks a lot Rob! Indeed the method of using two nodes gives me no frame delay. The only problem now is that the depth doesn't get sorted in the right way. Could this be because of how I'm writing the depth in the shaders? And how does it work with blending modes in the case the objects are drawn by two different nodes? Thanks again!

Here's a picture of what I get now

i would set each node's erase_color to 0 0 0 0 and then you can use the default alpha blending.

The only thing is that I would like the sphere still not to be rendered on top of other objects.

well that's what the depth rebuilder is supposed to take care of. might take some tweaking to get it to work in your particular system, but I believe the functionality is there.

After a bit of time I'm back on this patch, that I still couldn't solve in the right way. It looks like that when capturing objects on a node with the @capture attribute, they are not going to be rendered inside the jit.gl.pass @depth videoplane. Is this correct?

not sure what you're referring to exactly.

when a jit.gl.pass subpass tag has a depth ouput attribute (e.g. as in the @fxname depth builtin effect), the pass is drawn to its gl.node's parent context framebuffer and depthbuffer, rather than output as a texture. if you check out the source code of mrt.depth.jxs, you see it writes to the gl_FragColor and gl_FragDepth locations. so it is effectively redrawing the geometry, but also allows you to perform post-processing effects on it. note that the jit.gl.node itself is still outputting the captured textures (color and normals+depth) that you can do whatever you want with.

you can tweak both the depth.jxp pass file and the mrt.depth.jxs shader file to your needs. if you specify <subpass file="yourfile.jxs" output="DEPTH"> in the jxp, then the output is written to the parent context framebuffer/depthbuffer, as opposed to it's own textures as is the case with non-depth-output-enabled pass effects. i tried to reorganize the patch to better illustrate the technique. hope this makes it clearer.

You are the best Rob! I solved it with jit.gl.pass @fxname depth. However I get a slightly worst framerate. Is this because the objects are being redrawn by jit.gl.pass?

¯\_(ツ)_/¯

Or jit.gl.pass simply reorganizes them all before getting drawn? I'm sorry for all these questions, but you are the only person that can answer this : /

the depth pass effect has one sub-pass, each pass effect sub-pass is full drawing pass of the node's scene objects using the specified sub-pass shader. can't really speculate further without seeing the exact patches that you are comparing.