[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