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

Re: [Public WebGL] Problems with vertexAttrib4fv



Ah right, I had the GL/GL ES differences backwards.  Argh, I thought we already handled this, but I guess not.  Will fix!

    - Vlad

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