Wesley Smith

> and lastly, is it possible to render an entire scene to a texture now? Just curious, as it seems like > some things have been changed possibly wrt jitter. Not a big deal

Indeed it is possible now using the FBO backend. The pbuffer backend

has some issues in the public beta that will hopefully be addressed in

the future, but for now, FBOs work quite nicely. There are a few

things to note in the patch. First, pay attention to how

jit.gl.render's @capture attribute is being used to both render to

texture and to the normal jit.window context. Second, notice the

glreadback message to jitter. There are two options given in patch:

fbo and rtt. fbo is FBO and rtt is pbuffer. You will probably get

stack overflow errors with the pbuffer setting.

The example is not so hot. I threw it together to show the mechanics

of it. To get more interesting effects, I would reccomend using

shaders to process the capture texture to get some alpha in the thing

for better feedback. Also something to note is that I'm rendering all

of the geometry to the FBO and to the jit.window. This requires

rendering everything twice. This doesn't have to be the case. You

can render to just the FBO or just the jit.window.

Indeed it is possible now using the FBO backend.  The pbuffer backend
has some issues in the public beta that will hopefully be addressed in
the future, but for now, FBOs work quite nicely.  There are a few
things to note in the patch.  First, pay attention to how
jit.gl.render's @capture attribute is being used to both render to
texture and to the normal jit.window context.  Second, notice the
glreadback message to jitter.  There are two options given in patch:
fbo and rtt.  fbo is FBO and rtt is pbuffer.  You will probably get
stack overflow errors with the pbuffer setting.

The example is not so hot.  I threw it together to show the mechanics
of it.  To get more interesting effects, I would reccomend using
shaders to process the capture texture to get some alpha in the thing
for better feedback.  Also something to note is that I'm rendering all
of the geometry to the FBO and to the jit.window.  This requires
rendering everything twice.  This doesn't have to be the case.  You
can render to just the FBO or just the jit.window.

render-to-texture-example

> This is big. Last night I finally figured out how to get to_texture 

> working. For some reason I was simply blanking on it and couldnt 

> get it working before. I did end up rendering twice, and erasing 

> once I had captured to the texture but before I drew to the screen. 

> Ugly hack. The first thing I did once I got it working was throw 

> some jit.gl.slabs and imageunits at it. Goddamn, this is a new era ;)

Yes, to_texture now works properly (which is another way to 

accomplish this besides the @capture/FBO solution). The texture will 

also adapt to the viewport size if the @adapt attribute of 

jit.gl.texture is enabled(is by default).

> This is big. Last night I finally figured out how to get to_texture  
> working. For some reason I was simply blanking on it and couldnt  
> get it working before. I did end up rendering twice, and erasing  
> once I had captured to the texture but before I drew to the screen.  
> Ugly hack.  The first thing I did once I got it working was throw  
> some jit.gl.slabs and imageunits at it. Goddamn, this is a new era ;)

Yes, to_texture now works properly (which is another way to  
accomplish this besides the @capture/FBO solution). The texture will  
also adapt to the viewport size if the @adapt attribute of  
jit.gl.texture is enabled(is by default).

Thats exactly how I was using it - ill have to read up on FBO (is 

there a performance difference at all or ? FBO isnt in my acronym 

Also I noticed that imageunits get cranky if you change the size of 

the texture (as reported in the helpfile - id crash occasionally but 

more likely id notice a huge drop in framerate and Max's memory usage 

would climb and climb - it seemed this would happen more in 

@colormode uyvy.. ), but I really cant be any happier with this 

functionality. Once things work smoothly, it will really make a huge 

Ive already incorporated 1.6 features into my new patch and am 

finding whole slews of new things to play with via slab chains and 

imageunits that manipulate the whole render context - adding some 

distortions/bump maps to the texuture really 'unflattens' openGL.

On Jun 26, 2006, at 10:09 AM, Joshua Kit Clayton wrote:

> Yes, to_texture now works properly (which is another way to 

> accomplish this besides the @capture/FBO solution). The texture 

> will also adapt to the viewport size if the @adapt attribute of 

> jit.gl.texture is enabled(is by default).

Thats exactly how I was using it - ill have to read up on FBO  (is  
there a performance difference at all or ? FBO isnt in my acronym  
database ;)

Also I noticed that imageunits get cranky if you change the size of  
the texture (as reported in the helpfile - id crash occasionally but  
more likely id notice a huge drop in framerate and Max's memory usage  
would climb and climb - it seemed this would happen more in  
@colormode uyvy.. ), but I really cant be any happier with this  
functionality. Once things work smoothly, it will really make a huge  
difference.

Ive already incorporated 1.6 features into my new patch and am  
finding whole slews of new things to play with via slab chains and  
imageunits that manipulate the whole render context - adding some  
distortions/bump maps to the texuture really 'unflattens' openGL.

> Yes, to_texture now works properly (which is another way to  
> accomplish this besides the @capture/FBO solution). The texture  
> will also adapt to the viewport size if the @adapt attribute of  
> jit.gl.texture is enabled(is by default).

when running on an x800 ati xp swetup i get

jit.gl.readback.pbuffer: error creating pbuffer: GL Error: Invalid

> Thats exactly how I was using it - ill have to read up on FBO (is there a

> performance difference at all or ? FBO isnt in my acronym database ;)

> Also I noticed that imageunits get cranky if you change the size of the

> texture (as reported in the helpfile - id crash occasionally but more likely

> id notice a huge drop in framerate and Max's memory usage would climb and

> climb - it seemed this would happen more in @colormode uyvy.. ), but I

> really cant be any happier with this functionality. Once things work

> smoothly, it will really make a huge difference.

> Ive already incorporated 1.6 features into my new patch and am finding

> whole slews of new things to play with via slab chains and imageunits that

> manipulate the whole render context - adding some distortions/bump maps to

> the texuture really 'unflattens' openGL.

> On Jun 26, 2006, at 10:09 AM, Joshua Kit Clayton wrote:

> Yes, to_texture now works properly (which is another way to accomplish

> this besides the @capture/FBO solution). The texture will also adapt to

> the viewport size if the @adapt attribute of jit.gl.texture is enabled(is

when running on an x800 ati xp swetup i get
jit.gl.readback.pbuffer: error creating pbuffer: GL Error: Invalid
enumeration

On 6/26/06, vade  wrote:
>
> Thats exactly how I was using it - ill have to read up on FBO  (is there a
> performance difference at all or ? FBO isnt in my acronym database ;)
> Also I noticed that imageunits get cranky if you change the size of the
> texture (as reported in the helpfile - id crash occasionally but more likely
> id notice a huge drop in framerate and Max's memory usage would climb and
> climb - it seemed this would happen more in @colormode uyvy.. ), but I
> really cant be any happier with this functionality. Once things work
> smoothly, it will really make a huge difference.
> Ive already incorporated 1.6 features into my new patch and am finding
> whole slews of new things to play with via slab chains and imageunits that
> manipulate the whole render context - adding some distortions/bump maps to
> the texuture really 'unflattens' openGL.
>
> great work - seriously.
> *
> *
> *
> *
> *v a d e //*
> *
> *
> *www.vade.info*
> *abstrakt.vade.info*
>
>
> On Jun 26, 2006, at 10:09 AM, Joshua Kit Clayton wrote:
>
> Yes, to_texture now works properly (which is another way to accomplish
> this besides the @capture/FBO solution). The texture will also adapt to
> the viewport size if the @adapt attribute of jit.gl.texture is enabled(is
> by default).
>
>
>
>
>
>

If you're trying to do RTT, try this patch:

Render To Texture Example