[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] vertexAttribPointer conformance test
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: