Weird corrupted-like textures after some texture operations ...

Got it.

Clamping values solved the problem. For some weird reason, the jxs temporal slide shader doesn't work well with float (64 and 32 too I guess) and... for some WEIRD reason, I got negative values as a result.

gl_FragColor = clamp(mix(down, up, amount),0.,1.); solved everyting.

Nice catch Julien! Thanks for sharing.

thanks for sharing, I'll investigate adding your fix to this shader.

I don't know if it would be done on the endpoint side (jit.world / window, pwindow) or on the generator side.

i got this black area recently too and i don't understand why either, but i notice i lessened the chance of it by restraining values as well. was using a 'float32' texture(from Matteo Marson's recent oscilloscope tutorial), but i then put it through a jumble of operations whereby the additive mix made the screen bleed gradually into black, and then the only way i could use the drawing context again was by reinstantiating jit.world. my only guess was that i was somehow writing very extreme negative numbers to the screen maybe(?)... the patch is a bit too big to share now, but... ...i too wonder about fixing on endpoint/drawing-context vs. generator/source-functions(i like the extreme level of experimentation we can get into: for example, one time this black bleed happened by using the 'rotor' object within jit.gl.pix... i don't know if we're supposed to rotate color by quaternions (haha), but it was fun to do(perhaps it can lead to some strange negative/imaginary numbers, though, when translated to float32 somehow that cause this black screen death), and i would prefer to have that option left in as freely as it is, than to have it restrained in any way). just my 2cents.

actually, this what I had. imho, a generator "doesn't have to know what is required by objects connected to its output" it should be able to deliver whatever you want to (float32, float64, char whatever).

if pworld, world / window can't get negative numbers in, they have to clip these, or to rescale these.

i agree, normalizing them is a good solution. [start-of-tangent] ...but also, i wish this normalization was hard-wired into every graphics pipeline, because if we think about it: every graphics pipeline calculates the vertex shader before the fragment shader, so there could be this 'normalizing' of values that happens right at the fragment shader(allowing us to use something like 'rotor' function in 3D space for vertex shader, and then freely try the same function out in fragment shaders as well).

(we need a consortium of sorts, like a branch of IEEE, one that governs graphic-pipeline standards, and we need to democratically vote(administrated by them) to change the standard so that all manufacturers of graphics chips, and all associated language specifications(whether metal, or openGL, or whatever), will create this basic but essential change in either their hardware or the language/software-side... i am too lazy, and prefer to get more fresh air, someone else should do all this) [/end-of-tangent] if they normalize this in Max, i will have to learn how to do it in other environs manually... but then again, this thread has taught me how, so that's ok, too :D (i hope they document any change beyond this thread, though, beginners will try to transfer things to other environs and get very confused)