Julien Bayle

Hi there, I noticed something very weird in my new jitter-based system, and it occured in different situations.

Candid description: sometimes, when I blend / mix 2 texture using kind of dodge blending, burn etc according to usual blend modes 

https://en.wikipedia.org/wiki/Blend_modes

 , I got some part of my texture which are plain black and whatever I can do ... it keeps black there. The only way to "remove" and reset the thing is going from floating mode to window mode for my world's window, for instance.

weird.png

After that, whatever texture I send to the window ... the black area cannot be overlayed or "removed".

It occured with the basic dodge operation within a jit.gl.pix.

It also occured sometimes when I was using a .jxs based shader (temporal slide). etc.

1st question : is it sometimes someone already got ?

2nd question : can the cause come from float32 vs 64 things ? or something else ? what is that black area ?

years with max + jitter, first time I got that weird thing.

Candid description: sometimes, when I blend / mix 2 texture using kind of dodge blending, burn etc according to usual blend modes https://en.wikipedia.org/wiki/Blend_modes , I got some part of my texture which are plain black and whatever I can do ... it keeps black there. The only way to "remove" and reset the thing is going from floating mode to window mode for my world's window, for instance.

It occured with the basic dodge operation within a jit.gl.pix.
It also occured sometimes when I was using a .jxs based shader (temporal slide). etc.

1st question : is it sometimes someone already got ?
2nd question : can the cause come from float32 vs 64 things ? or something else ? what is that black area ?

Hi there, I noticed something very weird in my new jitter-based system, and it occured in different situations.
Candid description: ... 

weird-corrupted-like-textures-after-some-texture-operations

Unity Care Builds Momentum in Q1 2022 with Successful Outcomes, COA Accreditation and Expansion Across Three Counties.

Unity Care Builds Momentum in Q1 2022 with Successful Outcomes, COA Accreditation and Expansion Across Three Counties.
Unity Care

Consultant, City Manager, and Governor appointed @AmeriCorps Commissioner focused on strengthening communities and planning the next outdoor adventure.

Consultant, City Manager, and Governor appointed @AmeriCorps Commissioner focused on strengthening communities and planning the next outdoor adventure.
Michael Grayum

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.

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.

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 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.

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.

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.

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). 

i agree, normalizing them is a good solution. 

...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 

 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)

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)

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)


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