Mattijs

Please have a look at this simple example patch. It uses an uzi to update 3 texture objects with 1 jit.qt.movie. Expected behaviour is that every plane gets textured with a different movie frame.

http://avdl1064.oli.tudelft.nl/movie123.mov

Perhaps the texture object stores a matrix reference and the actual matrix is retrieved only at rendertime?

This is on a dual G5, Mac OS 10.4.7, Max 4.5.6, Jitter 1.5.2

To test this properly I use this movie:
http://avdl1064.oli.tudelft.nl/movie123.mov

rapid-texture-update-fails

I took a look at your patch and cleaned it up a bit. Everything seems

Hello Mattijs,
I took a look at your patch and cleaned it up a bit.  Everything seems
to work fine here.  Below is the patch.

Hi wesley, thanks for your reply, your version is indeed a solution to this problem.

Could it be that the matrix objects you appended to the jit.gl.texture force the texture objects (or the movie object) to assign unique matrix id's to the textures? I assume that's the reason that the render now recognizes them as different images.

Below I made another version that describes the issue wesley's way. This is unintended behaviour, right?

You know, this shouldn't be an issue the way you're doing it and I

didn't mean to inadvertently solve the problem with those trailing

matrix objects. Here's a good and efficient solution.

You know, this shouldn't be an issue the way you're doing it and I
didn't mean to inadvertently solve the problem with those trailing
matrix objects.  Here's a good and efficient solution.

I've run up against this issue before. I believe that it is 

intended, but a subtle side-effect of sending the matrix name via the 

jitter patch cords, instead of actual matrix data. I think that this 

small change fixes it - I change the out_name of the jit.qt.movie 

On Jul 26, 2006, at 4:28 PM, Mattijs Kneppers wrote:

> Hi wesley, thanks for your reply, your version is indeed a solution 

> Could it be that the matrix objects you appended to the 

> jit.gl.texture force the texture objects (or the movie object) to 

> assign unique matrix id's to the textures? I assume that's the 

> reason that the render now recognizes them as different images.

> Below I made another version that describes the issue wesley's way. 

> #P message 623 113 77 196617 frame_true $1;

> #P newex 659 322 252 196617 jit.gl.texture MyOutput @name tex3 

> #P newex 571 293 252 196617 jit.gl.texture MyOutput @name tex2 

> #P newex 482 264 252 196617 jit.gl.texture MyOutput @name tex1 

> #P user jit.pwindow 658 199 82 62 0 1 0 0 1 0;

> #P user jit.pwindow 570 199 82 62 0 1 0 0 1 0;

> #P user jit.pwindow 481 199 82 62 0 1 0 0 1 0;

> #P newex 22 272 333 196617 jit.gl.gridshape MyOutput @matrixoutput 

> 0 @shape plane @blend_enable 0 @depth_enable 1 @automatic 1 

> #P newex 22 236 333 196617 jit.gl.gridshape MyOutput @matrixoutput 

> #P newex 22 201 333 196617 jit.gl.gridshape MyOutput @matrixoutput 

I've run up against this issue before.  I believe that it is  
intended, but a subtle side-effect of sending the matrix name via the  
jitter patch cords, instead of actual matrix data.  I think that this  
small change fixes it - I change the out_name of the jit.qt.movie  
each time it outputs a frame, like so:

>
> Hi wesley, thanks for your reply, your version is indeed a solution  
> to this problem.
>
> Could it be that the matrix objects you appended to the  
> jit.gl.texture force the texture objects (or the movie object) to  
> assign unique matrix id's to the textures? I assume that's the  
> reason that the render now recognizes them as different images.
>
> Below I made another version that describes the issue wesley's way.  
> This is unintended behaviour, right?
>
> Mattijs
>
> #P toggle 446 314 15 0;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 552 314 29 196617 gate;
> #P newex 463 314 29 196617 gate;
> #P newex 552 333 55 196617 jit.matrix;
> #P newex 463 333 55 196617 jit.matrix;
> #P button 22 36 15 1;
> #P comment 22 22 21 196617 0);
> #P newex 589 73 27 196617 t b i;
> #P newex 22 56 60 196617 loadmess 1;
> #P newex 606 93 27 196617 t i i;
> #P message 623 113 77 196617 frame_true $1;
> #P newex 659 322 252 196617 jit.gl.texture MyOutput @name tex3  
> @matrixoutput 1;
> #P newex 571 293 252 196617 jit.gl.texture MyOutput @name tex2  
> @matrixoutput 1;
> #P newex 482 264 252 196617 jit.gl.texture MyOutput @name tex1  
> @matrixoutput 1;
> #P user jit.pwindow 658 199 82 62 0 1 0 0 1 0;
> #P user jit.pwindow 570 199 82 62 0 1 0 0 1 0;
> #P user jit.pwindow 481 199 82 62 0 1 0 0 1 0;
> #P newex 22 117 50 196617 t b erase;
> #P window linecount 2;
> #P newex 22 272 333 196617 jit.gl.gridshape MyOutput @matrixoutput  
> 0 @shape plane @blend_enable 0 @depth_enable 1 @automatic 1  
> @texture tex3 @position 2 0 -1;
> #P newex 22 236 333 196617 jit.gl.gridshape MyOutput @matrixoutput  
> 0 @shape plane @blend_enable 0 @depth_enable 1 @automatic 1  
> @texture tex2 @position 0 0 -1;
> #P newex 22 201 333 196617 jit.gl.gridshape MyOutput @matrixoutput  
> 0 @shape plane @blend_enable 0 @depth_enable 1 @automatic 1  
> @texture tex1 @position -2 0 -1;
> #P toggle 22 78 15 0;
> #P window linecount 1;
> #P newex 22 98 57 196617 qmetro 40;
> #P window linecount 2;
> #P newex 22 164 243 196617 jit.window MyOutput @depthbuffer 1  
> @doublebuffer 1 @fsmenubar 0 @rect 0 50 720 338;
> #P window linecount 1;
> #P newex 22 141 111 196617 jit.gl.render MyOutput;
> #P newex 482 162 47 196617 gate 3 1;
> #P button 559 36 15 1;
> #P newex 559 53 40 196617 uzi 3;
> #P comment 559 22 284 196617 2) click the bang twice while watching  
> the output window;
> #P message 519 36 30 196617 read;
> #B color 1;
> #P newex 519 132 102 196617 jit.qt.movie @rate 0;
> #P comment 519 22 16 196617 1);
> #P window linecount 3;
> #P comment 374 314 70 196617 3) open the gate and repeat step 2;
> #P connect 32 0 30 0;
> #P connect 32 0 31 0;
> #P connect 20 0 31 1;
> #P connect 27 0 24 0;
> #P connect 24 0 11 0;
> #P connect 11 0 10 0;
> #P connect 10 0 15 0;
> #P connect 15 0 8 0;
> #P fasten 15 1 8 0 67 137 27 137;
> #P connect 30 0 28 0;
> #P fasten 23 0 7 0 611 159 487 159;
> #P fasten 7 0 16 0 487 189 487 189;
> #P connect 16 0 19 0;
> #P connect 19 0 30 1;
> #P connect 3 0 2 0;
> #P connect 5 0 2 0;
> #P connect 22 0 2 0;
> #P connect 2 0 7 1;
> #P connect 31 0 29 0;
> #P connect 6 0 5 0;
> #P fasten 7 1 17 0 505 192 576 192;
> #P connect 17 0 20 0;
> #P connect 5 2 25 0;
> #P connect 25 1 23 0;
> #P connect 23 1 22 0;
> #P fasten 7 2 18 0 523 185 664 185;
> #P connect 18 0 21 0;
> #P window clipboard copycount 33;
>


Hi wes, for me the problem was solved with your first post which confirmed that the matrix id was the actual issue.

I am no longer looking for a solution for my own patch but for 'the common good' ;), I still believe that this could be implemented in a better way. Perhaps the texture object should have the matrix behaviour added, in other words jit.gl.texture could make a copy of the texture data as soon as it is updated. Another option would be to add this behaviour as a warning to the help file of jit.gl.texture.

to lowfrequency.org - that is really a nice solution that doesn't use extra memory like the previous ideas. I can imagine that the drawback is that this out_name has to be unique. This could be a problem when you put the jit.qt.movie in an abstraction and use it multiple times. But there should be a workaround for that, I'll check it out.

Rapid texture update fails?