[GEM-dev] branches: SIMD & vertex-array going MAIN!
james tittle
tigital at mac.com
Tue Dec 14 19:29:03 CET 2004
On Dec 14, 2004, at 10:05 AM, chris clepper wrote:
>
> On Dec 14, 2004, at 3:29 AM, Johannes M Zmoelnig wrote:
>>
>> and i have changed the width of all of the arrays to 4 (this is:
>> x/y/z/w but also u/v/0/0) to make them more uniformly.
> So my vote is that the array widths should go back to there natural
> sizes as the very minor and rare benefits of equal lengths outweigh
> the negatives.
...chris and I talked about this last week at length, and I also
believe that we should not inflate the data to potentially allow
flexibility...
...first off, the original idea of vertex_array was to add a way of
manipulating vertex arrays on the cpu, and optimize the uploading of
the data (as we have with vertex_array_object/vertex_buffer_object)...
...second, the possible data's are not mutually interchangeable: like
chris said, colors will always be upload as 0-1.0, whereas normals and
vertices can be anything +/-...
...third, there are other arrays that haven't been implemented
(SecondaryColor, Index, FogCoord, EdgeFlag): I admit I don't know what
SecondaryColor is really good for, but if we were to inflate each of
these to 4 floats then we're really talking about bloat...
...in essence, I think that it'd be better to have an optimized pathway
to deal with specific data, and let the user massage the data into the
different formats on their own (or provide abstractions or objects that
do this)...
...as far as numbers go, I can try to do some benchmarking next
weekend...
jamie
More information about the GEM-dev
mailing list