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

Re: [Public WebGL] Problems with vertexAttrib4fv



OpenGL ES 2.0 doesn't have any special semantics for vertex attribute
0. I don't see anything in section 2.7 of the OpenGL ES 2.0 spec that
specifically mentions this.
http://www.opengl.org/sdk/docs/man/xhtml/glVertexAttrib.xml mentions
the desktop OpenGL semantics briefly at the bottom of the Description
section, but it doesn't explicitly mention that if you don't enable
vertex attribute 0 as an array that you don't get any rendered output.

See http://src.chromium.org/viewvc/chrome/trunk/src/gpu/command_buffer/service/gles2_cmd_decoder.cc?view=markup
, GLES2DecoderImpl::SimulateAttrib0, for an example of how this can be
emulated.

-Ken

On Wed, Aug 11, 2010 at 2:14 PM, Vladimir Vukicevic
<vladimir@mozilla.com> wrote:
> I'm trying to find the description of GL ES 2.0 behaviour for attrib 0 -- what section is it in?
>
>    - Vlad
>
> ----- Original Message -----
>> 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: