[GEM-dev] vertex proposals

[IOhannes m zmoelnig]

> ...there is still a matter of how to go about this (as is, there is a 
> "#define __VBO" at the top of vertex_draw.cpp):  how far back, and with 
> what effort, are we going to support stuff like this?  A third rewrite 
> using ATI & NV's EXT's would be necessary to get support on 
> linux/windo$e cards that don't support EXT_vertex_buffer_object...

fine.
i have moved the files into src/Vertex (i was unclear about this, when i 
was talking about creating the src/Vertex folder; i really think *all* 
vertex-stuff should be in there, even though vertex_draw is somehow a Geo)

after some minor changes it compiles on linux (and most probably windos) 
too. however, __VBO is dead slow (needs 4* more CPU), so i have enabled 
it only for __APPLE__;



>>> 1) i can apply a single processVertex-function to all arrays without
>>> having to know anything about the type of data (this reminds me strongly
>>> of the "generalized 3d shape synthesizer")
>>
>> It's a good idea, but the sacrifice of performance for flexibility 
>> might be far
>> to great to have a usable system in the end.
> 
> ...I agree that we want to keep performance top...also, the shape synth 

i agree that re-arranging would be a bad thing if it really costs so 
much. (i haven't done any testings at all)
i would risk a *small* performance loss, but naturally a 
"performance-killer" could not really be accepted..

from what i understand so far (being no export in DMA at all), the real 
boost with integer-colors would be in having far less memory to move 
from main-mem to the graphics card -> correct ?? (i always thought that 
the fpu-units of modern processors can compete with the integer units)

probably i should get some openGL-profiler (i know there is one for osX; 
but does anybody no one for linux ??)

or could you (chris?) post some numbers of your profilings ?


> is a series of abstractions to deal with shapes, not colors or 
> such...gotta draw the line somewhere when abstracting:  perhaps we need 
> a texture synth?  Conversion abstractions could also help 
> (normal2vertex, color2texcoord...?)

well; when i read glassner's article i really had the impression that it 
was important to not stick some ideas to a specific data-type, e.g. shape.

because we do not know any application that would do anything 
intelligent when rotating color-vectors this does not mean, that there 
are none.



>> Also, it is possible to use vertex arrays in display lists, so that 
>> might make
>> for a nice option.

from what i read it might not ;-) (but this might be old information)

> 
> 
> ...I've also started adding .3ds support, because it seems to be easier 
> to find modeler's that work with it...nice to see we're all excited 
> about this stuff!

this is really cool.