jit.gl.slab and capture

Sep 13, 2006 at 6:24pm

jit.gl.slab and capture

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.

#27614
Sep 13, 2006 at 6:36pm

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.

#83667
Sep 13, 2006 at 6:58pm

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

#83668
Sep 13, 2006 at 6:58pm

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.)

#83669
Sep 13, 2006 at 7:06pm

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

#83670
Sep 13, 2006 at 11:17pm

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.

#83671
Sep 13, 2006 at 11:29pm

Ah never mind

sendoutput name friendly_name

Thanks all.

#83672
Sep 13, 2006 at 11:31pm

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

#83673

You must be logged in to reply to this topic.