distributing textures by name
Hello Jitter Pros,
I am trying to "route" a texture without patch cords, because i am working on a complex patch where I am using textures on different locations. I also try to avoid send/receive objects.
My idea is using named ji.gl.texture objects as an reference and use this reference as an input to feed other shader.
The first try was to use a ji.gl.texture with the same name.
This seems not to be allowed and throws an error "name myname already in use. ob3d does not allow multiple bindings"
This works, but there is no update, if the source texture changes.
The only way i got it working is binding the texture to an jit.gl.layer an capture the layer with a jit.gl.node. Which seems to be not very effective.
Attached a example patch.
Perhaps someone has an idea how to get access to a named texture easily.
I am using Max 8.4.6 on a Mac M1 Machine.
Thanks in advance,
hhelt
You were very close! You just need to send the entire message "texture name" each frame:
TIL you can use texture instead of jit_gl_texture and it works!
EDIT: as the use of the texture message is not documented, I would use jit_gl_texture instead, just to be 100% sure it will work everywhere.
Hello TFL,
Thank you very much for your fast answer.
Perhaps I was not clear enough. I am trying to avoid sending a message every frame.
Your solution is a bit like the "method 2" in my patch with activated gate.
"method 3" works without any send/receive pair and there are no patch cords involved.
I am searching for such a method with less objects ;-)
Perhaps it is not possible and I am using the jitter gl system in a wrong way.
Just a question of coding style.
Thanks in advance,
hhelt
In Max 9 you have jit.bang from the builtin jit.mo package, but it's really the same as using a send/receive (except that you benefits from its @enable attribute)
You made me realize that in Max 9, the @automatic attribute of jit.gl.pix/slab has actually been hidden and are no longer referenced.
I guess jit.gl.pix/slab objects are meant to be used in a chain of object, contrarily to jit.movie or jit.gl.node who are automatically banged if @automatic 1, hence that choice. I guess it's mostly about adapting your coding style at this point!
yes jit.gl.slab/pix require either a bang or a jit_gl_texture message to trigger output.
Hello Rob,
Thank you very much for the clarification.
Is there a single object where i can set a texture name which outputs automatically the texture associated with the name? Like the jit.gl.node object. Would be a nice shortcut.
Thanks in advance,
hhelt
sorry, not clear to me what you're asking for
Hello Rob,
Sorry for the confusion :-)
Here is a patch which demonstrate my thought. (hopefully)
Hello Wil,
Thanks for sharing your thoughts and build the abstraction.
Great idea to add the "erase_color 0 0 0 1" to the jit.gl.node.
I wonder if this variant consumes more resources than sending the texture via send/receive pair.
Perhaps Rob can give an advice, what is the most efficient way to route a texture.
We have many options here. Patch cords, send/receive, bang with texture names ...
It's really nice that there are so many nice and helpful people here in the forum.
hh
So you are talking about resources - fps
I just keep an eye on fpsgui - haha
//
Rule for me is
In Max:
send/recieve mostly for messaging , as long they don't interfere with timing
mc.send~/mc.receive~ for audio as long as they don't interfere with timing
In jitter:
send/recieve mostly for messaging , and cleanliness
@drawto in lieu of patch chords - rarly use send/receive for video (except unusual cases like 1,2 or 3 jit.grab to many places)
-- always one final ji.gl.videoplane , everything else is jit.gl.layer
here is fun:
Rob will know more about efficiency of resources
Yeah, using a jit.gl.node + jit.gl.layer/videoplane is just wasted resource (you basically render your texture on a plane mesh, capture the result and send it as another texture, rather than just sending the original texture). Should not have much impact on simple patches but will definitely eat some fps if the patch already consumes 100% of the GPU.
Using send/receive is OK with jit.gl objects, as long as you know what you do and are careful with the overall routing.
Here is another example which both makes use of send/receive AND sends a message at every frame, so not what OP might want, but still very convenient to use. I actually used that in some big patches without issue.
Hello all,
Thank you for all your great suggestions!
I think in my use case the send/receive way will be the simplest.
The node and drawto solution is also very elegant and seems to be great for positioning and mixing planes with modes.
Greetings,
hhelt
Yeah, those constant message sends are messy, and I'm all about avoiding that. Seems like Jitter GL doesn't let you directly reference a texture without updating it, which is a bummer. TFL, jit.bang is basically a dressed-up send/receive. And yeah, fps matters, I'm always watching that fpsgui. I mostly use send/receive for messages, and drawto for video, keeps things clean.
Hello Koomo San,
Thank you for sharing your experience!
It could be a feature request: Route a texture by name without triggering every frame.
could be realised with
- a new jit.gl.textureforward @name mysource object (automatic 0 or 1)
- allow multiple bindings of named texture
- a new attribute "shared" for jit.gl.texture something like this: @drawto target_name @shared 1
Just some thoughts. Perhaps it a dissent to the way opengl works ;-)
hhelt
Wouldn't this be enough? Maybe i'm missing something....
You can also send multiple input textures by chaining their names like (texture tex0 tex1 ... texN)
