Forums > Jitter

jit.gl.slab and capture

September 13, 2006 | 6:24 pm

I’m not clear on how slab works. Does it actually render? Or does it just setup a shader for rendering that happens in a downstream obj3d like videoplane? Reason I ask is that sending the capture message to slab doesn’t seem to work.


September 13, 2006 | 6:36 pm

I’m not sure why you would want to use @capture with jit.gl.slab, since
the output is already in the form of a texture. Perhaps you could
indicate what you are trying to accomplish?

Andrew B.


September 13, 2006 | 6:58 pm

On Sep 13, 2006, at 11:24 AM, Paul Greyson wrote:

>
> I’m not clear on how slab works. Does it actually render? Or does
> it just setup a shader for rendering that happens in a downstream
> obj3d like videoplane? Reason I ask is that sending the capture
> message to slab doesn’t seem to work.

As has been discussed previously on the list jit.gl.slab is
fundamentally, just an all in one bundle of the following, with a
little bit of logic.

- an instance of jit.gl.texture for each input, let’s call
in_tex0,….in_texN
- an instance of jit.gl.texture for the output, lets call out_tex
- an instance of jit.gl.shader, let’s call myshader
- an instance of jit.gl.gridshape @shape plane @transform_reset 2
@texture in_tex0 in_tex1 … in_texN @capture out_tex @shader myshader

If you want to copy the output of slab to another texture, just feed
it in the patcher, or from Javascript/Java/C send the message
jit_gl_texture to the instance of
jit.gl.texture you wish to copy to. In JS, this would be something
like the following:

mytex.jit_gl_texture(myslab.capture);

Hope this helps.

-Joshua


September 13, 2006 | 6:58 pm

I was trying to use capture because I want the output to be available to other render contexts (without the restrictions that come with texture sharing.)


September 13, 2006 | 7:06 pm

On Sep 13, 2006, at 11:58 AM, Paul Greyson wrote:

>
> I was trying to use capture because I want the output to be
> available to other render contexts (without the restrictions that
> come with texture sharing.)

FWIW, as far as I know, if you can’t accomplish it with texture
sharing (using shared rendering contexts), you can’t do it with
@capture, and instead need to move through host memory.

On a related note, in the next Jitter release, I’ve provided example
shaders which convert to UYVY or GRGB (masquerading as RGBA) for half
bandwidth transfer of the texture information back to the CPU.

-Joshua


September 13, 2006 | 11:17 pm

Sorry it looks like our previous messages cross.

So since slab uses capture, the output texture is already available to other contexts (I’ve confirmed this.)

So now I’d just like to be able to either specify which texture for slab to use (which doesn’t appear possible from the docs) or alias a second "friendly" name for the auto generated texture. Any way to do either of these? Sorry if this is a basic question. I’ve not been having much success searching the forum on these topics.


September 13, 2006 | 11:29 pm

Ah never mind

sendoutput name friendly_name

Thanks all.


September 13, 2006 | 11:31 pm

On Sep 13, 2006, at 4:17 PM, Paul Greyson wrote:

> So now I’d just like to be able to either specify which texture for
> slab to use (which doesn’t appear possible from the docs) or alias
> a second "friendly" name for the auto generated texture. Any way to
> do either of these? Sorry if this is a basic question. I’ve not
> been having much success searching the forum on these topics.

You could either use "sendoutput name myfriendlyname" -> jit.gl.slab,
or connect the output of jit.gl.slab->jit.gl.texture @name
myfriendlyname. Copying textures this way *also* uses essentially the
same mechanism as capture, FWIW.

Note that sendoutput, sendinput, and send shader let you send any
messages corresponding to the internal texture and shader’s methods
or attributes.

-Joshua


Viewing 8 posts - 1 through 8 (of 8 total)