[GEM-dev] vertex_array

[IOhannes m zmölnig]

hi.

????


 > On Aug 19, 2005, at 10:04 AM, IOhannes m zmoelnig wrote:
 >
 >>
 >> well, i do still believe that a generic approach would be better.

so this is my personal opinion

 >>
 >> whether the arrays are all 4-elements floating point or not is something
 >> that should be of no concern to the user.
 >>
 >> do we agree on that ?
 >


chris clepper wrote:
> I don't agree at all.  It doesn't make any sense to have the arrays with 
> sizes that do not fit the data type.   I think the usefulness of 
> switching vertex with color or normal data is very minor and it simply 
> won't work without translating that data any way.

that was not the whole point of my arguing.

> 
> Vertex data can be of any range for x,y,z,w, but color and texcoods 
> range from 0..1.  Plus, the texcoords are only two elements so how do 
> you reconcile that?  Have the results of cramming one data type into the 
> other even been proven effective at all?

so whats the exact difference in floating point vertices and color ? 
both are 4 elements but color is ranged between 0..1 (but as far as i 
remember there is no _real_ floating point type ranging between 0..1; 
apart from the hackish GLtypes)

> 
> The user should know what that data format is or else they will be 
> feeding four elements to an object manipulating texcoords or normals and 
> wondering why in the hell only two or three values do anything.  I 
> intended these objects to be a more advanced set of tools for those who 
> have hit the limit of static geometry, and it's not unreasonable to 
> expect someone to know the basics of 3D and OpenGL at that point.

i was talking rather about the interface.
people might also wonder why z does nothing in orthogonal viewing.

what i meant is: people need not be aware how the data is stored in 
reality: if they are feeding texcoords (to their own good: only two 
values) they might not care at all, whether the 2 values are stored in a 
8-element double array or as 2 integer values (they might care a bit, 
because of the resulting resolution with the integer values, but that is 
just the way it is (like 32bit-color is just 32bit color))

from an interfacing poin of view, it remains the same (remember that in 
pd we only have exactly one data-type: floating point)

> 
> The idea to have a single object that works on all of the data types is 
> a good one.  There's no reason these objects cannot take an argument or 
> message to set the array to be manipulated and the object then choosing 
> the right loop to run.

hey, great we have at least found something we agree on.

> 
> Honestly, I vote for no vertex data objects at all over forcing the data 
> into inappropriate containers.  I would just change the objects back to 
> the proper formats for my own use which is what I'm doing now.
> 

so what should i do now ??
apperenty saying that "damned, it is not exactly like i wanted it to be; 
but hey, for the sake of getting it finally done, i agree to those os-x 
guys and we should sacrifice the whole one-single-array-type idea and do 
separate arrays for the various data-types (we _might_ think later about 
unifying this again, when someone has done a performance test and showed 
me some numbers)" is not enough for you.

what else should i offer ? do i have to pay you to get your ideas done 
rather than mine ??

finally, it will be me who will have to change to code back.


mfg.a.sr
IOhannes