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.
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?
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.
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.
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.
cgc
On Aug 19, 2005, at 10:04 AM, IOhannes m zmoelnig wrote:
well, i do still believe that a generic approach would be better.
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 ?