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

Re: [Public WebGL] Problems with vertexAttrib4fv



Current Chromium builds, at least, should be emulating the OpenGL ES
2.0 behavior for vertex attribute 0. You should not need to modify
your application code. Any other behavior of a WebGL implementation is
not spec compliant and a bug should be filed with the appropriate
browser vendor.

-Ken

On Wed, Aug 11, 2010 at 1:04 PM, Alan Chaney <alan@mechnicality.com> wrote:
> 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:
>
>

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