icu222much

I have a few simple 3D polygons in the foreground moving being rendered in my 3D world using the jit.gl.render object. I want to use a 2D image as my background. Is this possible?

jit-gl-render-2d-background

send a 4 char matrix (like the output of jit.qt.movie) with a prepend 

draw_pixels which will force the background to be... your movie!

or, check out @automatic 0 mode, and use a jit.gl.videoplane. This is 

nicer as you have better interpolation (prepend draw_pixels) has no 

> I have a few simple 3D polygons in the foreground moving being 

> rendered in my 3D world using the jit.gl.render object. I want to 

> use a 2D image as my background. Is this possible?

send a 4 char matrix (like the output of jit.qt.movie) with a prepend  
draw_pixels which will force the background to be... your movie!

or, check out @automatic 0 mode, and use a jit.gl.videoplane. This is  
nicer as you have better interpolation (prepend draw_pixels) has no  
interpolation.

>
> Hello
>
> I have a few simple 3D polygons in the foreground moving being  
> rendered in my 3D world using the jit.gl.render object. I want to  
> use a 2D image as my background. Is this possible?
>
> -Jon-

also, use the @transform_reset 2 attribute of jit.gl.videoplane, and 

like vade sez make sure you draw it first (before anything else) 

> send a 4 char matrix (like the output of jit.qt.movie) with a 

> prepend draw_pixels which will force the background to be... your 

> or, check out @automatic 0 mode, and use a jit.gl.videoplane. This 

> is nicer as you have better interpolation (prepend draw_pixels) has 

> On Mar 30, 2007, at 10:09 AM, jOn wrote:

>> I have a few simple 3D polygons in the foreground moving being 

>> rendered in my 3D world using the jit.gl.render object. I want to 

>> use a 2D image as my background. Is this possible?

also, use the @transform_reset 2 attribute of jit.gl.videoplane, and  
like vade sez make sure you draw it first (before anything else)  
using bangs and "@automatic 0"

> send a 4 char matrix (like the output of jit.qt.movie) with a  
> prepend draw_pixels which will force the background to be... your  
> movie!
>
> or, check out @automatic 0 mode, and use a jit.gl.videoplane. This  
> is nicer as you have better interpolation (prepend draw_pixels) has  
> no interpolation.
>
> On Mar 30, 2007, at 10:09 AM, jOn wrote:
>
>>
>> Hello
>>
>> I have a few simple 3D polygons in the foreground moving being  
>> rendered in my 3D world using the jit.gl.render object. I want to  
>> use a 2D image as my background. Is this possible?
>>
>> -Jon-
>
> v a d e //
>
> www.vade.info
> abstrakt.vade.info
>
>
>


I should note prepend draw_pixels goes to jit.gl.render :)

On Mar 30, 2007, at 10:56 AM, vade wrote:

> send a 4 char matrix (like the output of jit.qt.movie) with a  
> prepend draw_pixels which will force the background to be... your  
> movie!
>
> or, check out @automatic 0 mode, and use a jit.gl.videoplane. This  
> is nicer as you have better interpolation (prepend draw_pixels) has  
> no interpolation.
>

I'm hoping there is a simple answer for this question...

I'm using jit.gl.videoplane in conjunction with a custom vertex 

my patch has two modes, one with shader enabled the other without.

I also have a simple 'fade to black' algorithm, using "color $1 $1 

$1 $1" command sent to jit.gl.videoplane.

fade works perfectly when the videoplane is not using the shader, but 

for some reason with the shader enabled. the color command no longer 

works. I'm wondering if there needs to be a hook in the shader to 

pass through commands, or if maybe the color command needs to be 

any thoughts on how to get fade to black working with the shader is 

I'm using jit.gl.videoplane in conjunction with a custom vertex  
shader (via jit.gl.shader)

my patch has two modes, one with shader enabled the other without.
I also have a simple 'fade to black' algorithm,  using "color $1 $1  
$1 $1" command sent to jit.gl.videoplane.

fade works perfectly when the videoplane is not using the shader, but  
for some reason with the shader enabled. the color command no longer  
works.  I'm wondering if there needs to be a hook in the shader to  
pass through commands, or if maybe the color command needs to be  
specifically accounted for.

any thoughts on how to get fade to black working with the shader is  
appreciated (perhaps a work around?)

Yes, you have to put in some kind of hook because shaders completely

replace the standard OpenGL pipeline. There are a variety of ways to

do this. There is a built in vertex shader variable for accessing

what glColor() sets OpenGL state to. It is attribute vec4 gl_Color.

Another typical way to do this is to have a shader parameter for

output alpha. In the end it depends on if you want an explicit

opacity control or if you want to depend on actual OpenGL state. In

alot of the Jitter shaders, there is an explicit opacity control that

either sets just the final alpha or multiplies the final color by some

constant, including the alpha. This is probably the most

straightforward way to go for pixel processing. If you're doing

shaders on 3D forms other than a videoplane, you may want some more

involved dependency on OpenGL state. Here's some relevant info from

Unlike user-defined varying variables, the built-in varying variables

correspondence between the vertex language and the fragment language.

Two sets are provided, one for each language. Their relationship is

described below. The following built-in varying variables are

available to write to in a vertex shader. A particular one should be

written to if any functionality in a corresponding fragment shader or

fixed pipeline uses it or state derived from it. Otherwise, behavior

varying vec4 gl_TexCoord[]; // at most will be gl_MaxTextureCoords

For gl_FogFragCoord, the value written will be used as the "c" value

on page 160 of the OpenGL 1.4 Specification by the fixed functionality

pipeline. For example, if the z-coordinate of the fragment in eye

space is desired as "c", then that' s what the vertex shader should

write into gl_FogFragCoord. As with all arrays, indices used to

subscript gl_TexCoord must either be an integral constant expressions,

or this array must be re-declared by the shader with a size. The size

can be at most gl_MaxTextureCoords. Using indexes close to 0 may aid

the implementation in preserving varying resources. The following

varying variables are available to read from in a fragment shader. The

gl_Color and gl_SecondaryColor names are the same names as attributes

passed to the vertex shader. However, there is no name conflict,

because attributes are visible only in vertex shaders and the

following are only visible in a fragment shader.

The values in gl_Color and gl_SecondaryColor will be derived

gl_FrontColor, gl_BackColor, gl_FrontSecondaryColor, and

gl_BackSecondaryColor based on which face is visible.

Hi dekam,
Yes, you have to put in some kind of hook because shaders completely
replace the standard OpenGL pipeline.  There are a variety of ways to
do this.  There is a built in vertex shader variable for accessing
what glColor() sets OpenGL state to.  It is attribute vec4 gl_Color.
Another typical way to do this is to have a shader parameter for
output alpha.  In the end it depends on if you want an explicit
opacity control or if you want to depend on actual OpenGL state.  In
alot of the Jitter shaders, there is an explicit opacity control that
either sets just the final alpha or multiplies the final color by some
constant, including the alpha.  This is probably the most
straightforward way to go for pixel processing.  If you're doing
shaders on 3D forms other than a videoplane, you may want some more
involved dependency on OpenGL state.  Here's some relevant info from
the GLSL spec:

V a r y i n g V a r i a b l e s
Unlike user-defined varying variables, the built-in varying variables
don't have a strict one-to-one
correspondence between the vertex language and the fragment language.
Two sets are provided, one for each language. Their relationship is
described below. The following built-in varying variables are
available to write to in a vertex shader. A particular one should be
written to if any functionality in a corresponding fragment shader or
fixed pipeline uses it or state derived from it. Otherwise, behavior
is undefined.

varying vec4 gl_FrontColor;
varying vec4 gl_BackColor;
varying vec4 gl_FrontSecondaryColor;
varying vec4 gl_BackSecondaryColor;
varying vec4 gl_TexCoord[]; // at most will be gl_MaxTextureCoords
varying float gl_FogFragCoord;

For gl_FogFragCoord, the value written will be used as the "c" value
on page 160 of the OpenGL 1.4 Specification by the fixed functionality
pipeline. For example, if the z-coordinate of the fragment in eye
space is desired as "c", then that' s what the vertex shader should
write into gl_FogFragCoord. As with all arrays, indices used to
subscript gl_TexCoord must either be an integral constant expressions,
or this array must be re-declared by the shader with a size. The size
can be at most gl_MaxTextureCoords. Using indexes close to 0 may aid
the implementation in preserving varying resources. The following
varying variables are available to read from in a fragment shader. The
gl_Color and gl_SecondaryColor names are the same names as attributes
passed to the vertex shader. However, there is  no name conflict,
because attributes are visible only in vertex shaders and the
following are only visible in a fragment shader.

varying vec4 gl_Color;
varying vec4 gl_SecondaryColor;
varying vec4 gl_TexCoord[]; // at most will be gl_MaxTextureCoords
varying float gl_FogFragCoord;

The values in gl_Color and gl_SecondaryColor will be derived
automatically by the system from
gl_FrontColor, gl_BackColor, gl_FrontSecondaryColor, and
gl_BackSecondaryColor based on which face is visible.


or, if you prefer automatic, use @layer attribute for jit.gl objects.

jit.gl.render + 2D Background