[GEM-dev] vertex proposals

[James Tittle II]

On Aug 26, 2004, at 12:45 PM, chris clepper wrote:

> Quoting IOhannes m zmoelnig <zmoelnig at iem.at>:
>
>>
>> naively i have assumed that all arrays are of the same dimension, 
>> which
>> is not true; texCoordArray is [Nx2] and normalArray is [Nx3], the rest
>> is [Nx4];
>> this is certainly more memory-efficient.
>>
>> however, i would propose to unify all arrays to [Nx4];
>
> This is not going to work well because OpenGL wants the arrays in very 
> specific
> formatting.  A loop to rearrange arrays before uploading would be a 
> performance
> killer.  In fact, profiling the vertex_ stuff shows that a lot of time 
> is spent
> uploading the data to the card through the driver.  There are 
> supposedly ways
> to DMA this and/or eliminate driver copies, but I haven't gotten them 
> to work.

...I've just gotten the vertex_buffer_object stuff done, so I'm upping 
that into cvs:  this extension is supposed to do the DMA stuff really 
well...I'm also u/l'ing an extra header for compilation on __APPLE__:  
this is only a stop gap until apple gets it's act together and releases 
an updated OpenGL.framework...

...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...

>> why ?
>> 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 
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...?)  Plus, I think we'll have to get 
used to the current layout when dealing with vertex_program...

>> _sources_: OBJ-loader, grid, quad, supershape, random, sphere,...
>> _sinks_: draw, OBJ-exporter
>> _manips_(with only a lefthand gemlist): add(=offset), scale, set,
>> matrix-multiplication, rotation
>> _manips2_(with 2 gemlists): add, mul, set, blend
>> _misc_: info, merge (e.g. take array1 of gemlist1 as color and array4 
>> of
>> gemlist2 as vertex)
>
> That's pretty close to my original list, although I favor having more
> non-standard sources like the supershape rather than the usual Geo 
> primitives.
> The OBJ exporter can use the already provided code we use for 
> importing the
> models.
>
> Also, it is possible to use vertex arrays in display lists, so that 
> might make
> for a nice option.

...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!

jamie