On Aug 26, 2004, at 12:45 PM, chris clepper wrote:
Quoting IOhannes m zmoelnig zmoelnig@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 ?
- 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