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

Re: [Public WebGL] Problems with vertexAttrib4fv



Thanks Vlad,

Well, that would explain things. Looks like application writers will have to beware of this one. I'll modify my code as I outlined below and see if that fixes it on the Linux/ATI box. With my Khronos member hat on it looks like there will have to be work by some of the driver manufacturers if they want to claim that their drivers are WebGL compliant.

Regards

Alan


On 8/11/2010 12:54 PM, Vladimir Vukicevic wrote:
Oh right, I keep forgetting attrib indices are (have to be) just numbers.  I can't remember where we had this discussion, but I /think/ we decided that this was a driver bug (requiring attrib index 0 to be an enabled array).  At least, we didn't add any spec language requiring it, and I see that we don't do any explicit checks for it -- and that there are conformance tests that require a constant vertex attrib 0 to not fail (gl-bind-attrib-location-test.html).

     - Vlad

----- Original Message -----
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:

----------------------------------------------------------- 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: