[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Problems with vertexAttrib4fv

Hi Vlad

On 8/11/2010 11:21 AM, Vladimir Vukicevic wrote: 
Hmm, would be interesting to know what attrib location getAttribLocation is returning, though of course, you can't know that :/

Well, when I print it out, the attrib index is a number . I'm using the pattern of compiling and linking the shaders and then using the locations thus derived. I've checked, and it seems that on the linux box the attribute index for a_color is 0, but for the windows box the a_color index is 2.

This is easily explained in that presumably the graphics driver determines the index during the linking process, and the drivers are ATI and Nvidia respectively.

Of course, I could always set the attribute indices before linking, and for example make '0' correspond to 'a_position' which is pretty much always likely to be bound to an array. I notice that the Nvidia driver appears to have made a_position the 0th index

The actual shader code is:

attribute vec3 a_position;
attribute vec3 a_normal;
attribute vec4 a_color;
attribute vec3 a_texcoord;

and this is the order that the nvidia driver appears to use.

I wonder if this is something to do with attribute 0 needing to be an enabled array?  Is a_color the first attribute definition in your shader?  Though I thought we had error checks for 0 not being an enabled array.

I don't understand your comment about attribute 0 needing to be an enabled array. It seems from reading the spec that vertex attributes are handled slightly differently in WebGL than ES 2, but basically what I'm doing is to use disableVertexAttribArray to tell webgl that it isn't bound to an array.

The only specific reference I can find is:

6.2 Enabled Vertex Attributes and Range Checking

and the way that's written implies to me that if you call enableVertexAttribArray(n) then you need to make sure that n is bound with a vertex attribute array pointer statement. But I'm specifically calling disableVertexAttribArray because it isn't.

My feeling at this point is that I'll rewrite the code to set the attrib locations prior to linking. If I do that, the logical thing is to call disableVertexAttribArray as I create them and assign specific default values (ie make them 'constant attributes') and then when I'm setting up a vertexatttrib array specifically enable the ones that I'm using. The nature of my application is such that different objects can use different combinations of attributes. I assume that if I enable them, draw them (drawArrays/drawElements) and then disable them that the GL state machine will handle that properly. Alternatively, I suppose I can track which ones are enabled/disabled and just make sure that as the scenegraph is traversed then the attributes are enabled/disabled according to the needs of the specific scene element.

I'll report back but it probably won't be today because I have to do some other things this afternoon.


Thanks

Alan


     - Vlad

----- Original Message -----

On Wed, Aug 11, 2010 at 10:05 AM, alan@mechnicality.com
<alan@mechnicality.com>  wrote:

Hi

I'm seeing a problem with vertexAttrib4fv which manifests on Linux
x86_64/ATI Radeon 5770 but not on my WinXP32/GForce 8800 GTX

The pseudo code is something like:


    if (! colorVertexAttributeData) {

         int colorIndex = getAttribLocation(shader, "a_color")
         if (colorIndex != -1) {
                 disableVertexAttribArray(colorIndex)
                 vertexAttrib4fv(colorIndex, defaultColor)
         }
   }


where my shader has:

attribute vec3 a_color;

in the attribute definitions.

The purpose behind the code is for the cases where the data doesn't
have a
color attribute channel (using Max speak) so that it is displayed
with a
default color, so I use a constant vertex attribute.

This works fine in the win setup, but on the linux box Chrome
6.0.472.25 dev
ignores the color and Firefox (3.7 ->  4.0 beta 2) just produces a
black
image. By "ignore the color" I've set a default value of
vec4(0.2,0.2,0.2,1.0) in the shader so I can see if anything is
happening.
In chrome, the objects are this color rather than the color provided
in the
vertexAttrib statement.

I don't have a really useful suggestion except to please try the top
of tree Chromium build rather than the dev channel build. WebGL is
still under rapid development. See the WebGL wiki for download
instructions.

If you can boil this down into a small test case please post it.

-Ken


It seems to me that the likely candidates are either the graphics
driver or
some issue with WebGL and X86_64 linux.

When there is a color attribute channel in the vertex attray then
the
vertexAttribPointer correctly finds and displays the color on all
platforms.

Regards

Alan






-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:



-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:


-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: