ok, after thinking of it for a while, i understand the node hierarchy, which seems somehow related to a parent/child articulation philosophy that make sense for articulated bodies. However, it sounds like a limitation and a constraint in the wonderful "connect anything to anything" logic in Max.

As for the rasterization, here is a demo patch, and the question is : is it possible to do the same with jit.gl.node / camera (without duplicating objects) ?

the below gets you close. can't really say if this is more useful for you than your existing technique.

thanks for the reply... that's a smart solution ! ;) However I assume there would be more performance hit as the number of objects increases, since there is a separate rendering + GL mixing for each object. I can only make an assumption here, as I am not sure about how GPU handle optimization at that low-level.

The other thing that makes me prefer the first solution at the moment, is the fact that I targetting a general rendering pipeline approach where I can easily switch destinations without having to instanciate new objects for the purpose (like the pix alphablend, in your case).

The ugly thing in the to_texture technique is having to explicitely send all those bangs. That makes a lot of function call where I assume the gl.node approach to be lighter.

At the moment, using "drawto" messages tie the objet to undergo both viewing transform *and* capture in the gl.node/camera chain. Would it be relevant at some point to dissociate the "context" into 1- a viewing transform context on hand 2- a rasterization context on the other hand I can imagine the jit.gl.camera using an @automatic 0 attribute and a name (e.g. "myCamera1") and the jit.gl.*whateverObject to have a "@capturer myCamera1 myCamera1 etc." attribute which would make them rendered by these cameras. I can't see as much as you if it would cause some backward-compatibility issue, though... just my 2 cents. What do you think ?

of course it depends on the complexity in your scene, but the technique i posted will generally be faster for the specific case demoed in your patch, where you want the same geometry and modelview rendered in different places, because the geometry is only rendered once and the remaining operations are performed using textures. your technique renders the blue ball geometry twice.

again, if your technique is working for you, then i would stick with it.

i'll add the rest of your thoughts as notes to the feature request we discussed in the previous thread.

well, if I was completely satisfied with my technique, I wouldn't investigate these possibilities.

A much simpler solution (from a user perspective) than the things I said I said in the previous post and that would work nicely, is to have the possibility that the parent node output the texture (with @capture 1) *even if* some child node is capturing too. In the demo patch, that would make the parent node output *both* red and cyan shape, while the child nodes would output the red and cyan shape *respectively*. Does that make sense ?

For the record, below is the version using Nodes with the feedback effect achieved with planes as in my original post. Just a question about it : why do one need to put a texture (the one called "tmp" in the patch below) attached to main context rather than using directly jit.gl.node's output ? What happens here exactly ?