Wesley Smith

If you have Jitter 1.6, there are some new features that aren't

entirely obvious. One of them is shared contexts for texture memory

on the GPU in order to make an OpenGL preview window. If you're doing

a performance and the projection screen is behind or otherwise outside

of your field of vision, you can now make a fully hardware accelerated

copy of what's being projected in a preview window for yourself.

In Jitter 1.6, jit.gl.render has some new attributes, among them are

@copy_texture and @shared_context. @copy texture designates a named

texture to for jit.gl.render to copy each frame into and

@shared_context designates a second OpenGL context to share resources

with. Put these 2 attributes together and you have an OpenGL preview

window. This works with both jit.window and jit.pwindow. Obviously

this doesn't come without some kind of performance hit, but if your

resolution isn't massive, it should be tolerable. The patch is below.

If you have Jitter 1.6, there are some new features that aren't
entirely obvious.  One of them is shared contexts for texture memory
on the GPU in order to make an OpenGL preview window.  If you're doing
a performance and the projection screen is behind or otherwise outside
of your field of vision, you can now make a fully hardware accelerated
copy of what's being projected in a preview window for yourself.

In Jitter 1.6, jit.gl.render has some new attributes, among them are
@copy_texture and @shared_context.  @copy texture designates a named
texture to for jit.gl.render to copy each frame into and
@shared_context designates a second OpenGL context to share resources
with.  Put these 2 attributes together and you have an OpenGL preview
window.  This works with both jit.window and jit.pwindow.  Obviously
this doesn't come without some kind of performance hit, but if your
resolution isn't massive, it should be tolerable.  The patch is below.

sharing-is-fun-new-toys-opengl-preview

do you find this faster than the previous method of doing a preview window using texture readback? This is what I"m using now, and it works pretty well on my machine with a PCIe graphics card, even if my 2nd monitor is 1024x768, but AGP cards seem to suffer from this with a 1024x768 output.

I look forward to trying this in 1.6, esp when 1.6 is on XP.

do you find this faster than the previous method of doing a preview window using texture readback?  This is what I"m using now, and it works pretty well on my machine with a PCIe graphics card, even if my 2nd monitor is 1024x768, but AGP cards seem to suffer from this with a 1024x768 output.
I look forward to trying this in 1.6, esp when 1.6 is on XP.


I was using your exact method, and switched to the preview method Wes 

showed us. I dont notice any real speed difference, it just seems a 

little more elegant (the new method), as it gets the whole context, 

not just the texture (should you for example want to tint/color, 

change the geometry that the texture is being drawn on).

On Aug 15, 2006, at 2:11 PM, pnyboer wrote:

> do you find this faster than the previous method of doing a preview 

> window using texture readback? This is what I"m using now, and it 

> works pretty well on my machine with a PCIe graphics card, even if 

> my 2nd monitor is 1024x768, but AGP cards seem to suffer from this 

> I look forward to trying this in 1.6, esp when 1.6 is on XP.

I was using your exact method, and switched to the preview method Wes  
showed us. I dont notice any real speed difference, it just seems a  
little more elegant (the new method), as it gets the whole context,  
not just the texture (should you for example want to tint/color,  
change the geometry that the texture is being drawn on).

>
> do you find this faster than the previous method of doing a preview  
> window using texture readback?  This is what I"m using now, and it  
> works pretty well on my machine with a PCIe graphics card, even if  
> my 2nd monitor is 1024x768, but AGP cards seem to suffer from this  
> with a 1024x768 output.
> I look forward to trying this in 1.6, esp when 1.6 is on XP.
> --
> |||||||||||||||||||||||||||||||
> Brown Cocktail
> 3/4 oz light rum
> 3/4 oz gin
> 3/4 oz dry vermouth
> Shake with ice and serve
> in chilled cocktail glass
> |||||||||||||||||||||||||||||||

good to know....i am hoping the elegance is increased by not having to create a separate jit.gl.texture object for each possible res of the 2nd monitor for the readback (currently, I have 3: 1024, 800, and 640, and have to do a res-detect before readback) becuase you can't change the dim of the texture dynamically for this.

This was fixed as well in 1.6. If your jit.gl.texture object is given 

@adapt 1, it will automatically adapt to the context size when rendering 

Hey Peter,
This was fixed as well in 1.6.  If your jit.gl.texture object is given 
@adapt 1, it will automatically adapt to the context size when rendering 
to texture.

jitter 1.6 fixes this as well, with @adapt 1 for the texture 

destination dim as well. (iirc, ymmv, etc etc). So yeah, with 1.6, 

using texture preview, I only had one target texture and it worked 

fine with resizing. Wes was kind enough to show me the OGL preview at 

siggraph, and while I didnt see any speed difference, it just like a 

ive been using 1.6 for a while now, with my thesis codebase, and its 

really a nice update for most of these things, and surprisingly 

On Aug 15, 2006, at 3:02 PM, pnyboer wrote:

> good to know....i am hoping the elegance is increased by not having 

> to create a separate jit.gl.texture object for each possible res of 

> the 2nd monitor for the readback (currently, I have 3: 1024, 800, 

> and 640, and have to do a res-detect before readback) becuase you 

> can't change the dim of the texture dynamically for this.

jitter 1.6 fixes this as well, with @adapt 1 for the texture  
destination dim as well. (iirc, ymmv, etc etc). So yeah, with 1.6,  
using texture preview, I only had one target texture and it worked  
fine with resizing. Wes was kind enough to show me the OGL preview at  
siggraph, and while I didnt see any speed difference, it just like a  
better solution.

ive been using 1.6 for a while now, with my thesis codebase, and its  
really a nice update for most of these things, and surprisingly  
stable as well.

>
> good to know....i am hoping the elegance is increased by not having  
> to create a separate jit.gl.texture object for each possible res of  
> the 2nd monitor for the readback (currently, I have 3: 1024, 800,  
> and 640, and have to do a res-detect before readback) becuase you  
> can't change the dim of the texture dynamically for this.
> --
> |||||||||||||||||||||||||||||||
> Brown Cocktail
> 3/4 oz light rum
> 3/4 oz gin
> 3/4 oz dry vermouth
> Shake with ice and serve
> in chilled cocktail glass
> |||||||||||||||||||||||||||||||

This is one of the things I worked around in render_node, through 

dynamically creating new textures with JS. So there's a workaround 

if you want one. But I don't think it should be needed anymore-- 

some issues with texture resizing were fixed in 1.6.

On Aug 15, 2006, at 12:02 PM, pnyboer wrote:

This is one of the things I worked around in render_node, through  
dynamically creating new textures with JS.  So there's a workaround  
if you want one.  But I don't think it should be needed anymore--  
some issues with texture resizing were fixed in 1.6.

>
> good to know....i am hoping the elegance is increased by not having  
> to create a separate jit.gl.texture object for each possible res of  
> the 2nd monitor for the readback (currently, I have 3: 1024, 800,  
> and 640, and have to do a res-detect before readback) becuase you  
> can't change the dim of the texture dynamically for this.
> --
> |||||||||||||||||||||||||||||||
> Brown Cocktail
> 3/4 oz light rum
> 3/4 oz gin
> 3/4 oz dry vermouth
> Shake with ice and serve
> in chilled cocktail glass
> |||||||||||||||||||||||||||||||
>


Fantastic! I've been waiting for this for quite a while!

But I'm not sure I understand the behavior of the shared_context flag. It looks as though a named texture which is used with capture is available to all other render contexts by default (demonstrated in the patch below.) I like this behavior just fine since it allows a preview or output to be attached to any stage of a filter graph. And this seems more efficient since a copy isn't required. But is that how it's supposed to work?

jit.gl.render @shared_context will call the OS specific function for

sharing resources across OpenGL contexts. It works a bit differently

from OSX to windows. On OSX, the aglCreateContext (or something like

that) function can take an optional paraemter specifying a context

with which displaylists, textures, and the like are shared. On

Windows, the function is instead wglShareLists. On OSX, the texture

can be in any context that is shared and be accessible. On Windows,

things choke a bit if you share things and then recreate the main

context, so make sure the textures and such are in the main context.

Otherwise, your shared texture may become all white. This is not

really a limitation, just something to be aware of.

The reason your patch works is that these @capture textures are using

pbuffers which have their own context independent of the opengl

context, which is why they can naturally be shared between contexts.

Setting @shared_context gives a bit more flexibility in texture

sharing. THe patch below shows what I'm talking about. Incidentally,

in making this patch, a few issues have come up that need to be fixed.

It seems that there's an order of operations thing going on here that

needs to be addressed. In any case, texture sharing does work with

@shared_context, but at some point if it doesn't seem to be doing its

thing the right way, reinstantiate the texture and that should fix

> Fantastic! I've been waiting for this for quite a while!

> But I'm not sure I understand the behavior of the shared_context flag. It looks as though a named texture which is used with capture is available to all other render contexts by default (demonstrated in the patch below.) I like this behavior just fine since it allows a preview or output to be attached to any stage of a filter graph. And this seems more efficient since a copy isn't required. But is that how it's supposed to work?

> #P newex 108 95 189 196617 jit.gl.handle main @inherit_transform 1;

> #P newex 56 144 82 196617 jit.window main;

> #P newex 400 311 193 196617 jit.gl.videoplane prev_2 @texture watch;

> #P newex 400 289 101 196617 jit.gl.render prev_2;

> #P newex 400 332 94 196617 jit.window prev_2;

> #P newex 56 163 157 196617 jit.gl.texture main @name watch;

> #P newex 401 152 193 196617 jit.gl.videoplane prev_1 @texture watch;

> #P newex 401 130 101 196617 jit.gl.render prev_1;

> #P newex 401 173 94 196617 jit.window prev_1;

> #P newex 56 120 89 196617 jit.gl.render main;

> #P user umenu 48 259 100 196647 1 64 275 1;

> #P newex 48 281 82 196617 prepend capture;

> #P newex 48 304 248 196617 jit.gl.gridshape main @shape sphere @poly_mode 1 1;

jit.gl.render @shared_context will call the OS specific function for
sharing resources across OpenGL contexts.  It works a bit differently
from OSX to windows.  On OSX, the aglCreateContext (or something like
that) function can take an optional paraemter specifying a context
with which displaylists, textures, and the like are shared.  On
Windows, the function is instead wglShareLists.  On OSX, the texture
can be in any context that is shared and be accessible.  On Windows,
things choke a bit if you share things and then recreate the main
context, so make sure the textures and such are in the main context.
Otherwise, your shared texture may become all white.  This is not
really a limitation, just something to be aware of.

The reason your patch works is that these @capture textures are using
pbuffers which have their own context independent of the opengl
context, which is why they can naturally be shared between contexts.

Setting @shared_context gives a bit more flexibility in texture
sharing.  THe patch below shows what I'm talking about.  Incidentally,
in making this patch, a few issues have come up that need to be fixed.
 It seems that there's an order of operations thing going on here that
needs to be addressed.  In any case, texture sharing does work with
@shared_context, but at some point if it doesn't seem to be doing its
thing the right way, reinstantiate the texture and that should fix
things.

On 9/6/06, Paul Greyson  wrote:
>
> Fantastic! I've been waiting for this for quite a while!
>
> But I'm not sure I understand the behavior of the shared_context flag. It looks as though a named texture which is used with capture is available to all other render contexts by default (demonstrated in the patch below.) I like this behavior just fine since it allows a preview or output to be attached to any stage of a filter graph. And this seems more efficient since a copy isn't required. But is that how it's supposed to work?
>
> - Paul
>
> max v2;
> #N vpatcher 259 289 1047 692;
> #P window setfont "Sans Serif" 9.;
> #P window linecount 1;
> #P newex 108 95 189 196617 jit.gl.handle main @inherit_transform 1;
> #P newex 56 144 82 196617 jit.window main;
> #P newex 400 311 193 196617 jit.gl.videoplane prev_2 @texture watch;
> #P newex 400 203 48 196617 loadbang;
> #P toggle 400 224 15 0;
> #P newex 400 243 57 196617 qmetro 60;
> #P newex 400 264 50 196617 t b erase;
> #P newex 400 289 101 196617 jit.gl.render prev_2;
> #P newex 400 332 94 196617 jit.window prev_2;
> #P newex 56 163 157 196617 jit.gl.texture main @name watch;
> #P newex 401 152 193 196617 jit.gl.videoplane prev_1 @texture watch;
> #P newex 401 44 48 196617 loadbang;
> #P toggle 401 65 15 0;
> #P newex 401 84 57 196617 qmetro 60;
> #P newex 401 105 50 196617 t b erase;
> #P newex 401 130 101 196617 jit.gl.render prev_1;
> #P newex 401 173 94 196617 jit.window prev_1;
> #P newex 56 34 48 196617 loadbang;
> #P toggle 56 55 15 0;
> #P newex 56 74 57 196617 qmetro 33;
> #P newex 56 95 50 196617 t b erase;
> #P newex 56 120 89 196617 jit.gl.render main;
> #P user umenu 48 259 100 196647 1 64 275 1;
> #X add none;
> #X add watch;
> #P newex 48 281 82 196617 prepend capture;
> #P newex 48 304 248 196617 jit.gl.gridshape main @shape sphere @poly_mode 1 1;
> #P fasten 2 1 1 0 143 278 53 278;
> #P connect 1 0 0 0;
> #P connect 7 0 6 0;
> #P connect 6 0 5 0;
> #P connect 5 0 4 0;
> #P fasten 4 0 3 0 61 116 61 116;
> #P fasten 4 1 3 0 101 116 61 116;
> #P connect 24 0 3 0;
> #P connect 21 0 20 0;
> #P connect 20 0 19 0;
> #P connect 19 0 18 0;
> #P fasten 18 0 17 0 405 285 405 285;
> #P fasten 18 1 17 0 445 285 405 285;
> #P connect 13 0 12 0;
> #P connect 12 0 11 0;
> #P connect 11 0 10 0;
> #P fasten 10 1 9 0 446 126 406 126;
> #P fasten 10 0 9 0 406 126 406 126;
> #P pop;
>
>


So I guess the flexibility you're referring to is the ability to fill the texture using something other than capture/obj3d?

>>>
Setting @shared_context gives a bit more flexibility in texture
sharing.<<<
So I guess the flexibility you're referring to is the ability to fill the texture using something other than capture/obj3d?


Yes. Plus the ability to take the framebuffer at the end of rendering

and copy it to a texture for use in a different context of which a

> Setting @shared_context gives a bit more flexibility in texture

> So I guess the flexibility you're referring to is the ability to fill the texture using something other than capture/obj3d?

Yes.  Plus the ability to take the framebuffer at the end of rendering
and copy it to a texture for use in a different context of which a
preview window is on special case.

On 9/6/06, Paul Greyson  wrote:
>
> >>>
> Setting @shared_context gives a bit more flexibility in texture
> sharing.
><<<
> So I guess the flexibility you're referring to is the ability to fill the texture using something other than capture/obj3d?
>


Yes. Plus the ability to take the framebuffer at the end of rendering and copy it to a texture for use in a different context.<<<

Can't that also be done with capture? How is the capture pbuffer different than a texture that's copied from a render context?

>>>
Yes. Plus the ability to take the framebuffer at the end of rendering and copy it to a texture for use in a different context.<<<

Can't that also be done with capture? How is the capture pbuffer different than a texture that's copied from a render context?


If you capture <> to the pbuffer, it's no different. If

you don't want the hassle of doing this or can't afford a 1280x1024

> Yes. Plus the ability to take the framebuffer at the end of rendering and copy it to a texture for use in a different context.

> Can't that also be done with capture? How is the capture pbuffer different than a texture that's copied from a render context?

If you capture <> to the pbuffer, it's no different.  If
you don't want the hassle of doing this or can't afford a 1280x1024
size texture, then it's probably better.

On 9/6/06, Paul Greyson  wrote:
>
> >>>
> Yes. Plus the ability to take the framebuffer at the end of rendering and copy it to a texture for use in a different context.
><<<
>
> Can't that also be done with capture? How is the capture pbuffer different than a texture that's copied from a render context?
>


If you capture *everything* to the pbuffer, it's no different<<<

Sorry, I don't understand. It should be possible to have multiple obj3d's in the same render context each rendering to a different pbuffer, no? If that's the case, then it seems that anything that can be done with shared textures can also be done with capture/pbuffers (with the exception of the matrix->texture type stuff you mentioned.)

>>>
If you capture *everything* to the pbuffer, it's no different<<<
Sorry, I don't understand. It should be possible to have multiple obj3d's in the same render context each rendering to a different pbuffer, no? If that's the case, then it seems that anything that can be done with shared textures can also be done with capture/pbuffers (with the exception of the matrix->texture type stuff you mentioned.)


> Sorry, I don't understand. It should be possible to have multiple obj3d's in the same render context each rendering to a different pbuffer, no? If that's the case, then it seems that anything that can be done with shared textures can also be done with capture/pbuffers (with the exception of the matrix->texture type stuff you mentioned.)

Ok, here's the deal. Let's say I'm rendering a gridshape with alpha

0.5 and a mesh with alpha 0.5 and the mesh happens to cut through the

middle of the gridshape. If you render both things to different

pbuffers and then blen the textures together, it ain't gonna look

right as compared to just rendering everything normally. In addition,

if I have depth testing enabled, it also won't look right because some

parts of the mesh will be covered by the gridshape and vice-verse.

To capture what you would see in the framebuffer to a pbuffer, you

have to do something like jit.gl.render @capture tex_pbuff. This will

capture *everything*...meaning the gridshape and the mesh properly

> Sorry, I don't understand. It should be possible to have multiple obj3d's in the same render context each rendering to a different pbuffer, no? If that's the case, then it seems that anything that can be done with shared textures can also be done with capture/pbuffers (with the exception of the matrix->texture type stuff you mentioned.)
>

Ok, here's the deal.  Let's say I'm rendering a gridshape with alpha
0.5 and a mesh with alpha 0.5 and the mesh happens to cut through the
middle of the gridshape.  If you render both things to different
pbuffers and then blen the textures together, it ain't gonna look
right as compared to just rendering everything normally.  In addition,
if I have depth testing enabled, it also won't look right because some
parts of the mesh will be covered by the gridshape and vice-verse.

To capture what you would see in the framebuffer to a pbuffer, you
have to do something like jit.gl.render @capture tex_pbuff.  This will
capture *everything*...meaning the gridshape and the mesh properly
blended together.  Make sense?

One method I worked out, to allow multiple objects to be all captured 

together, but still allow for separate scenes, is to do this

Say you want to have 2 groups of objects, that you can crossfade and 

blend between, but which will render correctly when you are in 

'channel a' or channel b' ( ie: dont have the issues Wes' described)

set up all of your ob3Ds with automatic 0, @name , 

and DONT hook them up to anything. Nothing will render.

make a jit.gl.sketch @capture texture1 @automatic 0 and a 

jit.gl.sketch @capture texture2 @automatic 0

tell the jit.gl.sketch objects to [drawobject ] and your 

ob3D object will pop onto the texture that is capturing the sketch 

Do that for multiple objects, and you can control the scene. Throw in 

a few slabs, and a videoplane to texture on, and you are all set (as 

long as your render order for the sketches, and video plane is 

Ive got an example patch, but Im about to run off to work. Let me 

know if you want it. it works quite well.

On Sep 7, 2006, at 1:49 AM, Wesley Smith wrote:

>> Sorry, I don't understand. It should be possible to have multiple 

>> obj3d's in the same render context each rendering to a different 

>> pbuffer, no? If that's the case, then it seems that anything that 

>> can be done with shared textures can also be done with capture/ 

>> pbuffers (with the exception of the matrix->texture type stuff you 

> Ok, here's the deal. Let's say I'm rendering a gridshape with alpha

> 0.5 and a mesh with alpha 0.5 and the mesh happens to cut through the

> middle of the gridshape. If you render both things to different

> pbuffers and then blen the textures together, it ain't gonna look

> right as compared to just rendering everything normally. In addition,

> if I have depth testing enabled, it also won't look right because some

> parts of the mesh will be covered by the gridshape and vice-verse.

> To capture what you would see in the framebuffer to a pbuffer, you

> have to do something like jit.gl.render @capture tex_pbuff. This will

> capture *everything*...meaning the gridshape and the mesh properly

One method I worked out, to allow multiple objects to be all captured  
together, but still allow for separate scenes, is to do this

Say you want to have 2 groups of objects, that you can crossfade and  
blend between, but which will render correctly when you are in  
'channel a' or channel b' ( ie: dont have the issues Wes' described)

set up all of your ob3Ds with automatic 0, @name ,  
and DONT hook them up to anything. Nothing will render.

make a jit.gl.sketch @capture texture1 @automatic 0 and a  
jit.gl.sketch @capture texture2 @automatic 0

tell the jit.gl.sketch objects to [drawobject ] and your  
ob3D object will pop onto the texture that is capturing the sketch  
object.

Do that for multiple objects, and you can control the scene. Throw in  
a few slabs, and a videoplane to texture on, and you are all set (as  
long as your render order for the sketches, and video plane is  
correct ;)

Ive got an example patch, but Im about to run off to work. Let me  
know if you want it. it works quite well.

>> Sorry, I don't understand. It should be possible to have multiple  
>> obj3d's in the same render context each rendering to a different  
>> pbuffer, no? If that's the case, then it seems that anything that  
>> can be done with shared textures can also be done with capture/ 
>> pbuffers (with the exception of the matrix->texture type stuff you  
>> mentioned.)
>>
>
> Ok, here's the deal.  Let's say I'm rendering a gridshape with alpha
> 0.5 and a mesh with alpha 0.5 and the mesh happens to cut through the
> middle of the gridshape.  If you render both things to different
> pbuffers and then blen the textures together, it ain't gonna look
> right as compared to just rendering everything normally.  In addition,
> if I have depth testing enabled, it also won't look right because some
> parts of the mesh will be covered by the gridshape and vice-verse.
>
> To capture what you would see in the framebuffer to a pbuffer, you
> have to do something like jit.gl.render @capture tex_pbuff.  This will
> capture *everything*...meaning the gridshape and the mesh properly
> blended together.  Make sense?
>
> wes


right as compared to just rendering everything normally.<<<

In my application I do all 3d rendering for each layer of the mix in a single external so I think pbuffers will be a better solution for me.

>>>
If you render both things to different
pbuffers and then blen the textures together, it ain't gonna look
right as compared to just rendering everything normally.<<<

So it looks like I can have the best of both worlds by aggregating obj3d's using sketch and compositing layers using capture.

>>>
tell the jit.gl.sketch objects to [drawobject ] and your 
ob3D object will pop onto the texture that is capturing the sketch 
object.<<<

So it looks like I can have the best of both worlds by aggregating obj3d's using sketch and compositing layers using capture.


yeah, it works pretty well, and its super sexy to use imageunits to 

work with photoshop style blend modes on the geometry. Of course, 

only using a spinning torus if you are truly hardcore, right greg?

On Sep 7, 2006, at 1:50 PM, Paul Greyson wrote:

> tell the jit.gl.sketch objects to [drawobject ] and your

> ob3D object will pop onto the texture that is capturing the sketch

> So it looks like I can have the best of both worlds by aggregating 

> obj3d's using sketch and compositing layers using capture.

yeah, it works pretty well, and its super sexy to use imageunits to  
work with photoshop style blend modes on the geometry. Of course,  
only using a spinning torus if you are  truly hardcore, right greg?

>
>>>>
> tell the jit.gl.sketch objects to [drawobject ] and your
> ob3D object will pop onto the texture that is capturing the sketch
> object.
><<<
>
> Cool! I didn't know you can do that.
>
> So it looks like I can have the best of both worlds by aggregating  
> obj3d's using sketch and compositing layers using capture.

> yeah, it works pretty well, and its super sexy to use imageunits to 

> work with photoshop style blend modes on the geometry. Of course, 

> only using a spinning torus if you are truly hardcore, right greg?

Yessirree! Thanks for bringing it up. Spinning is

marginally less "so last Tuesday" in comparison

to throbbing, but all the cool kids are doing spectrally

[sharing is fun: new toys] OpenGL preview