Trond Lossius

One of the things I find difficult when working with OpenGL stuff, is 

finding good approaches towards how to debug patches. I often find that 

either it work, and I can see whatever I am attempting at, or one or 

more layers do not show up when rendered. I often wish that I would be 

able to monitor what the signal looks like along the chain from one 

OpenGL object to the next, the way that is so easy to do with ordinary 

Jitter objects. Are there any smart ways of doing this that I have 

missed out on, or other recommended strategies for debugging OpenGL 

One of the things I find difficult when working with OpenGL stuff, is 
finding good approaches towards how to debug patches. I often find that 
either it work, and I can see whatever I am attempting at, or one or 
more layers do not show up when rendered. I often wish that I would be 
able to monitor what the signal looks like along the chain from one 
OpenGL object to the next, the way that is so easy to do with ordinary 
Jitter objects. Are there any smart ways of doing this that I have 
missed out on, or other recommended strategies for debugging OpenGL 
processing?

how-to-debug-opengl-patches

seconded. a reverse jit.gl.texture might be a really useful gl object.

On Aug 20, 2007, at 12:29 PM, Trond Lossius wrote:

> One of the things I find difficult when working with OpenGL stuff, 

> is finding good approaches towards how to debug patches. I often 

> find that either it work, and I can see whatever I am attempting 

> at, or one or more layers do not show up when rendered. I often 

> wish that I would be able to monitor what the signal looks like 

> along the chain from one OpenGL object to the next, the way that is 

> so easy to do with ordinary Jitter objects. Are there any smart 

> ways of doing this that I have missed out on, or other recommended 

> strategies for debugging OpenGL processing?

seconded.  a reverse jit.gl.texture might be a really useful gl object.

> One of the things I find difficult when working with OpenGL stuff,  
> is finding good approaches towards how to debug patches. I often  
> find that either it work, and I can see whatever I am attempting  
> at, or one or more layers do not show up when rendered. I often  
> wish that I would be able to monitor what the signal looks like  
> along the chain from one OpenGL object to the next, the way that is  
> so easy to do with ordinary Jitter objects. Are there any smart  
> ways of doing this that I have missed out on, or other recommended  
> strategies for debugging OpenGL processing?
>
>
> Thanks,
> Trond
>


One of the not very well known techniques is that texture and slab 

processing let you do inline texture readback to a matrix.

jit.gl.slab mycontext @file vade.awesome.shader.jxs

it seems as though you cant go straight to a pwindow however. I 

sometimes use this to troubleshoot things.

However, without using slabs/texture processing, you are going to 

have to do a bit of work, and disabled things you dont want to draw.

This is why I use @automatic 0. You can simply gate any bangs to 

objects you want to disable. They no longer render, and voila, you 

can see what is happening before they are drawn into the buffer.

One of the not very well known techniques is that texture and slab  
processing let you do inline texture readback to a matrix.

jit.gl.slab mycontext @file vade.awesome.shader.jxs
|
jit.matrix 4 char 320 240
|
jit.pwindow

it seems as though you cant go straight to a pwindow however. I  
sometimes use this to troubleshoot things.

However, without using slabs/texture processing, you are going to  
have to do a bit of work, and disabled things you dont want to draw.

This is why I use @automatic 0. You can simply gate any bangs to  
objects you want to disable. They no longer render, and voila, you  
can see what is happening before they are drawn into the buffer.

> One of the things I find difficult when working with OpenGL stuff,  
> is finding good approaches towards how to debug patches. I often  
> find that either it work, and I can see whatever I am attempting  
> at, or one or more layers do not show up when rendered. I often  
> wish that I would be able to monitor what the signal looks like  
> along the chain from one OpenGL object to the next, the way that is  
> so easy to do with ordinary Jitter objects. Are there any smart  
> ways of doing this that I have missed out on, or other recommended  
> strategies for debugging OpenGL processing?
>
>
> Thanks,
> Trond

> One of the not very well known techniques is that texture and slab 

> processing let you do inline texture readback to a matrix.

> jit.gl.slab mycontext @file vade.awesome.shader.jxs

> it seems as though you cant go straight to a pwindow however. I 

> sometimes use this to troubleshoot things.

> However, without using slabs/texture processing, you are going to have 

> to do a bit of work, and disabled things you dont want to draw.

> This is why I use @automatic 0. You can simply gate any bangs to objects 

> you want to disable. They no longer render, and voila, you can see what 

> is happening before they are drawn into the buffer.

> On Aug 20, 2007, at 12:29 PM, Trond Lossius wrote:

>> One of the things I find difficult when working with OpenGL stuff, is 

>> finding good approaches towards how to debug patches. I often find 

>> that either it work, and I can see whatever I am attempting at, or one 

>> or more layers do not show up when rendered. I often wish that I would 

>> be able to monitor what the signal looks like along the chain from one 

>> OpenGL object to the next, the way that is so easy to do with ordinary 

>> Jitter objects. Are there any smart ways of doing this that I have 

>> missed out on, or other recommended strategies for debugging OpenGL 

vade wrote:
> One of the not very well known techniques is that texture and slab 
> processing let you do inline texture readback to a matrix.
>
> you can go from
>
> jit.gl.slab mycontext @file vade.awesome.shader.jxs
> |
> jit.matrix 4 char 320 240
> |
> jit.pwindow
>
> it seems as though you cant go straight to a pwindow however. I 
> sometimes use this to troubleshoot things.
>
> However, without using slabs/texture processing, you are going to have 
> to do a bit of work, and disabled things you dont want to draw.
>
> This is why I use @automatic 0. You can simply gate any bangs to objects 
> you want to disable. They no longer render, and voila, you can see what 
> is happening before they are drawn into the buffer.
>
>
> On Aug 20, 2007, at 12:29 PM, Trond Lossius wrote:
>
>> One of the things I find difficult when working with OpenGL stuff, is 
>> finding good approaches towards how to debug patches. I often find 
>> that either it work, and I can see whatever I am attempting at, or one 
>> or more layers do not show up when rendered. I often wish that I would 
>> be able to monitor what the signal looks like along the chain from one 
>> OpenGL object to the next, the way that is so easy to do with ordinary 
>> Jitter objects. Are there any smart ways of doing this that I have 
>> missed out on, or other recommended strategies for debugging OpenGL 
>> processing?
>>
>>
>> Thanks,
>> Trond
>> jitter@cycling74.com 
>
> *v a d e //*
>
> *www.vade.info*
> *abstrakt.vade.info*
>
>
>


How to debug OpenGL patches