Java-Gaming.org
Play Revenge of the Titans! The situation is critical. We need fancy commanders to defend Earth, the moon, Mars!
Featured games (78)
games approved by the League of Dukes
Games in Showcase (408)
games submitted by our members
Games in WIP (293)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  GLSL help  (Read 1255 times)
0 Members and 1 Guest are viewing this topic.
Offline anarchotron

Junior Member




...precious bodily fluids.


« Posted 2005-10-17 03:41:14 »

Howdy.  I've got a GLSL problem I need  help with.

Basically I have a shader that operates on 5 active texture units & 5 texture coordinate sets.  I'm pretty sure that all 5 texture units are properly activated on the code-side.  I'm positive that all 5 texture coordinate sets are coming in.  However, when I assign gl_TexCoord values for indices 0-4, the value in gl_TexCoord[0] basically overwrites what in one of my other, user-defined varying variables (in this case, normal).

I've stripped down my shaders to isolate the problem.  The vertex program just sets a varying normal, and assigns 0-4 gl_TexCoord values.  The fragment program just renders the value of the normal, which allows me to see that the register has been filled with the value of gl_TexCoord[0]. (I confirmed this by messing around with the 0th texture coordinate to see the results).

I'm going to keep looking into the code, because it really seems like the vertex program is mis-allocating the gl_TexCoord array, in a way such that gl_TexCoord[0] is aliasing my other varying register (normal).

In the meantime, if this problem rings any bells for anyone, please let me know.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
varying vec3 normal_c;

void main()
{  
   normal_c = normalize(gl_NormalMatrix * gl_Normal);  
     
   gl_TexCoord[0] = gl_TextureMatrix[0] * gl_MultiTexCoord0;
   gl_TexCoord[1] = gl_TextureMatrix[1] * gl_MultiTexCoord1;
   gl_TexCoord[2] = gl_TextureMatrix[2] * gl_MultiTexCoord2;
   gl_TexCoord[3] = gl_TextureMatrix[3] * gl_MultiTexCoord3;
   gl_TexCoord[4] = gl_TextureMatrix[4] * gl_MultiTexCoord4;

   gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}


1  
2  
3  
4  
5  
6  
varying vec3 normal_c;

void main()
{  
   gl_FragColor = vec4(normal_c, 0.0);
}
Offline anarchotron

Junior Member




...precious bodily fluids.


« Reply #1 - Posted 2005-10-17 03:45:24 »

FWIW, I can confirm this behavior by changing the vertex program like below.  Now when the fragment program renders from normal_c, it is correct!.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
varying vec3 normal_c;

void main()
{  
   normal_c = normalize(gl_NormalMatrix * gl_Normal);  
     
        ///-------
  gl_TexCoord[0] = vec4(normal_c, 0.0);
        ///-------

   gl_TexCoord[1] = gl_TextureMatrix[1] * gl_MultiTexCoord1;
   gl_TexCoord[2] = gl_TextureMatrix[2] * gl_MultiTexCoord2;
   gl_TexCoord[3] = gl_TextureMatrix[3] * gl_MultiTexCoord3;
   gl_TexCoord[4] = gl_TextureMatrix[4] * gl_MultiTexCoord4;

   gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}
Offline anarchotron

Junior Member




...precious bodily fluids.


« Reply #2 - Posted 2005-10-17 04:07:30 »

Sorry for the spam, but I took a look at the cgc output for my vertex & fragment program.  Vertex program looks ok.  Fragment program looks like this, clearly pulling the normal_c varying variable from the TEX0 register.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
fs_broken.fsh
5 lines, 0 errors.
!!ARBfp1.0
# cgc version 1.4.0000, build date Jun  9 2005 12:09:02
# command line args: -oglsl -profile arbfp1
# source file: fs_broken.fsh
#vendor NVIDIA Corporation
#version 1.0.02
#profile arbfp1
#program main
#var float4 gl_FragColor : $vout.COLOR : COL : -1 : 1
#var float3 normal_c : $vin.TEX0 : TEX0 : -1 : 1
#const c[0] = 0
PARAM c[1] = { { 0 } };
MOV result.color.xyz, fragment.texcoord[0];
MOV result.color.w, c[0].x;
END
# 2 instructions, 0 R-regs
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Spasi
« Reply #3 - Posted 2005-10-17 12:50:07 »

Hi anarchotron,

Quote
# cgc version 1.4.0000, build date Jun  9 2005 12:09:02
First of all, try a newer driver. The original shader should be working as expected and the behavior you're seeing seems like a bug.

The cgc output you're getting is actually correct. When you link these two shaders, the linker sees that you're not using the gl_TexCoords and optimizes them away. So, only the normal_c remains and is correctly put in TEX0.

You may be able to work around this bug by either assigning normal_c to a spare gl_TexCoord, or using custom varyings for the TexCoords.
Offline anarchotron

Junior Member




...precious bodily fluids.


« Reply #4 - Posted 2005-10-17 16:33:25 »

Aye I got the newest driver (Catalyst 5.10) as soon as this started happening, with no luck.

Very annoying little bug.  I worked around it for now by using fewer gl_TexCoord elements for my actual TCs, as well as packing my declared varyings a little better (like merging fog into one of the unused elements in a varying declared as vec3).

If I ever stumble across what's actually happening I'll let you know!

Thanks!
Offline Spasi
« Reply #5 - Posted 2005-10-17 16:48:09 »

Hmmm, ATI... Wink

Were you using gl_FogFragCoord?
Offline anarchotron

Junior Member




...precious bodily fluids.


« Reply #6 - Posted 2005-10-17 17:10:01 »

Nope.  I did try to shift over to using that instead of my own varying variable.  I've used it before with no problems.  However, the cgc compiler claims something to the effect of "not available with this shader version" or something.  (I don't have the error right in front of me).

In the past, gl_FogFragCoord has worked properly using the GL GLSL compiler, even if cgc refuses to compile with it.  I figured that might be a good way to free up a interpolant.

Is there something dangerous I should know about gl_FogFragCoord?

Offline Spasi
« Reply #7 - Posted 2005-10-17 17:50:23 »

I had reported a bug to ATI with a very similar behaviour (last March IIRC). When I was accessing gl_FogFragCoord (even if it didn't contribute to the shader output), all the varyings "shifted" one position. So, given there were 3 varyings A, B, C, I was getting the following behaviour:

- A contained random values
- B contained the value of A
- C contained the value of B
- The C value was lost

Anyway, that's an old bug and should be fixed by now.

Are you sure you were not exceeding MAX_VARYING_FLOATS before reducing/packing your varyings?
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

Play Revenge of the Titans! The situation is critical. We need fancy commanders to defend Earth, the moon, Mars!
 
Play Revenge of the Titans! The situation is critical. We need fancy commanders to defend Earth, the moon, Mars and Titan!

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

The invasion has landed! On Mars! And you're there to beat 'em!
cubemaster21 (104 views)
2013-05-17 21:29:12

alaslipknot (113 views)
2013-05-16 21:24:48

gouessej (141 views)
2013-05-16 00:53:38

gouessej (137 views)
2013-05-16 00:17:58

theagentd (149 views)
2013-05-15 15:01:13

theagentd (134 views)
2013-05-15 15:00:54

StreetDoggy (177 views)
2013-05-14 15:56:26

kutucuk (200 views)
2013-05-12 17:10:36

kutucuk (201 views)
2013-05-12 15:36:09

UnluckyDevil (207 views)
2013-05-12 05:09:57
Complex number cookbook
by Roquen
2013-04-24 12:47:31

2D Dynamic Lighting
by Oskuro
2013-04-17 16:46:12

2D Dynamic Lighting
by Oskuro
2013-04-17 16:45:57

2D Dynamic Lighting
by Oskuro
2013-04-17 16:23:20

Noise (bandpassed white)
by Roquen
2013-04-05 17:36:01

Noise (bandpassed white)
by Roquen
2013-04-03 16:17:38

Java Data structures
by Roquen
2013-03-29 13:21:12

Topic Request
by kutucuk
2013-03-22 21:42:01
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!
Page created in 0.095 seconds with 21 queries.