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

Re: [Public WebGL] Problems with vertexAttrib4fv



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: