Re: [Public WebGL] vertexAttribPointer conformance test

[Steve Baker <steve@sjbaker.org>]

There is a category of trick/algorithm in which this kind of overlap is
actually useful.  Because each vertex shader 'run' is totally ignorant
of the the other vertices that make up a triangle - some per-triangle
things you'd like to be able to do are tricky.   Sending all three sets
of per-vertex data to each shader run does that...and that makes this
overlapping thing kinda useful.

So if there isn't a really good reason to ban this...we shouldn't.

  -- Steve


On 12/22/2010 04:16 PM, Gregg Tavares (wrk) wrote:
>
>
> On Wed, Dec 22, 2010 at 1:05 PM, Gregg Tavares (wrk) <gman@google.com
> <mailto:gman@google.com>> wrote:
>
>     So I updated the test to test lots of combinations (checked in)
>
>     That brings up more questions about the restrictions added in
>     section 6.3
>
>     1st) "why the restrictions"
>
>         Is there some situation we are trying to prevent that we need
>         to prevent?
>
>
>     2nd) "why not more restrictions"
>
>         As currently specified it's possible to set size = 4, type =
>         byte, stride = 1.  So as input to the shader you'll get
>
>             vec4 (element0,element1,element2,element3)
>
>             vec4 (element1,element2,element3,element4)
>
>             vec4 (element5,element6,element7,element8)
>
>             ...
>
>
> This example was wrong. It should have been
>  
>
>     vec4 (element0,element1,element2,element3)
>
>     vec4 (element1,element2,element3,element4)
>
>     vec4 (element2,element3,element4,element5)
>     ...
>
>
>
>     3rd) "why INVALID_OPERATION"
>
>         wouldn't INVALID_VALUE be more appropriate?
>
>
>

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