jit.unpack vs swiz
hi all,
i'm trying to translate some jitter patches in jit.gl.pix, for better understanding and to see if staying in the Gpu will improve performance. Now i ran into this problem: I'm trying to substitute jit.unpack with swiz in gl.pix. But when I try to unpack a 12 planes matrix (from a gridshape) the first five planes are the same using unpack or swiz, but the others planes (normal vectors and following planes) doesn't. I tried to norm some input but no success. What I'm missing?
Hey Riccardo,
you should consider a couple of things:
1) jit.gl.pix is intended to work with textures. Textures can contain only 4 planes, therefore the "swiz" operator doesn't work like in jit.gen, but instead it works only up to the fourth index (swiz 0 1 2 3, or swiz r g b a, or swiz x y z w)
2) in the "GL" world, the alpha plane is the last, so to swiz the planes in the correct order the indices of the swiz operators must be 3 0 1 2.
See attached patch:
Besides, you should consider if this approach can lead to a real performance boost. Having to pre-unpack the 12 planes geometry matrix constitutes a bottleneck, and unless you want to dynamically change the geometry, it's better to compute the parsing only once, and it doesn't really change much if you accomplish that on the CPU or on the GPU
Ciao Matteo,
thank you for the clarifications and for the patch. I understand better now.
Regarding point 2 of your answer i saw that the order is argb in gl pix instead of rgba in jittter world. But as you guessed I'm trying to change the geometry dynamically and I modified one example in the jit.gl.mesh help:
I removed the jit.rota objects from the original patch, planning to replace them with a gl.pix and then seeing all jit.pack objects i wondered if it was possible (or more efficient) to substitute them with gl.pix.
I'm planning a complex performative event, with lots of live audio and video interactions and every frame gained allows me to feel more comfortable. I thought switching between cpu and gpu back and forth was not ideal.
My goal is to recreate something similar to the rutt-etra videosynth, created by Vade several years ago as a shader. But the shader doesn't work in gl3 and I'm not good enough at programming to update the shader, so I started with this example to try to change the geometry dynamically (especially the vertex z position, both by extracting data from the luma, like in this one case or even from audio).
Nice patch, Thank you!
Two issues:
If i use the output_texture 1 (on) on the movie or image I get a black screen, with output_texture 0 everything is fine.
I cannot view changes by varying the line_width attr of the mesh (btw this happen also when I try the Vade' old Rutt-etra shader in gl3). Instead the point_size attr is working properly. Any hint?