jit.gl.render + 2D Background


    Mar 30 2007 | 2:09 pm
    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-

    • Mar 30 2007 | 2:56 pm
      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
    • Mar 30 2007 | 3:11 pm
      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"
      On Mar 30, 2007, at 3:56 PM, 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. > > 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 > > >
    • Mar 30 2007 | 3:17 pm
      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. >
      v a d e //
      www.vade.info abstrakt.vade.info
    • Mar 30 2007 | 4:58 pm
      Hi everyone,
      I'm hoping there is a simple answer for this question...
      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?)
      deKam
    • Mar 30 2007 | 5:18 pm
      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.
    • Mar 31 2007 | 10:31 am
      or, if you prefer automatic, use @layer attribute for jit.gl objects.