Hi all
I just created a branch called vertex_array in CVS and committed the first set of objects. The only changes to existing files are GemState.h and gemhead.c and the new objects are in the Geos directory. I think I did the tag for the branch correctly, but I was not able to immediately checkout a copy using the -r option; however, cvs update on the existing local files worked fine.
cgc
Hmm, I tried the tag again and apparently I don't have write access to the repository? So at this point I'm not sure if the first tag for the branch worked or not. Maybe this is another wait and see operation with sourceforge?
On Aug 3, 2004, at 11:55 AM, chris clepper wrote:
Hi all
I just created a branch called vertex_array in CVS and committed the first set of objects. The only changes to existing files are GemState.h and gemhead.c and the new objects are in the Geos directory. I think I did the tag for the branch correctly, but I was not able to immediately checkout a copy using the -r option; however, cvs update on the existing local files worked fine.
cgc
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
chris clepper wrote:
Hmm, I tried the tag again and apparently I don't have write access to the repository? So at this point I'm not sure if the first tag for the branch worked or not. Maybe this is another wait and see operation with sourceforge?
actually the code is checked in and branched correctly.
now i'll go and figure how to make gl*APPLE work on other platforms too...
mfg.a.sdr IOhannes
IOhannes m zmoelnig wrote:
now i'll go and figure how to make gl*APPLE work on other platforms too...
ok. it didn't take that long... (but i have added an "#error" for you to make a better "#ifdef" then just "__APPLE__" in the (2) appropriate places)
however, i have changed some things. i added a Base/GemVertex.h (which was probably a bit premature...) i have removed the GemShape-inheritence entirely and used GemBase instead: the only reason for GemShape was (i think...) the drawtype-method for [vertex_draw]; this i have copy'n'pasted. so the objects now only have one inlet (instead of a unused second one), and you cannot pass an unused floatargument any more....
tomorrow i will have a look at what these objects actually do looking forware to this
mfg.a.sdfr IOhannes
IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
now i'll go and figure how to make gl*APPLE work on other platforms too...
ok. it didn't take that long...
took some more time to make it run under windows too. i noticed that the vertex_array branch is really old (pre-0.90); this gave me several problems (as there where some fixes for nvidia-compiles under windows); however it works now.
i have changed following: [vertex_offset] now takes 2(X,Y,0,0), 3(X,Y,Z,0) or 4(X,Y,Z,W) arguments for "offset"; similarily i have changed [color_set] to take 1 (Grey), 3(RGBA) or 4(RGBA) arguments for "color"
i have removed the traces of GemShape in [color_set] too (changed to GemBase)
what i do not understand on [color_set] is a) the name: wouldn't [vertex_color] fit better (to see what it is meant for, like [part_color]) b) the message "number": why is it "number" and not "vertex" as in [vertex_offset] ? i think the 2 are so similiar that 2 different messages for the same behaviour is non-intuitive.
haven't tested [vertex_quad] (crashes, but haven't looked why), [vertex_grid] and [vertex_combine] yet.
mfg.a.sdr IOhannes
hello,
it's working here to on windows.
thanks a lot for this stuff.
it's very interesting!
cyrille
IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
now i'll go and figure how to make gl*APPLE work on other platforms too...
ok. it didn't take that long...
took some more time to make it run under windows too. i noticed that the vertex_array branch is really old (pre-0.90); this gave me several problems (as there where some fixes for nvidia-compiles under windows); however it works now.
i have changed following: [vertex_offset] now takes 2(X,Y,0,0), 3(X,Y,Z,0) or 4(X,Y,Z,W) arguments for "offset"; similarily i have changed [color_set] to take 1 (Grey), 3(RGBA) or 4(RGBA) arguments for "color"
i have removed the traces of GemShape in [color_set] too (changed to GemBase)
what i do not understand on [color_set] is a) the name: wouldn't [vertex_color] fit better (to see what it is meant for, like [part_color]) b) the message "number": why is it "number" and not "vertex" as in [vertex_offset] ? i think the 2 are so similiar that 2 different messages for the same behaviour is non-intuitive.
haven't tested [vertex_quad] (crashes, but haven't looked why), [vertex_grid] and [vertex_combine] yet.
mfg.a.sdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
hi chris. hi all
IOhannes m zmoelnig wrote:
haven't tested [vertex_quad] (crashes, but haven't looked why), [vertex_grid] and [vertex_combine] yet.
both of them crashed instantly on my machines. i have tracked the error down to [vertex_draw] and fixed it there (a missing check for some state-pointer to a float-array)
what i do not understand on [color_set] is a) the name: wouldn't [vertex_color] fit better (to see what it is meant for, like [part_color]) b) the message "number": why is it "number" and not "vertex" as in [vertex_offset] ? i think the 2 are so similiar that 2 different messages for the same behaviour is non-intuitive.
any comments on these ? i would like to release this as soon as possible (to not start releasing for 3 years again...)
would it make sense to put it in a separate directory (just like particles) ??
mfg.as.dr IOhannes
On Aug 10, 2004, at 2:26 AM, IOhannes m zmoelnig wrote:
what i do not understand on [color_set] is a) the name: wouldn't [vertex_color] fit better (to see what it is meant for, like [part_color]) b) the message "number": why is it "number" and not "vertex" as in [vertex_offset] ? i think the 2 are so similiar that 2 different messages for the same behaviour is non-intuitive.
any comments on these ? i would like to release this as soon as possible (to not start releasing for 3 years again...)
would it make sense to put it in a separate directory (just like particles) ??
The idea is to have all of the color manipulations separate from the vertex position ones. So color_set just sets the color value, overwriting the current data, while the not-yet-existing color_scale would multiply the color values by a value (useful for alpha-blending and fading perhaps?). The naming convention would continue to texcoord_scale, normal_set, and so on.
I'm not sold on any set way of handling vertex, color, tex_coord or normal data in GEM, so this is just my first idea.
Also, I should post a few patches that illustrate things like just adjusting a section of the array as well. Oh and the color array/objects should probably be unsigned chars not float, which doesn't affect the resolution one bit but speeds things up by a factor of four.
cgc
mfg.as.dr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
chris clepper wrote:
On Aug 10, 2004, at 2:26 AM, IOhannes m zmoelnig wrote:
what i do not understand on [color_set] is a) the name: wouldn't [vertex_color] fit better (to see what it is meant for, like [part_color]) b) the message "number": why is it "number" and not "vertex" as in [vertex_offset] ? i think the 2 are so similiar that 2 different messages for the same behaviour is non-intuitive.
any comments on these ? i would like to release this as soon as possible (to not start releasing for 3 years again...)
would it make sense to put it in a separate directory (just like particles) ??
The idea is to have all of the color manipulations separate from the vertex position ones. So color_set just sets the color value, overwriting the current data, while the not-yet-existing color_scale would multiply the color values by a value (useful for alpha-blending and fading perhaps?). The naming convention would continue to texcoord_scale, normal_set, and so on.
i think i understand. but the color-manipulations we are talking about apply just to vertex-arrays (?). so what i meant was that i wouldn't have thought that [color_set] did something with the Geo i loaded via [vertex_model] -- to be honest in my first attempt to make the vertex-stuff going i haven't even compiled color_set, because i have only added all the vertex_* files to my makefile.
eventually one could incorporate the [color_set]-features into [color] and [colorRGB] (if a colorArray is present use it, else just call glColor()) - but this would probably be even more confusing. and [color_scale] (which i think is a good idea) would not work at all with "normal" geos.
so what i meant is, that each object that only makes sense in connection with "vertex-data" should be prefixed with a terse identifier (i agree that [vertex_color_set] or even [vertex_texcoord_scale] is a bit clumsy) [vtx_*] might be better (although "vtx" probably needs more time to get familiar with than "vertex")
seeing the as asterisk what about object names like [vtx_color] (for "color_set") [vtx_texcoord*] (for "texcoord_scale") [vtx_color+] (for "color_offset") ?
at least we are not going into such problems as Gem.scale vs maxlib.scale with any of these names.
as for "number"-vs-"vertex"-messages this problem will of course be gone as soon as we create an explicit inlet for this data.
mfg.asd.r IOhannes
On Aug 10, 2004, at 11:35 AM, IOhannes m zmoelnig wrote:
seeing the as asterisk what about object names like [vtx_color] (for "color_set") [vtx_texcoord*] (for "texcoord_scale") [vtx_color+] (for "color_offset") ?
[vertex_color scale] [vertex_color set] might be another way too? Put all of the color, texcoord and normal stuff in a single object for each function. Some of the other vertex_ objects, like [vertex_combine (blend?)], will eventually work on some combination of vertex, normal, color and texcoord data anyway, so that might be a point of confusion as well?
Another idea would be to have more generic objects:
[vertex_scale color] (or [vertex_mult])
[vertex_set vertex]
[vertex_blend texcoord]
[vertex_random normal]
The object would also respond to messages regarding which part (color, normal) of the arrays to work on, and multiple states could possibly be active at once. Maybe this would be both more generic in the hip trend of 'matrix' processing and also still allow for enough focus to make development more streamlined and end use easier? Of course some exceptions would naturally apply that throw the whole thing off.
Hell, maybe we just need to break down and write a GEM specific scripting format! I'm only half-joking about this.
at least we are not going into such problems as Gem.scale vs maxlib.scale with any of these names.
as for "number"-vs-"vertex"-messages this problem will of course be gone as soon as we create an explicit inlet for this data.
mfg.asd.r IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
chris clepper wrote:
On Aug 10, 2004, at 11:35 AM, IOhannes m zmoelnig wrote:
[vertex_color scale] [vertex_color set] might be another way too? Put all of the color, texcoord and normal stuff in a single object for each function.
actually this would be like having a signal-object [~] and a float-object [f] and you could send them messages on how to operate...
not really the paradigm of pd (but hey, we are talking about Gem and not necessarily pd ;-))
Another idea would be to have more generic objects:
[vertex_scale color] (or [vertex_mult]) [vertex_set vertex] [vertex_blend texcoord] [vertex_random normal]
The object would also respond to messages regarding which part (color, normal) of the arrays to work on, and multiple states could possibly be active at once. Maybe this would be both more generic in the hip trend of 'matrix' processing and also still allow for enough focus to make development more streamlined and end use easier? Of course some exceptions would naturally apply that throw the whole thing off.
i like this idea. it is probably simplest to do (in terms of programming) and makes it quite clear what is going on (int terms of patching)
and while i don't think that changing the operation via a message is a good idea (like in [vertex_color scale]), but changing the "channel" (normal, texcoord) sounds fine to me.
Hell, maybe we just need to break down and write a GEM specific scripting format! I'm only half-joking about this.
somebody has asked me to do a [mtx_expr] a while ago (which i consider unnecessary as matrix-elements can well be accessed from pd itself)
this and your half-joking idea leads to [pix_expr] and [vertex_expr]. neat.
mfg.a.sdr IOhannes
On Aug 11, 2004, at 2:14 AM, IOhannes m zmoelnig wrote:
Another idea would be to have more generic objects: [vertex_scale color] (or [vertex_mult]) [vertex_set vertex] [vertex_blend texcoord] [vertex_random normal]
i like this idea. it is probably simplest to do (in terms of programming) and makes it quite clear what is going on (int terms of patching)
Let's go with this idea then.
There might be a need to have some objects that only work with a single data type, which would raise some questions. If I wrote an object that only made sense for colors or texcoords then how would those be distinguished?
this and your half-joking idea leads to [pix_expr] and [vertex_expr]. neat.
For the vertex side, it would probably be best to have predefined 'scripts' in the form of vertex shaders. I think it might be possible to create shaders in some of the high-end 3D apps like Maya now, and it probably won't be too long before some lower end app makes shaders accessible to most. If we could figure out a way to 'compile' a patch into a shader then that would be pretty amazing. I have no idea how to do it though.
cgc
chris clepper wrote:
On Aug 11, 2004, at 2:14 AM, IOhannes m zmoelnig wrote:
Let's go with this idea then.
i have done [vertex_set] [vertex_offset] and [vertex_scale], all of them working on all 4 tables (color still being floating-point though)
i do not know _where_ to check them in ? Geos/ seems to be the wrong place. should we place it into Manips/ or make a seperate Vertex/-directory
i would rather vote for the later, especially when considering jamie's ideas on shape-synthesizers, which would probably fit best into this vertex-stuff. (right now it might look a bit oversized to make a directory for 5 objects...)
mfg..sdr IOhannes
IOhannes m zmoelnig wrote:
i do not know _where_ to check them in ? Geos/ seems to be the wrong place. should we place it into Manips/ or make a seperate Vertex/-directory
so if no one objects within 5 minutes i will create a new module src/Vertex tomorrow. at least if no one objects until tomorrow.
i really think, that there is a potential for a lot of vertex_ objects.
i also want to add [vertex_add] and [vertex_mul] for adding/multiplying 2 vertex arrays. (i have never seen higher maths on objects but a*(x^2)+x really looks cool for x:=venus.obj)
IOhannes
ps: somehow i feel like a nerd, who keeps screaming "i will create a directory" and nobody cares...
Quoting IOhannes m zmoelnig zmoelnig@iem.at:
so if no one objects within 5 minutes i will create a new module src/Vertex tomorrow. at least if no one objects until tomorrow.
Do it! I dare you.
i really think, that there is a potential for a lot of vertex_ objects.
i also want to add [vertex_add] and [vertex_mul] for adding/multiplying 2 vertex arrays. (i have never seen higher maths on objects but a*(x^2)+x really looks cool for x:=venus.obj)
[vertex_add] would be same as [vertex_offset] and [vertex_scale] = [vertex_mul] right? I'm fine with the name changes since the add/mul is probably more informative.
I made the object [vertex_combine] to try and blend between two arrays. I never got around to doing the interpolation for arrays of different sizes however. I think the easiest way is to have a float counter var that's a positive ratio between the two arrays (like 3.33:1) and then coerce it back an int. It's a very crude way to do it, and it has to be scheduled in a way that the processing ops don't stall waiting for the conversion. I'm open to any ideas about interpolation as long as they are fast. ;)
We should discuss the development of the vertex_stuff in more depth. For example, what are some ideas for vertex generation objects? On the one hand, I think vertex_model handles a whole lot of the old static Geos since it's pretty easy to find a model of a sphere or cube, but way more possibilities exist. Check this and tell me that it's not a completely bad-ass, must-have object:
http://astronomy.swin.edu.au/~pbourke/surfaces/supershape3d/
The OSX and Linux apps demonstrate what this is capable of doing. I've sat for hours just pressing the random generation buttons to see what comes out. I really need a trig lesson or three to fully understand what's going on with that formula.
IOhannes
ps: somehow i feel like a nerd, who keeps screaming "i will create a directory" and nobody cares...
Hey, if you give fair warning and get no response then what more can you do?
cgc
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
chris clepper wrote:
[vertex_add] would be same as [vertex_offset] and [vertex_scale] = [vertex_mul] right? I'm fine with the name changes since the add/mul is probably more informative.
no! [vertex_add] and [vertex_offset] are not the same (for now): [vertex_offset] adds a single vector to all vertices. [vertex_add] adds 2 vertex-arrays. [vertex_mul] multiplies 2 vertex-arrays (so you can really "square" a model)
I made the object [vertex_combine] to try and blend between two arrays. I never got around to doing the interpolation for arrays of different sizes however. I
which is what has inspired me for [vertex_add] and the like
think the easiest way is to have a float counter var that's a positive ratio between the two arrays (like 3.33:1) and then coerce it back an int. It's a very crude way to do it, and it has to be scheduled in a way that the processing ops don't stall waiting for the conversion. I'm open to any ideas about interpolation as long as they are fast. ;)
right now they are hard casts to integer. it was fastest to write (not to execute). i have no objections to any speed up too...
We should discuss the development of the vertex_stuff in more depth. For example, what are some ideas for vertex generation objects? On the one hand, I think vertex_model handles a whole lot of the old static Geos since it's pretty
one of my alltime favourites is of course, grabbing data from pd's offers: mapping signals to vertices (i have done some 3d spectral visualisation (normal "scientific" waterfall-plots) just this week with [pix_sig2pix~] and [imageVert] and it was kindof slow) and mapping tables to vertices.
these will be very generic solutions
easy to find a model of a sphere or cube, but way more possibilities exist. Check this and tell me that it's not a completely bad-ass, must-have object:
ok. we'll do it ;-)
mfg.ads.hzt IOhannes
On Thu, 26 Aug 2004, IOhannes m zmoelnig wrote:
one of my alltime favourites is of course, grabbing data from pd's offers: mapping signals to vertices (i have done some 3d spectral visualisation (normal "scientific" waterfall-plots) just this week with [pix_sig2pix~] and [imageVert] and it was kindof slow) and mapping tables to vertices.
these will be very generic solutions
I had done that 4 years ago with the (original?) sig2pix external that I wrote. It was fast. It was not very general though ... Just found it amusing ... back to lurker state.
Guenter
easy to find a model of a sphere or cube, but way more possibilities exist. Check this and tell me that it's not a completely bad-ass, must-have object:
ok. we'll do it ;-)
mfg.ads.hzt IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
guenter geiger wrote:
I had done that 4 years ago with the (original?) sig2pix external that I wrote. It was fast. It was not very general though ...
the sig2pix hasn't changed much since (at least i don't think that performance has decreased) i haven't done any profiling, but i think a lot of CPU-power is wasted while casting from float to int and back again, and when getting the luminance of the image to map to vertices. performance isn't *that* bad, bit i thought it could be better.
i don't think that conversion to pixes and then to vertices is optimal.
Just found it amusing ... back to lurker state.
mfg.asr IOhannes
On Thu, 26 Aug 2004, IOhannes m zmoelnig wrote:
guenter geiger wrote:
I had done that 4 years ago with the (original?) sig2pix external that I wrote. It was fast. It was not very general though ...
the sig2pix hasn't changed much since (at least i don't think that performance has decreased)
Ah, sorry then. I have to admit that I haven't used that for a long time, and I could vaguely remember that in order to get a waterfall display with the new pix2sig you had to use a large blocksize with overlap, which in theory should reduce the performance "overlap" times. But maybe I am talking nonsense here.
Guenter
i haven't done any profiling, but i think a lot of CPU-power is wasted while casting from float to int and back again, and when getting the luminance of the image to map to vertices. performance isn't *that* bad, bit i thought it could be better.
i don't think that conversion to pixes and then to vertices is optimal.
Just found it amusing ... back to lurker state.
mfg.asr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
guenter geiger wrote:
Ah, sorry then. I have to admit that I haven't used that for a long time, and I could vaguely remember that in order to get a waterfall display with the new pix2sig you had to use a large blocksize with overlap, which in theory should reduce the performance "overlap" times.
i don't quite understand the last sentence.
however you are right; [pix_sig2pix~] uses huge blocks which will get peaks in performance.
mfg.ca.srtz IOhannes
On Thu, 26 Aug 2004 zmoelnig@iem.at wrote:
Ah, sorry then. I have to admit that I haven't used that for a long time, and I could vaguely remember that in order to get a waterfall display with the new pix2sig you had to use a large blocksize with overlap, which in theory should reduce the performance "overlap" times.
i don't quite understand the last sentence.
hmm, thats probably because it isn't really understandable, sorry :(
I really can't remember exactly, but I had the feeling that in order to achieve the waterfall effect you had to use a certain overlap factor. This makes it slow. I don't think that the conversion from float to int at a rate of 44kHz can do the performance much harm.
On the other site, the original sig2pix external was optimised for just doing that, a waterfall. This was done by having a buffer twice as large as the image and filling this with the audio data, line per line. Each time a new line was added, the image scrolled by one line. This was done by repositioning the image pointer only. Each turn around there was an additional copy of the whole image.
Well, probably something like this should be called pix_waterfall~ already.
Guenter
however you are right; [pix_sig2pix~] uses huge blocks which will get peaks in performance.
mfg.ca.srtz IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
Quoting IOhannes m zmoelnig zmoelnig@iem.at:
no! [vertex_add] and [vertex_offset] are not the same (for now): [vertex_offset] adds a single vector to all vertices. [vertex_add] adds 2 vertex-arrays. [vertex_mul] multiplies 2 vertex-arrays (so you can really "square" a model)
Oh I get it... Good thing at least one of us is paying attention.
right now they are hard casts to integer. it was fastest to write (not to execute). i have no objections to any speed up too...
There's an Altivec op that changes floats to ints without the memory access. I might try to build a loop to fill an array of indexes (wild stuff) if the counter conversions become problematic. I think proper scheduling of the conversion one loop iteration or more ahead will alleviate most problems.
countint = (int) countf;
while (countint < maxcount){ //adjust to keep the counter in the right place for the next iteration nextcount = (int)countf + interval;
//do stuff
countint = nextcount; }
Any super-scalar machine with decent OOOE will be able to handle this without stalls. If the code is all vector ops then there will be no reason for stalls in the floating point unit either.
one of my alltime favourites is of course, grabbing data from pd's offers: mapping signals to vertices (i have done some 3d spectral visualisation (normal "scientific" waterfall-plots) just this week with [pix_sig2pix~] and [imageVert] and it was kindof slow) and mapping tables to vertices.
Personally, I've never been a fan of direct mapping of audio to image data or vice-versa. Instead I extract some useful element of the audio/video to use as control data. The kids really love the direct mapping from what I hear, as it's apparently a major selling point of some commercial video objects for Max that will remain nameless. ;)
I'm all for working on these objects - I might be convinced of their usefulness some day.
cgc
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
On Aug 25, 2004, at 12:08 PM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
i do not know _where_ to check them in ? Geos/ seems to be the wrong place. should we place it into Manips/ or make a seperate Vertex/-directory
so if no one objects within 5 minutes i will create a new module src/Vertex tomorrow. at least if no one objects until tomorrow.
...I don't object ;-)
i really think, that there is a potential for a lot of vertex_ objects.
i also want to add [vertex_add] and [vertex_mul] for adding/multiplying 2 vertex arrays. (i have never seen higher maths on objects but a*(x^2)+x really looks cool for x:=venus.obj)
...ok, so i finally got around to grabbing this branch, and after a bit of customizing to my dev environment, I ran into your warning for "# error please replace __APPLE__ by something more specific; JMZ "...there seems to be a coupla ways around this:
1. as is is ok for apple, but to get similar behavior on other systems, use ATI_vertex_array_object and/or NV_vertex_array_object? This seems to be a tower of babel situation...
2. change to ARB_vertex_buffer_object...this extension is newly supported on 10.3.4+, but isn't in the OpenGL.framework: however, it's trivially easy to hack around this and create your own vbo.h with the correct defs:
#include <stdint.h> #include <OpenGL/gl.h>
#ifdef __cplusplus extern "C" { #endif
typedef intptr_t GLintptrARB; typedef uintptr_t GLsizeiptrARB;
extern void glBindBufferARB(GLenum target, GLuint buffer); extern void glDeleteBuffersARB(GLsizei n, const GLuint *buffers); extern void glGenBuffersARB(GLsizei n, GLuint *buffers); extern GLboolean glIsBufferARB(GLuint buffer);
extern void glBufferDataARB(GLenum target, GLsizeiptrARB size, const GLvoid *data, GLenum usage); extern void glBufferSubDataARB(GLenum target, GLintptrARB offset, GLsizeiptrARB size, const GLvoid *data); extern void glGetBufferSubDataARB(GLenum target, GLintptrARB offset, GLsizeiptrARB size, GLvoid *data);
extern void *glMapBufferARB(GLenum target, GLenum access); extern GLboolean glUnmapBufferARB(GLenum target);
extern void glGetBufferParameterivARB(GLenum target, GLenum pname, GLint *params); extern void glGetBufferPointervARB(GLenum target, GLenum pname, GLvoid **params);
#define GL_ARRAY_BUFFER_ARB 0x8892 #define GL_ELEMENT_ARRAY_BUFFER_ARB 0x8893
#define GL_ARRAY_BUFFER_BINDING_ARB 0x8894 #define GL_ELEMENT_ARRAY_BUFFER_BINDING_ARB 0x8895 #define GL_VERTEX_ARRAY_BUFFER_BINDING_ARB 0x8896 #define GL_NORMAL_ARRAY_BUFFER_BINDING_ARB 0x8897 #define GL_COLOR_ARRAY_BUFFER_BINDING_ARB 0x8898 #define GL_INDEX_ARRAY_BUFFER_BINDING_ARB 0x8899 #define GL_TEXTURE_COORD_ARRAY_BUFFER_BINDING_ARB 0x889A #define GL_EDGE_FLAG_ARRAY_BUFFER_BINDING_ARB 0x889B #define GL_SECONDARY_COLOR_ARRAY_BUFFER_BINDING_ARB 0x889C #define GL_FOG_COORDINATE_ARRAY_BUFFER_BINDING_ARB 0x889D #define GL_WEIGHT_ARRAY_BUFFER_BINDING_ARB 0x889E
#define GL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB 0x889F
#define GL_STREAM_DRAW_ARB 0x88E0 #define GL_STREAM_READ_ARB 0x88E1 #define GL_STREAM_COPY_ARB 0x88E2 #define GL_STATIC_DRAW_ARB 0x88E4 #define GL_STATIC_READ_ARB 0x88E5 #define GL_STATIC_COPY_ARB 0x88E6 #define GL_DYNAMIC_DRAW_ARB 0x88E8 #define GL_DYNAMIC_READ_ARB 0x88E9 #define GL_DYNAMIC_COPY_ARB 0x88EA
#define GL_READ_ONLY_ARB 0x88B8 #define GL_WRITE_ONLY_ARB 0x88B9 #define GL_READ_WRITE_ARB 0x88BA
#define GL_BUFFER_SIZE_ARB 0x8764 #define GL_BUFFER_USAGE_ARB 0x8765 #define GL_BUFFER_ACCESS_ARB 0x88BB #define GL_BUFFER_MAPPED_ARB 0x88BC
#define GL_BUFFER_MAP_POINTER_ARB 0x88BD
#ifdef __cplusplus } #endif
...ok, so the vertex_buffer_object is fairly new, but seems better supported on linux/windoze (at least on recent graphics boards)...as far as I can tell on apple, the two paths a similar, with the exception that the vao is supported back to 10.2 and vbo is only 10.3.4+?
...any preferences? jamie
James Tittle II wrote:
On Aug 25, 2004, at 12:08 PM, IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote: i do not know _where_ to check them in ? Geos/ seems to be the wrong place. should we place it into Manips/ or make a seperate Vertex/-directory so if no one objects within 5 minutes i will create a new module src/Vertex tomorrow. at least if no one objects until tomorrow....I don't object ;-)
ah. probably some misunderstanding.
i have thought of *moving* the old objects from Geos to Vertex
i see that you have now changed the [vertex_draw] in Geos. i will eventually move these changes to Vertex/ and REmove the vertex-objects from other directories.
mfg.a.sdr IOhannes
-
chris clepper -
cyrille henry -
guenter geiger -
IOhannes m zmoelnig -
James Tittle II -
zmoelnig＠iem.at