Page MenuHome

TexCoord in 2dFilters ...
Closed, ArchivedPublicPATCH


Right now I can get texcoord[3] from texcoord[0] dividing them.
As showed below:

vec2 cancoord = gl_TexCoord[3].st; // the canvas texcoord
vec2 texcoord = gl_TexCoord[0].st; // the texture texcoord

vec2 cancenter = vec2 (0.5,0.5);

//getting the values from the uniform
cancenter.s *= texcoord.s / cancoord.s;
cancenter.t *= texcoord.t / cancoord.t;

However it doesn't work with texcood[1](GL_DEPTH_COMPONENT) or texcoord[2] (GL_LUMINANCE16) because of the difference in their origin and the GL_RGBA8 buffer.

As soon as someone (Brecht?) can figure out why this is happen and HOW to synchronize their origins we can have them working perfectly.

As an example with you apply this patch (_bglCoordFactor_161108) and run the blend file (_depthBUG10.blend) the shader actiaved with the key 7 and 8 should work similarly.

This patch is not made for committing(yet) but to share the WIP.

Previous commits:

Event Timeline

why not using this?
glMultiTexCoord2fARB(GL_TEXTURE0_ARB, 1.0, 1.0);
glMultiTexCoord2fARB(GL_TEXTURE1_ARB, 1.0, 1.0);
glMultiTexCoord2fARB(GL_TEXTURE2_ARB, 1.0, 1.0);
glMultiTexCoord2fARB(GL_TEXTURE3_ARB, canvascoord[1], canvascoord[3]);

Hi Hamed.
In order to use the code as you wrote (and it is the better option), we should expect that:

glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, viewport[0], viewport[1], texturewidth, textureheight, 0);

has the same behavior that

glCopyTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE16(or GL_DEPTH_COMPONENT), viewport[0], viewport[1], texturewidth, textureheight, 0);

However in my graphic card (WindowsVista64 NVIDIA9600M GT) this produce the offset effect I submitted as bug report before.

Indeed, if I change:
RGBA_8 per RGBA_16 I have the same "problem" I have with the other buffers.

I'm not sure with the problem is my computador or the way Blender handles the RGBA_8 buffer.

Indeed if you can test, I'm attaching a file with two simple patches that show that (also with two screenshots images and the test file).
I have even the binaries for windows here: (38 MB -

To test it (with the builds or the patches applied) you just need to run the test file with each version, and run the game as it is, without changing the BGE size (no fullscreen). A simple Ctrl+F3 show the result.
Then a list with: OS, graphic card and screen resolution.


Hi dalai,

when using RGBA16, try to change this line too (is in RAS_2DFilterManager::SetupTextures):
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, texturewidth, textureheight, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0);

Changing this line didn't change anything (applying over the patch RGBA16 in

I asked for some friends/users to test it. So I'm waiting for more conclusions and taking the time to go over some openGL basic material (the red book specifically).

But I don't think this is a bug in my system. (btw do you have similar results in your PC?)

strange, I didn't receive an email this time ...
writing again to make sure. (^^^^)

Both patches give me the same result as the RGBA_8 example in the lower-left corner of the .blend

Well I receive the feedback from some testers.

In NVIDIA (GeForce 8500GT@WindowsXP, GeForce 9600@Vista and a third one I forgot to ask the model) the results are the same as the images in that means, RGBA8 is different from RGBA16, LUMINANCE and DEPTH.

In ATI (Radeon 200M express (mobility)@Vista) all buffers (DEPTH, LUMINANCE, RGBA16) work as RGBA8.

So initially, the only way I see of making it compatible with all of them is let it the way it is. And to allow texcoord[3] to texcoord[0] conversion, we either work in the bottom left or fullscreen view, or I can write a python API to pass the viewport[0] and [1] to BGE (or to Blender modules).

It will make the conversion slightly more complex, but I can't see other solutions.

Any other ideas on this matter?

Hi Hamed,

the line [need_tex_update = true;] in RAS_2DFilterManager::EnableFilter is been called every frame.
I'm pretty sure this is slowing things down, why do we need it?

PS.: I'm attaching the patch with glCopySubTexImage - _bglCoordFactor_251108_SubTex I didn't notice any difference in performance though.

I'm having troubles because of the EnableFilter thing for my custom textures uniform patch (not in the track yet, but coming soon).
For I opened a bug report about that.

I started working on that again: Take a look at the file GLSL_samples2.blend.
After P, press 7.
This will get the pixel color corresponding of the Suzanne position and print the background with it.
(we are calculating its relative to the canvas position every frame, and sending it to the shader).

This will only work in the bottom left window or the full screen mode. A patch that doesn't solve the problem BUT indicate the direction I think it's needed to take is: glTexCoord3.patch (it's a mess patch, some things are clearly wrong there, but the key elements are present: UpdateCanvasTextureCoord and UpdateOffsetMatrix).

So, I will be available if anyone wants to help on that before Blender 2.49(I clearly can't do that alone, I tried ...).
Some shaders that need this feature:
- DoF (it takes the Depth information of the central pixel to calculate the Blur
- Scattering (it uses the relative sun position as origin to a radial blur)

They work without that, but only in fullscreen mode (or the bottom left window).

Some comment as your other patches :)

Mitchell Stokes (moguri) triaged this task as Low priority.Jul 4 2014, 10:26 AM

Working on cleaning out the patch tracker:

Is this something still being worked on, or should this report be closed? If there is no response in a week, I will close this report. Active patches should start being migrated to Differential.

Dalai Felinto (dfelinto) changed the task status from Unknown Status to Unknown Status.Jul 7 2014, 4:34 PM

Let's close it. I think I'm one of the 3 people who ever used glTexCoords[3] so if this ever become an issue we re-visit it.