things i'd like to discuss
general =======
[vertex_add] (and all other objects i have done so far) can be applied to all 4 arrays; this is, you can add the vertexArray of the lefthand gemlist to the colorArray to the righthand gemlist.
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]; 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") 2) there shouldn't be a problem with memory nowadays. 3) operations on the normalArray is probably faster than with [Nx3] (given that SIMD needs aligned memory) why not ? 1) unifying means the the colorArray would most likely stay float instead of becoming int 2) the texCoordArray doubles
probably it would be best to define just a number of [Nx4] arrays (with no data types at all) [vertex_model] would then load 4 arrays (vertex, color, normals, texcoords), [vertex_draw] would interprete them according to these defaults. simple generators like [vertex_random] would only create one array which could then be assigned to whatever.
objects ======= (just what comes to my mind is useful)
_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)
gosh there were so many; i have forgotten them right now...
mf.a.sdr IOhannes
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. The best advice I can give is to find the best (fastest) array format for GL and stick to it religiously. The vertex_stuff has the potential for some very heavy shit and all of the fat has to be trimmed to make the paths as fast and unencumbered as possible.
Specifics:
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.
- there shouldn't be a problem with memory nowadays.
GEM is very memory efficient, but take a look at what I had to do with vertex_model - there is a cached copy of the model. This could potentially put some strain on memory in certain cases like my Powerbook that has 1GB max RAM, which is even on the high side as far as laptops go.
- operations on the normalArray is probably faster than with [Nx3]
(given that SIMD needs aligned memory)
Honestly, I don't forsee doing a whole lot of normal processing. But take heart, because even though the 96 bit wide data isn't ideal for SIMD it can be dealt with efficiently. Here's how:
while (count < max){
//interleave the float and vector ops
//vector float vertex = vec_madd(vertex,scale,offset);
//vector int color = vec_adds(color,color_offset);
//float normal = normal * scale;
//vector float texcoord = vec_madd();
}
Here the super-scalar architecture would still issue these operations immediately as there would be nothing in the pipeline (ideal case) before them and no dependencies either. The only possible stall would be from a dependency for the texcoord from a vertex op or the vertex op could not be pipelined. Subsequent ops would have to be pipelined as always but at the very least all ops would be issued immediately. Something like a PPC 970 could really crank on this with it's dual FPUs (although the float and int vector units share the same resources which may or may not be problematic).
I think the arrays should remain specific to their data types for the most efficient handling of them. The real-time nature of GEM pretty much demands this.
_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.
cgc
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
hello,
_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)
what about deformation of shape? I mean primitives that can be distorded. I imagine by exemple a primitive that create a vertex array that could move to create sinusoidal oscillation. the aim of this primitive is to be mixed with other shape with somes manips2 object in order to distord a complex model.
or if you prefer mathematics, I imagine primitive creating an array like this : X=0, Y=0, Z=sin(index + time) ; // this is only an exemple this array is not really interesting by itself, but can be used to distord an original model.
does this make sense? or maybe this is useless cause it could already be done with manips object (add, sinus, etc).
Cyrille
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
...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__;
- 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.
IOhannes m zmoelnig wrote:
too. however, __VBO is dead slow (needs 4* more CPU), so i have enabled it only for __APPLE__;
after your last check-ins, things improved by numbers.
however, there is still one problem (at least on my system): when using VBOs, any changes i make to the vertices (e.g. with [vertex_offset]) are not uploaded to the card any-more. is this behavious on all platforms ? since i don't see any apple-specific things i assume so. therefore i have added a vertexDirty flag to GemState (and GemCache...) and rewrote setModified() for GemVertex-objects to set this dirty-flag when apropriate to reschedule the upload.
this works quite well for me (but still might be sub-optimal...)
mfg.a.sdr IOhannes
PS: i have removed all the vertex-objects from Geos/
-
chris clepper -
cyrille henry -
IOhannes m zmoelnig -
James Tittle II