DarkRadiant Preview Bug

[greebo]

Having a brief look through the code (on my Linux machine, where I have not previously seen the bug), it seems that the problem could be that the GLSL shader is using the texture matrixes from texture units which have not had a texture matrix set or initialised. The only changes to the texture matrix are:

 

OpenGLRenderPass::render(), which initialises the texture matrix of the currently-bound texture unit (with no attempt to determine which this is) to identity, and

 

GLSLBumpProgram::applyRenderParams() , which loads the local2light transformation matrix into the texture matrix of texture unit 3.

 

I suspect this worked before because the unused texture matrices were simply left at the identity, but maybe the newer drivers are not initialising texture matrices for texture units that are not used, so this operation in the GLSL shader gives a wrong result.

 

If this reasoning is correct, then the solution could be as simple as removing the offending multiplication operation in the GLSL shader altogether, since it performs no purpose when the texture matrices are never used in the code.

 

Robert (Tr3b) suggested to load our own uniform texture matrix into the shader. This might be necessary on the long run anyway, as each shader stage can have translate and scale instructions on them (diffuse and bump, all independently) - I cannot imagine accomplishing such a thing without hacking the texture matrix of each unit.

 

Of course, the quick fix would be to remove the references to texture units 1 and above.

[OrbWeaver]

Indeed, my "quick fix" suggestion was based on the assumption that at the moment the texture matrix modification keywords such as scale, translate etc are not supported. When these are implemented they will indeed have to use the texture matrix as you say.

[greebo]

Tracked: http://bugs.angua.at/view.php?id=2405

[Serpentine]

Havent followed this too closely, but this thread:

http://forums.amd.com/devforum/messageview.cfm?catid=392&threadid=140899&enterthread=y

 

seems to suggest it's been fixed and was a problem.

[greebo]

Interesting. Can somebody confirm that this is fixed with Catalyst 10.9?

[OrbWeaver]

That does look like the same problem, but I can't immediately see from his description whether the problem occurs only if he doesn't load the identity matrix into the texture units, or if it happens no matter what. It does sound like a driver bug in any case, since as far as I know all un-initialised matrices in OpenGL should be left at identity by the driver.

[ungoliant]

don't forget, some users (like me) use "legacy" cards. my radeon 1950xtx only supports catalyst drivers up to 10.2, so don't depend on 10.9 and up to fix everyones problems.

[Mr Lemony Fresh]

Hello, I too have had this problem and I don't know if THIS has been mentioned, but I was running 1.2.2 x64, bump map worked fine, then I installed 1.4.0 and now bump mapping doesn't work.

 

Just thought that might count for something.

 

EDIT: And here's more news, I installed catylist 10.10d to no improvement

 

EDIT: and 3.0 is the last to allow bump map rendering, so I'll use it with the latest release.

Edited November 22, 2010 by Mr Lemony Fresh

[greebo]

I already checked the workaround into SVN a few weeks ago, so DR 1.5.0 upwards should not expose that issue anymore.