New Texcoord[3] - canvas coordinate options in 2DFilters

http://lists.blender.org/pipermail/bf-blender-cvs/2008-November/016476.html

  • The second opengl texture coordinate (gl_TexCoord[3]) are now filled
    in as well, and will give canvas coordinates from 0.0 to 1.0. The
    first texture coordinates still give the coordinates in the texture
    that is being used, which may not match the canvas exactly, so both
    coordinates are needed.

Now 3d views in the right side of the screen use a smaller gl_Texture buffer and should performance better. You can also check for the canvas coordinate to process your shader only inside the canvas (the gl_Texture buffer is bigger than the current 3dview).

I’m attaching a file here to demonstrate this use - example file

Press 1 to see the shader using texcoord[0], texcoord[1] and getting color information from the canvas coordinates
Press 2 to see the same shader using the uniform calculated from python instead

I hope you can make a good use of it,
and a thank you for Brecht for the help in this matter and for the debug info in shader compilation errors (maybe a menu option to enable/disable it could help as well).

Cheers,
Dalai

EDIT:::
I forgot to say a small detail. It’s currently only available in SVN (post Blender.248a). You can use one recent build from Graphicall

EDIT2:: this example is outdated. To make it work replace texcoord[1] per texcoord[3]. and read this

Attachments

2Dfilter_texCoord.blend (33.6 KB)

i try it and enable all frame and the 1,2 buttons have same frame rate, im using the latest svn ,the 1 should be better?

In this file the shader is very simple. It will not have any performance boost between the two shaders (1 or 2).
However other heavy shaders (blur, DoF, …) and canvas dimensions far from power of 2 dimensions may have some help here.
Volunteers to benchmark are welcome.

These shaders are very easy to read, there you can find the code to avoid unnecessary shader calculation in areas outside the canvas. Since we need to perform a check to determine if the pixel is inside the canvas, this method can be even slower :stuck_out_tongue:

What you may notice for sure is the performance improvement from 2.48a and SVN builds for shaders running in screens other than the bottom left one. Now the gl_Tex_Buffer is smaller than before.

Does it make sense?
(btw, thanks for test :slight_smile: )

You’ll need 17267 or later.

dfelinto, apart from the performance improvement, I am still struggling a bit with the new texcoord system. Can you email me or something? thx.

Forget about the faster thing :slight_smile: We back to big buffer textures. To speedup your 2dfilters try to use 3dview from the left or fullscreen to run your game in Blender.

The important thing is:

Now the canvas texcoord can be accessed through texcoord[3] (intead of [1]).

I’m posting here an shader example


uniform sampler2D bgl_RenderedTexture;

void main()
{

	vec2 texcoord = gl_TexCoord[0].st;
	vec2 cancoord = gl_TexCoord[3].st;

	vec4 foreground = texture2D(bgl_RenderedTexture, texcoord);

	
// diagonals

	//diagonal 0,0 - 1,1
	if (cancoord.s > (cancoord.t - 0.01)){ 
		if (cancoord.s < cancoord.t){
			foreground.r = 1.0;
			foreground.g = 1.0;
			foreground.b = 1.0;
			foreground.a = 0.5;	
		}
	}
	 //diagonal 1,0 - 0,1
	if (cancoord.s > (1.0 - cancoord.t - 0.01)){
		if (cancoord.s < (1.0 - cancoord.t)){
			foreground.r = 1.0;
			foreground.g = 1.0;
			foreground.b = 1.0;
			foreground.a = 0.5;
		}
	}

// center crux

	if (cancoord.s > 0.495){
		if (cancoord.s < 0.5){
			foreground.r = 1.0;
			foreground.g = 0.0;
			foreground.b = 0.0;	
		}
	}

	if (cancoord.t > 0.495){
		if (cancoord.t < 0.5){
			foreground.r = 1.0;
			foreground.g = 0.0;
			foreground.b = 0.0;	
		}
	}

	gl_FragColor = foreground;

}

If you need to access a specific coordinate of the bgl_RenderedTexture using a canvas coordinate instead (from 0.0 to 1.0) the easiest way so far is to use the bottom left 3dview with one of the examples I posted before (changing texcoord[1] to texcoord[3]).

To use it in different 3dviews we have two options, both currently unavailable:

  1. create an API call to get access of the current canvas.GetLeft() and canvas.GetBottom() and perform some math to convert it (simple math though).

  2. try to make the buffer origin start in the canvas origin (the bottom left corner) - in Blender code

If you are confuse but curious about the technical aspects, this is the last commit related to that - http://lists.blender.org/pipermail/bf-blender-cvs/2008-November/016678.html