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

Re: [Public WebGL] Problems with vertexAttrib4fv



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: