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

Re: [Public WebGL] Problems with vertexAttrib4fv



Hmm

I suspect this may be an ATI issue. I added the following line:


gl.bindAttribLocation(shaderProgram, ATTR_INDEX_POSITION, ATTR_POSITION);

where ATTR_INDEX_POSITION = 0 and ATTR_POSITION = "a_position"

between attaching the shaders and linking the program and it all burst into life on the aforementioned linux box. I'll just double check it on the windows setup. Incidentally, the 'color' index is now 1 (was 0 before is 2 on nvidia)

I realize of course that this is a workaround, but at least I can get on with my stuff. Happy to continue debugging the original problem, because the way I see it Ken is right, I shouldn't have to do what I've done above.


Alan




On 08/11/2010 02:33 PM, Kenneth Russell wrote:
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: