Mattijs

jit.xfade with a negative xfade argument when fading two gridshapes looks different in 1.6.3b compared to 1.5.2.

I included an example of this below. To reproduce, open and start the patch in jitter 1.5 and in 1.6.3b. Expected behaviour is that both outputs look as it does in 1.5.

I attached a screenshot of how it looks here.

Mac OS 10.4.8, Max 4.6.2 and 4.5.7, Jitter 1.5.2 and 1.6.3b

Does someone know of a way to make the output of 1.6.3b look like the one in 1.5.2?

jit.xfade with a negative xfade argument when fading two gridshapes looks different in 1.6.3b compared to 1.5.2. 

jit-xfade-behaves-differently-in-jitter-1-6-3b-bug

Ah, appears it also happens with xfade > 1. Screenshot attached.

this looks like its a textureing issue only - the geometry looks the 

same - maybe xfade hasnt changed, but the texture coordinates being 

output by the matrixoutput 1 from the object you are using?

it use a jit.print and see what you find - id do it, but I dont have 

On Dec 20, 2006, at 12:28 PM, Mattijs Kneppers wrote:

> Ah, appears it also happens with xfade > 1. Screenshot attached.

> Interactive audiovisual sampling soft- and hardware

this looks like its a textureing issue only - the geometry looks the  
same - maybe xfade hasnt changed, but the texture coordinates being  
output by the matrixoutput 1 from the object you are using?

it use a jit.print and see what you find - id do it, but I dont have  
1.5 on my intel system :)

> Ah, appears it also happens with xfade > 1. Screenshot attached.
>
> Mattijs
> --
> SmadSteck - http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>
>

i once thought matrixoutput outputs only vertex geometry. good to know.

i once thought matrixoutput outputs only vertex geometry. good to know.
 ill just move along now.

On 12/20/06, Mattijs Kneppers  wrote:
>
> Ah, appears it also happens with xfade > 1. Screenshot attached.
>
> Mattijs
> --
> SmadSteck - http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>
>
>
>
>
>
>

There's nothing wrong with jit.xfade. There has been a change from

1.5 to 1.6 in how texture coordinates for planar forms are generated.

This was done to make things consistent with displaying video properly

when some bug fixes were made to jit.gl.texture. If you lookat plane

3 of the matrixoutput from the gridshapes, you will see a different

between the sphere and plane. When they are xfaded together, the

texcoords extrapolate and go negative, creating the clamp to border

effect you see. If you want it to look the same as before, simply use

the same texture coordinates for both gridshape matrixoutputs. In

other words, one of them has to have its data replaced with the

Alternatively, you could generate the same forms with jit.expr and use

jit.gl.mesh to render everything like in this patch:

There's nothing wrong with jit.xfade.  There has been a change from
1.5 to 1.6 in how texture coordinates for planar forms are generated.
This was done to make things consistent with displaying video properly
when some bug fixes were made to jit.gl.texture.  If you lookat plane
3 of the matrixoutput from the gridshapes, you will see a different
between the sphere and plane.  When they are xfaded together, the
texcoords extrapolate and go negative, creating the clamp to border
effect you see.  If you want it to look the same as before, simply use
the same texture coordinates for both gridshape matrixoutputs.  In
other words, one of them has to have its data replaced with the
other's for planes 3 and 4.

Alternatively, you could generate the same forms with jit.expr and use
jit.gl.mesh to render everything like in this patch:

Quote: wesley.hoke@gmail.com wrote on Thu, 21 December 2006 23:54

----------------------------------------------------

> There's nothing wrong with jit.xfade. There has been a change from

> 1.5 to 1.6 in how texture coordinates for planar forms are generated.

> This was done to make things consistent with displaying video properly

> when some bug fixes were made to jit.gl.texture. If you lookat plane

> 3 of the matrixoutput from the gridshapes, you will see a different

> between the sphere and plane. When they are xfaded together, the

> texcoords extrapolate and go negative, creating the clamp to border

> effect you see. If you want it to look the same as before, simply use

> the same texture coordinates for both gridshape matrixoutputs. In

> other words, one of them has to have its data replaced with the

Ah, thanks a lot wesley, both for the explanation and the alternative. Seems the latter allows for a lot of funky jamming, I will have to have a closer look at the possibilities of jit.expr in combination jit.gl.mesh.

To be complete here is the patch with wes' first solution implemented:

Quote: wesley.hoke@gmail.com wrote on Thu, 21 December 2006 23:54
----------------------------------------------------
> There's nothing wrong with jit.xfade.  There has been a change from
> 1.5 to 1.6 in how texture coordinates for planar forms are generated.
> This was done to make things consistent with displaying video properly
> when some bug fixes were made to jit.gl.texture.  If you lookat plane
> 3 of the matrixoutput from the gridshapes, you will see a different
> between the sphere and plane.  When they are xfaded together, the
> texcoords extrapolate and go negative, creating the clamp to border
> effect you see.  If you want it to look the same as before, simply use
> the same texture coordinates for both gridshape matrixoutputs.  In
> other words, one of them has to have its data replaced with the
> other's for planes 3 and 4.

jit.xfade behaves differently in jitter 1.6.3b (bug?)