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

Re: [Public WebGL] vertexAttribPointer conformance test



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: