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

Re: [Public WebGL] vertexAttribPointer conformance test



Ah - yes, of course!  I was thinking that the "skip" amount was elements -
not bytes, but of course that can't be right.

OK - then I have no problem with the first example being illegal.

Thanks!

  -- Steve

> Hmm, I don't think the two cases are what you think they are... the size
> is in elements, not in bytes.  For the first one, we're saying "this
> attribute has 3 floats, and then skip 2 bytes to get to the next set of
> 3".  That would result in the second set of 3 being aligned incorrectly.
> The second example I gave is what your first case -- with overlap (4 bytes
> would only skip the first of the 3 float elements).  I don't believe we're
> preventing either of the two variations you describe.
>
>     - Vlad
>
> ----- Original Message -----
>> I've seen both variations used to good effect in desktop OpenGL and
>> Direct3D - and afaik, both are legal.
>>
>> The first one (where the attributes overlap each other) does have a
>> few
>> uses - but they are pretty bizarre and I don't think many people would
>> be too upset if it wasn't allowed.
>>
>> The second (where the data has gaps) is essential to a couple of
>> strategies for handling large area terrain skins and some
>> level-of-detail mechanisms.
>>
>> Loss of the first isn't disasterous if it can't be implemented - but
>> loss of the second would be very bad news.
>>
>> -- Steve
>>
>> On 01/05/2011 06:50 PM, Vladimir Vukicevic wrote:
>> > I think some of these changes are wrong -- I agree that we should
>> > disallow (and I believe we already do and check for):
>> >
>> >   size = 3, type = FLOAT, stride = 2
>> >
>> > but I do not think that we should disallow
>> >
>> >   size = 3, type = FLOAT, stride = 4
>> >
>> > which the test currently does... the result here is perfectly valid,
>> > from my reading of the spec.
>> >
>> >      - Vlad
>> >
>> > ----- Original Message -----
>> >
>> >> 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 (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:
>> >
>> >
> -----------------------------------------------------------
> 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:
unsubscribe public_webgl
-----------------------------------------------------------