Mattijs

I can't seem to cross an invisible barrier when I try to work with texture-readbacks and multiple render contexts. This time it's a crash when re-instantiating the window that I am capturing from. Steps to reproduce are in the patch below. I attached the crashreport.

Max 4.6.2, Jitter 1.6.3 b1, Quad G5 2.5GHz 4GB ram, 1xGeForce 7800GT, 1x GeForce 6600

Furthermore I would expect this patch to actually read a texture back and render it on a videoplane in a second render context but probably I'm missing something. If someone happens to see what that is, feel free to let me know ;)

bugreport-crash-when-re-instantiating-render-context-that-is-used-for-capture

I can't seemt to get ahold of your Draw subpatch. It's off my screen

completely and I can't get it back through tried and true methods.

Can you resend it with the subpatch in a more accessible location?

> I can't seem to cross an invisible barrier when I try to work with texture-readbacks and multiple render contexts. This time it's a crash when re-instantiating the window that I am capturing from. Steps to reproduce are in the patch below. I attached the crashreport.

> Max 4.6.2, Jitter 1.6.3 b1, Quad G5 2.5GHz 4GB ram, 1xGeForce 7800GT, 1x GeForce 6600

> Furthermore I would expect this patch to actually read a texture back and render it on a videoplane in a second render context but probably I'm missing something. If someone happens to see what that is, feel free to let me know ;)

> #P comment 335 65 196 196617 2) re-instantiate (type and remove space);

> #P newex 51 141 232 196617 jit.gl.videoplane out @texture tex1 @automatic 0;

> #P newex 164 85 147 196617 jit.window out @depthbuffer 1;

> #P newex 27 161 82 196617 jit.gl.render out;

> #P newex 215 266 127 196617 jit.gl.texture @name tex1;

> #P newex 164 64 169 196617 jit.window render2 @depthbuffer 1;

> #P newex 215 246 244 196617 jit.gl.render render2 @camera 0 0 3 @capture tex1;

> #P newex 67 302 175 196617 jit.gl.handle render1 @auto_rotate 1;

> #P message 369 120 81 196617 drawto render2;

> #P newex 258 73 128 196617 t b b updateclients b erase;

> #P message 161 120 81 196617 drawto render1;

> #P newex 50 73 128 196617 t b b updateclients b erase;

Hi Mattijs,
I can't seemt to get ahold of your Draw subpatch.  It's off my screen
completely and I can't get it back through tried and true methods.
Can you resend it with the subpatch in a more accessible location?

On 11/29/06, Mattijs Kneppers  wrote:
> Hi cycling and fans,
>
> I can't seem to cross an invisible barrier when I try to work with texture-readbacks and multiple render contexts. This time it's a crash when re-instantiating the window that I am capturing from. Steps to reproduce are in the patch below. I attached the crashreport.
>
> Max 4.6.2, Jitter 1.6.3 b1, Quad G5 2.5GHz 4GB ram, 1xGeForce 7800GT, 1x GeForce 6600
>
> Furthermore I would expect this patch to actually read a texture back and render it on a videoplane in a second render context but probably I'm missing something. If someone happens to see what that is, feel free to let me know ;)
>
> Regards,
> Mattijs
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P comment 335 65 196 196617 2) re-instantiate (type and remove space);
> #P newex 27 121 58 196617 t b b erase;
> #P newex 51 141 232 196617 jit.gl.videoplane out @texture tex1 @automatic 0;
> #P newex 27 82 30 196617 t b b;
> #P newex 164 85 147 196617 jit.window out @depthbuffer 1;
> #P newex 27 161 82 196617 jit.gl.render out;
> #P newex 215 266 127 196617 jit.gl.texture @name tex1;
> #P newex 164 64 169 196617 jit.window render2 @depthbuffer 1;
> #P newex 215 226 54 196617 r render2;
> #P newex 215 246 244 196617 jit.gl.render render2 @camera 0 0 3 @capture tex1;
> #P newex 67 302 175 196617 jit.gl.handle render1 @auto_rotate 1;
> #P newex 22 227 54 196617 r render1;
> #P newex 23 302 41 196617 r draw;
> #N vpatcher -550 193 -64 401;
> #P window setfont "Sans Serif" 9.;
> #P newex 50 47 30 196617 t b b;
> #P newex 369 139 41 196617 s draw;
> #P message 369 120 81 196617 drawto render2;
> #P newex 258 73 128 196617 t b b updateclients b erase;
> #P newex 258 139 54 196617 s render2;
> #P newex 161 139 41 196617 s draw;
> #P message 161 120 81 196617 drawto render1;
> #P newex 50 73 128 196617 t b b updateclients b erase;
> #P inlet 50 30 15 0;
> #P newex 50 139 54 196617 s render1;
> #P connect 1 0 9 0;
> #P connect 9 0 2 0;
> #P connect 2 0 0 0;
> #P fasten 2 2 0 0 113 100 55 100;
> #P fasten 2 4 0 0 171 104 55 104;
> #P fasten 2 3 3 0 142 112 166 112;
> #P connect 3 0 4 0;
> #P connect 2 1 4 0;
> #P connect 9 1 6 0;
> #P connect 6 0 5 0;
> #P fasten 6 2 5 0 321 100 263 100;
> #P fasten 6 4 5 0 379 104 263 104;
> #P fasten 6 3 7 0 350 112 374 112;
> #P connect 6 1 8 0;
> #P connect 7 0 8 0;
> #P pop;
> #P newobj 47 102 42 196617 p Draw;
> #P window linecount 2;
> #P newex 23 325 289 196617 jit.gl.gridshape @shape torus @color 1 0 0 1 @lighting_enable 1 @blend_enable 1 @smooth_shading 1 @automatic 0;
> #P window linecount 1;
> #P newex 164 43 169 196617 jit.window render1 @depthbuffer 1;
> #P toggle 27 43 15 0;
> #P newex 27 62 57 196617 qmetro 30;
> #P newex 22 247 175 196617 jit.gl.render render1 @camera 0 0 3;
> #P comment 44 43 100 196617 1) turn on metro;
> #P connect 11 0 10 0;
> #P connect 18 1 17 0;
> #P connect 16 1 6 0;
> #P connect 18 0 14 0;
> #P connect 18 2 14 0;
> #P connect 16 0 18 0;
> #P connect 2 0 16 0;
> #P connect 3 0 2 0;
> #P connect 7 0 5 0;
> #P connect 9 0 5 0;
> #P connect 8 0 1 0;
> #P window clipboard copycount 20;
>
> --
> SmadSteck - http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>
>
>
>
>
>
>


On 29 nov. 06, at 17:56, Wesley Smith wrote:

> I can't seemt to get ahold of your Draw subpatch. It's off my screen

> completely and I can't get it back through tried and true methods.

> Can you resend it with the subpatch in a more accessible location?

Did you try choosing the "Draw" subpatcher in the window menu while 

By the way, I can reproduce the crash here (PPC 1.67, Max 4.6.2, 

> Hi Mattijs,
> I can't seemt to get ahold of your Draw subpatch.  It's off my screen
> completely and I can't get it back through tried and true methods.
> Can you resend it with the subpatch in a more accessible location?

Did you try choosing the "Draw" subpatcher in the window menu while  
pressing on the alt key?

By the way, I can reproduce the crash here (PPC 1.67, Max 4.6.2,  
Jitter 1.6.3b1).

> On 29 nov. 06, at 17:56, Wesley Smith wrote:

> > I can't seemt to get ahold of your Draw subpatch. It's off my screen

> > completely and I can't get it back through tried and true methods.

> > Can you resend it with the subpatch in a more accessible location?

> Did you try choosing the "Draw" subpatcher in the window menu while

> By the way, I can reproduce the crash here (PPC 1.67, Max 4.6.2,

On 11/29/06, Emmanuel Jourdan  wrote:
> On 29 nov. 06, at 17:56, Wesley Smith wrote:
>
> > Hi Mattijs,
> > I can't seemt to get ahold of your Draw subpatch.  It's off my screen
> > completely and I can't get it back through tried and true methods.
> > Can you resend it with the subpatch in a more accessible location?
>
> Wesley,
>
> Did you try choosing the "Draw" subpatcher in the window menu while
> pressing on the alt key?
>

No.  I didn't know about that trick.
thanks,
wes

> By the way, I can reproduce the crash here (PPC 1.67, Max 4.6.2,
> Jitter 1.6.3b1).
>
> Best,
> ej
>
>
>


I can reproduce as well. I can't say when this will get fixed, so

perhaps if you can describe what you're trying to do, I can suggest an

> > On 29 nov. 06, at 17:56, Wesley Smith wrote:

> > > I can't seemt to get ahold of your Draw subpatch. It's off my screen

> > > completely and I can't get it back through tried and true methods.

> > > Can you resend it with the subpatch in a more accessible location?

> > Did you try choosing the "Draw" subpatcher in the window menu while

> > By the way, I can reproduce the crash here (PPC 1.67, Max 4.6.2,

I can reproduce as well.  I can't say when this will get fixed, so
perhaps if you can describe what you're trying to do, I can suggest an
alternative non-crashing method.

On 11/29/06, Wesley Smith  wrote:
> On 11/29/06, Emmanuel Jourdan  wrote:
> > On 29 nov. 06, at 17:56, Wesley Smith wrote:
> >
> > > Hi Mattijs,
> > > I can't seemt to get ahold of your Draw subpatch.  It's off my screen
> > > completely and I can't get it back through tried and true methods.
> > > Can you resend it with the subpatch in a more accessible location?
> >
> > Wesley,
> >
> > Did you try choosing the "Draw" subpatcher in the window menu while
> > pressing on the alt key?
> >
>
> No.  I didn't know about that trick.
> thanks,
> wes
>
> > By the way, I can reproduce the crash here (PPC 1.67, Max 4.6.2,
> > Jitter 1.6.3b1).
> >
> > Best,
> > ej
> >
> >
> >
>


Quote: wesley.hoke@gmail.com wrote on Wed, 29 November 2006 18:55

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

> I can reproduce as well. I can't say when this will get fixed, so

> perhaps if you can describe what you're trying to do, I can suggest an

Sorry for the off-screen window; Emmanuel: great! I've had so much trouble with this.. :D

To wesley: I don't specifically need to use this functionality in a system but it consumes a lot of time while I'm programming.

It is a real problem that max crashes a lot as soon as I start working with texture readbacks and multiple render targets and other newly added features. I laid my finger on this one (still took me an hour or so to actually isolate the problem and formulate the bugreport properly, not mentioning the time I lost earlier together with a high-profile programmer that we hired to develop this DOF shader for us), but there are more bugs/crashes that I really don't think I have time to document properly one by one. In a way, sometimes I believe I might be taking max too seriously..

Nonetheless much thanks for reacting so quickly. I hope this bug will be squashed soon.

In the mean time there is a question you might be able to answer relatively easily (looking to your own experience in this field): could you have a look at the patch; is this a correct way to render to multiple targets, capture one of them and render that on a videoplane to a third target?

Below is the patch with a correctly placed Draw patcher.

Quote: wesley.hoke@gmail.com wrote on Wed, 29 November 2006 18:55
----------------------------------------------------
> I can reproduce as well.  I can't say when this will get fixed, so
> perhaps if you can describe what you're trying to do, I can suggest an
> alternative non-crashing method.
>
> wes

Ive also had issues when trying to edit patches that have a lot of 

render to texture, or @capture attributes. My solution is simply to 

quit max and start it up again when things go wonky. Ive never been 

able to pinpoint it, but it certain is a drag when working on large 

With regard to what you want to do, you might be best off using a 

jit.gl.sketch object with @capture, and then use the drawobject 

command to have sketch draw a set of OB3D elements and render them to 

a texture. With @automatic 0 and no incoming bangs to your assets for 

the various 'scenes', they will only be rendered when jit.gl.sketch 

its nice, and you can re-use elements this way as well.

Not certain if that will help, but it beats managing a bunch of 

On Nov 29, 2006, at 1:46 PM, Mattijs Kneppers wrote:

> Quote: wesley.hoke@gmail.com wrote on Wed, 29 November 2006 18:55

> ----------------------------------------------------

>> I can reproduce as well. I can't say when this will get fixed, so

>> perhaps if you can describe what you're trying to do, I can 

> Sorry for the off-screen window; Emmanuel: great! I've had so much 

> To wesley: I don't specifically need to use this functionality in a 

> system but it consumes a lot of time while I'm programming.

> It is a real problem that max crashes a lot as soon as I start 

> working with texture readbacks and multiple render targets and 

> other newly added features. I laid my finger on this one (still 

> took me an hour or so to actually isolate the problem and formulate 

> the bugreport properly, not mentioning the time I lost earlier 

> together with a high-profile programmer that we hired to develop 

> this DOF shader for us), but there are more bugs/crashes that I 

> really don't think I have time to document properly one by one. In 

> a way, sometimes I believe I might be taking max too seriously..

> Nonetheless much thanks for reacting so quickly. I hope this bug 

> In the mean time there is a question you might be able to answer 

> relatively easily (looking to your own experience in this field): 

> could you have a look at the patch; is this a correct way to render 

> to multiple targets, capture one of them and render that on a 

> Below is the patch with a correctly placed Draw patcher.

> #P comment 323 59 196 9109513 2) re-instantiate (type and remove 

> #P newex 15 124 58 9109513 t b b erase;

> #P newex 39 144 232 9109513 jit.gl.videoplane out @texture tex1 

Ive also had issues when trying to edit patches that have a lot of  
render to texture, or @capture attributes. My solution is simply to  
quit max and start it up again when things go wonky. Ive never been  
able to pinpoint it, but it certain is a drag when working on large  
patches.

With regard to what you want to do, you might be best off using a  
jit.gl.sketch object with @capture, and then use the drawobject  
command to have sketch draw a set of OB3D elements and render them to  
a texture. With @automatic 0 and no incoming bangs to your assets for  
the various 'scenes', they will only be rendered when jit.gl.sketch  
has them in its command list.

Not certain if that will help, but it beats managing a bunch of  
render contexts... (imo )

>
> Quote: wesley.hoke@gmail.com wrote on Wed, 29 November 2006 18:55
> ----------------------------------------------------
>> I can reproduce as well.  I can't say when this will get fixed, so
>> perhaps if you can describe what you're trying to do, I can  
>> suggest an
>> alternative non-crashing method.
>>
>> wes
>
> Hi wes,
>
> Sorry for the off-screen window; Emmanuel: great! I've had so much  
> trouble with this.. :D
>
> To wesley: I don't specifically need to use this functionality in a  
> system but it consumes a lot of time while I'm programming.
>
> It is a real problem that max crashes a lot as soon as I start  
> working with texture readbacks and multiple render targets and  
> other newly added features. I laid my finger on this one (still  
> took me an hour or so to actually isolate the problem and formulate  
> the bugreport properly, not mentioning the time I lost earlier  
> together with a high-profile programmer that we hired to develop  
> this DOF shader for us), but there are more bugs/crashes that I  
> really don't think I have time to document properly one by one. In  
> a way, sometimes I believe I might be taking max too seriously..
>
> Nonetheless much thanks for reacting so quickly. I hope this bug  
> will be squashed soon.
>
> In the mean time there is a question you might be able to answer  
> relatively easily (looking to your own experience in this field):  
> could you have a look at the patch; is this a correct way to render  
> to multiple targets, capture one of them and render that on a  
> videoplane to a third target?
>
> Below is the patch with a correctly placed Draw patcher.
>
> Thanks again,
> Mattijs
>
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P comment 323 59 196 9109513 2) re-instantiate (type and remove  
> space);
> #P newex 15 124 58 9109513 t b b erase;
> #P newex 39 144 232 9109513 jit.gl.videoplane out @texture tex1  
> @automatic 0;
> #P newex 15 76 30 9109513 t b b;
> #P newex 152 79 147 9109513 jit.window out @depthbuffer 1;
> #P newex 15 164 82 9109513 jit.gl.render out;
> #P newex 203 260 127 9109513 jit.gl.texture @name tex1;
> #P newex 152 58 169 9109513 jit.window render2 @depthbuffer 1;
> #P newex 203 220 54 9109513 r render2;
> #P newex 203 240 244 9109513 jit.gl.render render2 @camera 0 0 3  
> @capture tex1;
> #P newex 55 296 175 9109513 jit.gl.handle render1 @auto_rotate 1;
> #P newex 10 221 54 9109513 r render1;
> #P newex 11 296 41 9109513 r draw;
> #N vpatcher 31 486 517 694;
> #P window setfont "Sans Serif" 9.;
> #P newex 50 47 30 9109513 t b b;
> #P newex 369 139 41 9109513 s draw;
> #P message 369 120 81 9109513 drawto render2;
> #P newex 258 73 128 9109513 t b b updateclients b erase;
> #P newex 258 139 54 9109513 s render2;
> #P newex 161 139 41 9109513 s draw;
> #P message 161 120 81 9109513 drawto render1;
> #P newex 50 73 128 9109513 t b b updateclients b erase;
> #P inlet 50 30 15 0;
> #P newex 50 139 54 9109513 s render1;
> #P connect 1 0 9 0;
> #P connect 9 0 2 0;
> #P fasten 2 4 0 0 171 104 55 104;
> #P fasten 2 2 0 0 113 100 55 100;
> #P connect 2 0 0 0;
> #P fasten 2 3 3 0 142 112 166 112;
> #P connect 2 1 4 0;
> #P connect 3 0 4 0;
> #P connect 9 1 6 0;
> #P fasten 6 4 5 0 379 104 263 104;
> #P fasten 6 2 5 0 321 100 263 100;
> #P connect 6 0 5 0;
> #P fasten 6 3 7 0 350 112 374 112;
> #P connect 7 0 8 0;
> #P connect 6 1 8 0;
> #P pop;
> #P newobj 35 96 42 9109513 p Draw;
> #P window linecount 2;
> #P newex 11 319 289 9109513 jit.gl.gridshape @shape torus @color 1  
> 0 0 1 @lighting_enable 1 @blend_enable 1 @smooth_shading 1  
> @automatic 0;
> #P window linecount 1;
> #P newex 152 37 169 9109513 jit.window render1 @depthbuffer 1;
> #P toggle 15 37 15 0;
> #P newex 15 56 57 9109513 qmetro 30;
> #P newex 10 241 175 9109513 jit.gl.render render1 @camera 0 0 3;
> #P comment 32 37 100 9109513 1) turn on metro;
> #P connect 8 0 1 0;
> #P connect 9 0 5 0;
> #P connect 7 0 5 0;
> #P connect 3 0 2 0;
> #P connect 2 0 16 0;
> #P connect 16 0 18 0;
> #P connect 18 2 14 0;
> #P connect 18 0 14 0;
> #P connect 16 1 6 0;
> #P connect 18 1 17 0;
> #P connect 11 0 10 0;
> #P window clipboard copycount 20;
>
> --
> SmadSteck - http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>


I understand your frustrations with RTT stuff. I've been struggling

with it alot myself. Maybe it's time to post an article on best

practice for RTT. There are many ways to do it, but there are some

that are much less crash prone than others. My current method uses

jit.gl.sketch @capture texture to draw name ob3d objects to a texture.

This is the most robust way to do it in Jitter AFAIK and is also very

flexible since you can set opengl state through sketch commands in

addition to drawing the object. I've modified your patch to do this

and render the red torus to all 3 contexts with the "out" context

Hi Mattijs,
I understand your frustrations with RTT stuff.  I've been struggling
with it alot myself.  Maybe it's time to post an article on best
practice for RTT.  There are many ways to do it, but there are some
that are much less crash prone than others.  My current method uses
jit.gl.sketch @capture texture to draw name ob3d objects to a texture.
 This is the most robust way to do it in Jitter AFAIK and is also very
flexible since you can set opengl state through sketch commands  in
addition to drawing the object.  I've modified your patch to do this
and render the red torus to all 3 contexts with the "out" context
displaying the RTT'd texture.

Wow, vade and wes, much thanks for these tips. It works :) I didn't know about the drawobject message. Is it documented somewhere? I can't find it.

An additional question (please tell me if I get boring); is there a way to force the render order of multiple objects when using jit.gl.sketch? We used to need this to render objects correctly with respect to alpha and depth but it looks like sketch does some sorting automatically. Is that true?

After experimenting a bit more with this setup I ran into 3 funny things (I tried to lay it out as clear as possible in the patch below as well):

1) the movie texture is only available in jit.gl.sketch if sent to target 'render1', although sketch itself has target 'render2'

2) in the 'real' renders I don't see transparency, in the output of sketch I do.

3) jit.gl.sketch doesn't accept the drawobject messages in loadbang time.

Wow, vade and wes, much thanks for these tips. It works :) I didn't know about the drawobject message. Is it documented somewhere? I can't find it. 

Quote: Mattijs wrote on Thu, 30 November 2006 13:04

> 3) jit.gl.sketch doesn't accept the drawobject messages in loadbang time.

Quote: Mattijs wrote on Thu, 30 November 2006 13:04
----------------------------------------------------
> 3) jit.gl.sketch doesn't accept the drawobject messages in loadbang time.

I havent looked at the patch, but one thing about the drawobject 

command is that it can inherit the opengl state attributes (such as 

@blend_enable 1, @depth_enable 1, etc) from the sketch object, or 

from the object itself. This is documented in a subpatcher in the 

help file called object commands, as well as in the html docs for 

if I have an object such as jit.gl.gridshape rendercontext @name grid 

@blend_enable 1 @depth_enable 1 @blend_mode 6 1 @lighting_enable 1 

and a jit.gl.sketch object : jit.gl.sketch rendercontext

if I send drawobject grid 1 to jit.gl.sketch, I loose depth, 

blending, lighting and smooth shading (ie, it inherits jit.gl.sketchs 

ob3d attribute state of things being off, well, except for whatever 

if I send drawobject grid 0 to jit.gl.sketch I have the attributes 

ive specified for the grid object active, even through jit.gl.sketch 

does not have them. my output texture if I use @capture should 

On Nov 30, 2006, at 7:04 AM, Mattijs Kneppers wrote:

> Wow, vade and wes, much thanks for these tips. It works :) I didn't 

> know about the drawobject message. Is it documented somewhere? I 

> An additional question (please tell me if I get boring); is there a 

> way to force the render order of multiple objects when using 

> jit.gl.sketch? We used to need this to render objects correctly 

> with respect to alpha and depth but it looks like sketch does some 

> After experimenting a bit more with this setup I ran into 3 funny 

> things (I tried to lay it out as clear as possible in the patch 

> 1) the movie texture is only available in jit.gl.sketch if sent to 

> target 'render1', although sketch itself has target 'render2'

> 2) in the 'real' renders I don't see transparency, in the output of 

> 3) jit.gl.sketch doesn't accept the drawobject messages in loadbang 

> Are these three easy to explain for you?

> #P message 459 173 59 196617 drawto out;

> #P message 459 156 81 196617 drawto render2;

> #P message 459 139 81 196617 drawto render1;

> #P user jit.pwindow 459 55 82 62 0 1 0 0 1 0;

> #P newex 395 120 172 196617 jit.gl.texture render1 @name movie;

> #P newex 395 99 63 196617 jit.qt.movie;

> #P message 91 142 207 196617 reset , drawobject red 0 , 

> #P newex 43 161 236 196617 jit.gl.sketch render2 @capture tex1 

> #P newex 16 343 359 196617 jit.gl.gridshape @shape cube @color 0 0 

> 1 0.5 @lighting_enable 1 @rotatexyz 0. 45. 45. @blend_enable 1 

I havent looked at the patch, but one thing about the drawobject  
command is that it can inherit the opengl state attributes (such as  
@blend_enable 1, @depth_enable 1, etc) from the sketch object, or  
from the object itself. This is documented in a subpatcher in the  
help file called object commands, as well as in the html docs for  
jit.gl.sketch.

if I have an object such as jit.gl.gridshape rendercontext @name grid  
@blend_enable 1 @depth_enable 1 @blend_mode 6 1 @lighting_enable 1  
@smooth_shading 1

if I send drawobject grid 1 to jit.gl.sketch, I loose depth,  
blending, lighting and smooth shading (ie, it inherits jit.gl.sketchs  
ob3d attribute state of things being off, well, except for whatever  
defaults to 'on' or '1')

if I send drawobject grid 0 to jit.gl.sketch I have the attributes  
ive specified for the grid object active, even through jit.gl.sketch  
does not have them. my output texture if I use @capture should  
reflect this.

>
> Wow, vade and wes, much thanks for these tips. It works :) I didn't  
> know about the drawobject message. Is it documented somewhere? I  
> can't find it.
>
> That's a very clear patch wes, thanks.
>
> An additional question (please tell me if I get boring); is there a  
> way to force the render order of multiple objects when using  
> jit.gl.sketch? We used to need this to render objects correctly  
> with respect to alpha and depth but it looks like sketch does some  
> sorting automatically. Is that true?
>
> After experimenting a bit more with this setup I ran into 3 funny  
> things (I tried to lay it out as clear as possible in the patch  
> below as well):
>
> 1) the movie texture is only available in jit.gl.sketch if sent to  
> target 'render1', although sketch itself has target 'render2'
>
> 2) in the 'real' renders I don't see transparency, in the output of  
> sketch I do.
>
> 3) jit.gl.sketch doesn't accept the drawobject messages in loadbang  
> time.
>
> Are these three easy to explain for you?
>
> Thanks,
> Mattijs
>
>
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P message 459 173 59 196617 drawto out;
> #P message 459 156 81 196617 drawto render2;
> #P message 459 139 81 196617 drawto render1;
> #P newex 91 121 48 196617 loadbang;
> #P user jit.pwindow 459 55 82 62 0 1 0 0 1 0;
> #P newex 395 120 172 196617 jit.gl.texture render1 @name movie;
> #P message 395 74 30 196617 read;
> #P newex 395 99 63 196617 jit.qt.movie;
> #P message 91 142 207 196617 reset , drawobject red 0 ,  
> drawobject blue 0;
> #P newex 43 161 236 196617 jit.gl.sketch render2 @capture tex1  
> @automatic 0;
> #P newex 6 282 41 196617 r draw;
> #P window linecount 2;
> #P newex 16 343 359 196617 jit.gl.gridshape @shape cube @color 0 0  
> 1 0.5 @lighting_enable 1 @rotatexyz 0. 45. 45. @blend_enable 1  
> @smooth_shading 1 @automatic 0 @name blue;
> #P window linecount 1;
> #P newex 7 119 66 196617 t b b b erase;
> #P newex 25 181 314 196617 jit.gl.videoplane out @texture tex1  
> @automatic 0 @scale 1.25 1. 1.;
> #P newex 7 71 40 196617 t b b b;
> #P newex 108 67 209 196617 jit.window out @depthbuffer 1 @pos 20 605;
> #P newex 7 203 82 196617 jit.gl.render out;
> #P newex 281 161 144 196617 jit.gl.texture out @name tex1;
> #P newex 108 46 231 196617 jit.window render2 @depthbuffer 1 @pos  
> 20 340;
> #P newex 285 239 54 196617 r render2;
> #P newex 285 259 273 196617 jit.gl.render render2 @camera 0 0 5  
> @shared_context out;
> #P newex 70 287 175 196617 jit.gl.handle render1 @auto_rotate 1;
> #P newex 7 239 54 196617 r render1;
> #N vpatcher 444 709 930 917;
> #P window setfont "Sans Serif" 9.;
> #P newex 50 47 30 196617 t b b;
> #P newex 369 139 41 196617 s draw;
> #P message 369 120 81 196617 drawto render2;
> #P newex 258 73 128 196617 t b b updateclients b erase;
> #P newex 258 139 54 196617 s render2;
> #P newex 161 139 41 196617 s draw;
> #P message 161 120 81 196617 drawto render1;
> #P newex 50 73 128 196617 t b b updateclients b erase;
> #P inlet 50 30 15 0;
> #P newex 50 139 54 196617 s render1;
> #P connect 1 0 9 0;
> #P connect 9 0 2 0;
> #P fasten 2 4 0 0 171 104 55 104;
> #P fasten 2 2 0 0 113 100 55 100;
> #P connect 2 0 0 0;
> #P fasten 2 3 3 0 142 116 166 116;
> #P connect 3 0 4 0;
> #P connect 2 1 4 0;
> #P connect 9 1 6 0;
> #P fasten 6 4 5 0 379 104 263 104;
> #P fasten 6 2 5 0 321 100 263 100;
> #P connect 6 0 5 0;
> #P fasten 6 3 7 0 350 116 374 116;
> #P connect 7 0 8 0;
> #P connect 6 1 8 0;
> #P pop;
> #P newobj 22 95 42 196617 p Draw;
> #P window linecount 2;
> #P newex 16 310 366 196617 jit.gl.gridshape @shape torus @color 1 1  
> 1 1 @lighting_enable 1 @blend_enable 1 @smooth_shading 1 @automatic  
> 0 @name red @texture movie;
> #P window linecount 1;
> #P newex 108 25 225 196617 jit.window render1 @depthbuffer 1 @pos  
> 20 70;
> #P toggle 7 32 15 0;
> #P newex 7 51 57 196617 qmetro 30;
> #P newex 7 259 273 196617 jit.gl.render render1 @camera 0 0 5  
> @shared_context out;
> #P connect 21 0 23 0;
> #P connect 21 0 24 0;
> #P connect 18 0 4 0;
> #P connect 18 0 17 0;
> #P connect 26 0 23 0;
> #P connect 27 0 23 0;
> #P connect 28 0 23 0;
> #P connect 22 0 21 0;
> #P fasten 14 2 21 0 42 93 400 93;
> #P connect 9 0 8 0;
> #P connect 25 0 20 0;
> #P connect 16 2 19 0;
> #P connect 20 0 19 0;
> #P connect 16 1 15 0;
> #P connect 14 1 5 0;
> #P connect 7 0 4 0;
> #P connect 6 0 0 0;
> #P connect 16 0 12 0;
> #P fasten 16 3 12 0 66 200 12 200;
> #P connect 14 0 16 0;
> #P connect 1 0 14 0;
> #P connect 2 0 1 0;
> #P window clipboard copycount 29;
>
> --
> SmadSteck - http://www.smadsteck.nl
> Interactive audiovisual sampling soft- and hardware
>


> Wow, vade and wes, much thanks for these tips. It works :) I didn't know about the drawobject message. Is it documented somewhere? I can't find it.

> An additional question (please tell me if I get boring); is there a way to force the render order of multiple objects when using jit.gl.sketch? We used to need this to render objects correctly with respect to alpha and depth but it looks like sketch does some sorting automatically. Is that true?

You need glEnable(GL_BLEND) set either via jit.gl.sketch @blend_enable

1 or before the drawobject message in your command list doing

"glenable blend". This is in fact documented under the

object_commands subpatch in jit.gl.sketch.help.

> After experimenting a bit more with this setup I ran into 3 funny things (I tried to lay it out as clear as possible in the patch below as well):

> 1) the movie texture is only available in jit.gl.sketch if sent to target 'render1', although sketch itself has target 'render2'

It seems there's a limitation in the OS that only 1 context can be

shared with another context. If I share render2 with render1 and

render1 with out then I can see the texture in all 3 contexts.

> 2) in the 'real' renders I don't see transparency, in the output of sketch I do.

So this part was a bit of a hack using jit.gl.sketch to get things to

On 11/30/06, Mattijs Kneppers  wrote:
>
> Wow, vade and wes, much thanks for these tips. It works :) I didn't know about the drawobject message. Is it documented somewhere? I can't find it.
>
> That's a very clear patch wes, thanks.
>
> An additional question (please tell me if I get boring); is there a way to force the render order of multiple objects when using jit.gl.sketch? We used to need this to render objects correctly with respect to alpha and depth but it looks like sketch does some sorting automatically. Is that true?
>

You need glEnable(GL_BLEND) set either via jit.gl.sketch @blend_enable
1 or before the drawobject message in your command list doing
"glenable blend".  This is in fact documented under the
object_commands subpatch in jit.gl.sketch.help.

> After experimenting a bit more with this setup I ran into 3 funny things (I tried to lay it out as clear as possible in the patch below as well):
>
> 1) the movie texture is only available in jit.gl.sketch if sent to target 'render1', although sketch itself has target 'render2'
>

It seems there's a limitation in the OS that only 1 context can be
shared with another context.  If I share render2 with render1 and
render1 with out then I can see the texture in all 3 contexts.

> 2) in the 'real' renders I don't see transparency, in the output of sketch I do.
>
So this part was a bit of a hack using jit.gl.sketch to get things to
look right.

This is indeed helpful. I didn't think of looking inside the object commands subpatch in jit.gl.sketch help; Thanks, vade.

Wes, I tried your patch and it explains my blending question nicely.

But it looks like something goes entirely wrong with texture sharing. I attached 2 screenshots of what your patch looks like here (wesley patch 1 & 2). When I changed shared_context back to out for all renders and rendered the movie texture to out as well, it seemed to work.. but after a while it didn't work anymore! I attached 2 screenshots of that one as well (mattijs patch 1 & 2). I am quite sure there is still a bug in the texture sharing part in jitter or maybe somewhere else.

Trying to isolate the problem I now have 2 patches (test1 & test2) that are identical but show a different result. Very interesting. I attached the whole thing in a zip for your convenience.

But it looks like something goes entirely wrong with texture sharing. I attached 2 screenshots of what your patch looks like here (wesley patch 1 & 2). When I changed shared_context back to out for all renders and rendered the movie texture to out as well, it seemed to work.. but after a while it didn't work anymore! I attached 2 screenshots of that one as well (mattijs patch 1 & 2). I am quite sure there is still a bug in the texture sharing part in jitter or maybe somewhere else. 

bugreport: crash when re-instantiating render context that is used for capture