Hi all,
Does someone have an example patch of vertex_array that provides a 2D grid of configurable size where the opacity of each vertex can be controlled through a message?
I'm doing a fresh co of vertex_array because I had trouble with my cvs update -r vertex_array of the gem main branch. (ie the vertex_ objects did not work!)
something like this I guess:
gemhead | vertex_grid ?? | vertex_color?? | vertex_draw ??
Thanks all!
b>
Hey again.
Well it seems my fresh vertex_array checkout is not helping with compiling on OSX. The build system clearly does not match the new autoconf one. Anyhow:
./configure make
pd -lib Gem
Does not allow me to create "vertex_draw" or "vertex_color" objects.. I'm inclined to think no one has compiled the vertex_array stuff on linux for some time. Johannes, could you give it a try for me?
Thanks!
b>
B. Bogart wrote:
Hi all,
Does someone have an example patch of vertex_array that provides a 2D grid of configurable size where the opacity of each vertex can be controlled through a message?
I'm doing a fresh co of vertex_array because I had trouble with my cvs update -r vertex_array of the gem main branch. (ie the vertex_ objects did not work!)
something like this I guess:
gemhead | vertex_grid ?? | vertex_color?? | vertex_draw ??
Thanks all!
b>
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Quoting "B. Bogart" ben@ekran.org:
Hey again.
Well it seems my fresh vertex_array checkout is not helping with compiling on OSX. The build system clearly does not match the new autoconf one. Anyhow:
yes the new autoconf (in Gem/src instead of Gem/src/Gnu) has no notion of the vertex_array. in theory you just need to add "Vertex" to the GEM_TARGETS in Make.config (after configure), but i have no way to test this right now.
so i gues it is really time to make the vertex_array stuff ready for the main branch (even if there are different types for color/vertex/texcoord/...; this could be changed later on if need is at hand; or do costy conversions between those arrays at the user's own choice)
mfg.asdr IOhannes
Hi all,
I made a few efforts but the biggest issue is that I don't know what the vertex array stuff has changed. I copied all the vertex array files from the vertex_array branch into the main branch. Actually Base/Vertex/* and Base/GemVertex.* . I thought that was going to do it until:
GemCache has no member named vertexDirty
So I copied Base/GemSate.* and Base/GemCache*
Now compiling fails with:
GemglActiveTextureARB.cpp: glActiveTextureARB undeclared
GemglActiveTextureARB.cpp seems to only exist in the main branch, even though the vertex_array branch has a Base/openGL directory.
removing openGL from the Make.config results is a whole bunch of undeclared gl*ARB functions in Vertex/
So I give up.
Looks like merging vertex_array into main is just beyond my ability!
B.
zmoelnig@iem.at wrote:
Quoting "B. Bogart" ben@ekran.org:
Hey again.
Well it seems my fresh vertex_array checkout is not helping with compiling on OSX. The build system clearly does not match the new autoconf one. Anyhow:
yes the new autoconf (in Gem/src instead of Gem/src/Gnu) has no notion of the vertex_array. in theory you just need to add "Vertex" to the GEM_TARGETS in Make.config (after configure), but i have no way to test this right now.
so i gues it is really time to make the vertex_array stuff ready for the main branch (even if there are different types for color/vertex/texcoord/...; this could be changed later on if need is at hand; or do costy conversions between those arrays at the user's own choice)
mfg.asdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
hmmm,
...welcome back IOhannes! Hope ya had a good break: I'm still looking for one myself :-\
On Aug 16, 2005, at 10:09 AM, zmoelnig@iem.at wrote:
Quoting "B. Bogart" ben@ekran.org:
Hey again.
Well it seems my fresh vertex_array checkout is not helping with compiling on OSX. The build system clearly does not match the new autoconf one. Anyhow:
yes the new autoconf (in Gem/src instead of Gem/src/Gnu) has no notion of the vertex_array. in theory you just need to add "Vertex" to the GEM_TARGETS in Make.config (after configure), but i have no way to test this right now.
so i gues it is really time to make the vertex_array stuff ready for the main branch (even if there are different types for color/vertex/ texcoord/...; this could be changed later on if need is at hand; or do costy conversions between those arrays at the user's own choice)
...yeh, ben, you've opened an unfinished project, so proceed very carefully! When last we left (as I recall), IOhannes, chris, and I were bickering about IOhannes' latest change to the vertex_array branch: he had made all "arrays" equal at 4 floats: the idea being that we can then plug anything into anything and let someone else sort it out later...
...chris and I didn't (and I presume still don't) like this, firstly because there's no such thing as a 4 element normal, texcoord, color, etc....as a matter of fact, only vertices can have 4 elements...so, you're put in the position of potentially doubling the amount of data being used, potentially for some undefined flexibility...
...the whole matter was left there when IOhannes said "show me some numbers" about how big a slowdown we're talking about, and I never got around to actually doing that...
...I guess until the benchmarks are done and we can all fall on one side or the other, I'd like to point out that if we use vertex buffer objects (or any kind of buffer objects), and we do want to use them, it should be noted that you can't map a buffer for 4 elements to two...maybe can't is too harsh a word: let's say that it's experimental at best, and expects alot from the gl driver, especially considering we're dealing with multiple platforms, gpus, etc...
ok? jamie
*sigh*
Anyone have any hints for creating a curve3d (draw control) like plane of faces where the alpha of each vertex can be controlled?
I could dynamic patch an array of squares, or polygons but then I would need to use some fancy pix_coordinate stuff so that I can create the illusision that the array of objects is textured with one seamless image..
I suppose I could mess with some crazy pyext/numarray stuff to control pix_data.... that is probably slowwwww.
320x240 squares or polys or pixels would be a ok starting point.
Of course I could make this an opportunity to try the GL wrappers...
Thanks for jumping in Jamie, I was not aware of the conflicts. Maybe we should have a gem-dev meeting on #dataflow?
B.
james tittle wrote:
hmmm,
...welcome back IOhannes! Hope ya had a good break: I'm still looking for one myself :-\
On Aug 16, 2005, at 10:09 AM, zmoelnig@iem.at wrote:
Quoting "B. Bogart" ben@ekran.org:
Hey again.
Well it seems my fresh vertex_array checkout is not helping with compiling on OSX. The build system clearly does not match the new autoconf one. Anyhow:
yes the new autoconf (in Gem/src instead of Gem/src/Gnu) has no notion of the vertex_array. in theory you just need to add "Vertex" to the GEM_TARGETS in Make.config (after configure), but i have no way to test this right now.
so i gues it is really time to make the vertex_array stuff ready for the main branch (even if there are different types for color/vertex/ texcoord/...; this could be changed later on if need is at hand; or do costy conversions between those arrays at the user's own choice)
...yeh, ben, you've opened an unfinished project, so proceed very carefully! When last we left (as I recall), IOhannes, chris, and I were bickering about IOhannes' latest change to the vertex_array branch: he had made all "arrays" equal at 4 floats: the idea being that we can then plug anything into anything and let someone else sort it out later...
...chris and I didn't (and I presume still don't) like this, firstly because there's no such thing as a 4 element normal, texcoord, color, etc....as a matter of fact, only vertices can have 4 elements...so, you're put in the position of potentially doubling the amount of data being used, potentially for some undefined flexibility...
...the whole matter was left there when IOhannes said "show me some numbers" about how big a slowdown we're talking about, and I never got around to actually doing that...
...I guess until the benchmarks are done and we can all fall on one side or the other, I'd like to point out that if we use vertex buffer objects (or any kind of buffer objects), and we do want to use them, it should be noted that you can't map a buffer for 4 elements to two...maybe can't is too harsh a word: let's say that it's experimental at best, and expects alot from the gl driver, especially considering we're dealing with multiple platforms, gpus, etc...
ok? jamie
B. Bogart wrote:
Hey again.
Well it seems my fresh vertex_array checkout is not helping with compiling on OSX. The build system clearly does not match the new autoconf one. Anyhow:
./configure make
pd -lib Gem
Does not allow me to create "vertex_draw" or "vertex_color" objects.. I'm inclined to think no one has compiled the vertex_array stuff on linux for some time. Johannes, could you give it a try for me?
yes, i am just compiling (don't get much problems); i will update the vertex_array branch to match the current MAIN-branch.
apart from that: jamie, i noticed that in src/Vertex there is the code for [fragment_program] and [vertex_program]. Should we move these to src/Manips (in HEAD) ?
i mean, while [vertex_program] has some obvious relation to Vertex-manipulation, [fragment_program] does not; furthermore, even [vertex_program] is not really related with the other Vertex-stuff (e.g. the manipulation of user-defined vertex-arrays) but probably this view is just to technical ??
mfg.as.dr IOhanes
Hey all,
Thanks for taking a look at this. Let me know when the vertex_array branch is ready for me to give it a wirl.
There seems to be no vertex_color object, is this not implimented yet or am I missing something obvious. How do a change the alpha value of one vertex? Also I find vertex_grid and vertex_matrix damn confusing. Which one provides a definable grid (2d) of vertex's?
So working yesterday I have a solution to my problem by using pix_coordinate to offset a texture over multiple objects to give the illustion of one single object.
The pix_coordinate reference patch could use some finessing, as it took me and my collaborator hours to figure out how to change the size and offset the rectangular texture on a square. The secret is (in mode 1, repeat 0):
Left Bottom Right Bottom Right Top Left Top
For the 8 arguments to pix_coordinate. So a 640x480 texture yeilds:
0 480 640 480 640 0 0 0
It would be nice if the help patch described the s,t pair thing in more detail.
I'd like to work on it, but would be damn tempted to impliment it using the PDDP template...
B>
IOhannes m zmoelnig wrote:
B. Bogart wrote:
Hey again.
Well it seems my fresh vertex_array checkout is not helping with compiling on OSX. The build system clearly does not match the new autoconf one. Anyhow:
./configure make
pd -lib Gem
Does not allow me to create "vertex_draw" or "vertex_color" objects.. I'm inclined to think no one has compiled the vertex_array stuff on linux for some time. Johannes, could you give it a try for me?
yes, i am just compiling (don't get much problems); i will update the vertex_array branch to match the current MAIN-branch.
apart from that: jamie, i noticed that in src/Vertex there is the code for [fragment_program] and [vertex_program]. Should we move these to src/Manips (in HEAD) ?
i mean, while [vertex_program] has some obvious relation to Vertex-manipulation, [fragment_program] does not; furthermore, even [vertex_program] is not really related with the other Vertex-stuff (e.g. the manipulation of user-defined vertex-arrays) but probably this view is just to technical ??
mfg.as.dr IOhanes
On Aug 19, 2005, at 8:26 AM, IOhannes m zmoelnig wrote:
yes, i am just compiling (don't get much problems); i will update the vertex_array branch to match the current MAIN-branch.
apart from that: jamie, i noticed that in src/Vertex there is the code for [fragment_program] and [vertex_program]. Should we move these to src/Manips (in HEAD) ?
i mean, while [vertex_program] has some obvious relation to Vertex-manipulation, [fragment_program] does not; furthermore, even [vertex_program] is not really related with the other Vertex-stuff (e.g. the manipulation of user-defined vertex-arrays) but probably this view is just to technical ??
...yeh, I don't know what that's about, it's been awhile...I do remember not knowing where to put them, so maybe Manips would be ok, even more appropriate...together they can replace the render pipeline (and only work on the gpu, not the cpu), so that seems like a "Manips"-ulation...but they haven't been tested much lately, as I have mostly fooled around with the arb_programs stuff via the opengl wrappers...
...otoh, are you still believing we should have 4 elements for all vertex_* components (ie. vertex, normal, color, texcoord, etc)? If we can get over that hump, it's probably ready to go into HEAD...
l8r, jamie
james tittle wrote:
On Aug 19, 2005, at 8:26 AM, IOhannes m zmoelnig wrote:
...yeh, I don't know what that's about, it's been awhile...I do remember not knowing where to put them, so maybe Manips would be ok, even more appropriate...together they can replace the render pipeline (and only work on the gpu, not the cpu), so that seems like a "Manips"-ulation...
ok, i'll move them over to Manips then.
...otoh, are you still believing we should have 4 elements for all vertex_* components (ie. vertex, normal, color, texcoord, etc)? If we can get over that hump, it's probably ready to go into HEAD...
well, i do still believe that a generic approach would be better.
but honestly, i think it is more important to get the Vertex-array stuff into MAIN than to get my ideas about those arrays accepted by all.
however, i still think that there should be only one object for each modification, such as [vertex_set] can set vertex, color, ... (btw: ben, this is most likely what you are looking for)
whether the arrays are all 4-elements floating point or not is something that should be of no concern to the user.
do we agree on that ?
mfg.asd.r IOhannes
I don't agree at all. It doesn't make any sense to have the arrays with sizes that do not fit the data type. I think the usefulness of switching vertex with color or normal data is very minor and it simply won't work without translating that data any way.
Vertex data can be of any range for x,y,z,w, but color and texcoods range from 0..1. Plus, the texcoords are only two elements so how do you reconcile that? Have the results of cramming one data type into the other even been proven effective at all?
The user should know what that data format is or else they will be feeding four elements to an object manipulating texcoords or normals and wondering why in the hell only two or three values do anything. I intended these objects to be a more advanced set of tools for those who have hit the limit of static geometry, and it's not unreasonable to expect someone to know the basics of 3D and OpenGL at that point.
The idea to have a single object that works on all of the data types is a good one. There's no reason these objects cannot take an argument or message to set the array to be manipulated and the object then choosing the right loop to run.
Honestly, I vote for no vertex data objects at all over forcing the data into inappropriate containers. I would just change the objects back to the proper formats for my own use which is what I'm doing now.
cgc
On Aug 19, 2005, at 10:04 AM, IOhannes m zmoelnig wrote:
well, i do still believe that a generic approach would be better.
whether the arrays are all 4-elements floating point or not is something that should be of no concern to the user.
do we agree on that ?
hi.
????
On Aug 19, 2005, at 10:04 AM, IOhannes m zmoelnig wrote:
well, i do still believe that a generic approach would be better.
so this is my personal opinion
whether the arrays are all 4-elements floating point or not is something that should be of no concern to the user.
do we agree on that ?
chris clepper wrote:
I don't agree at all. It doesn't make any sense to have the arrays with sizes that do not fit the data type. I think the usefulness of switching vertex with color or normal data is very minor and it simply won't work without translating that data any way.
that was not the whole point of my arguing.
Vertex data can be of any range for x,y,z,w, but color and texcoods range from 0..1. Plus, the texcoords are only two elements so how do you reconcile that? Have the results of cramming one data type into the other even been proven effective at all?
so whats the exact difference in floating point vertices and color ? both are 4 elements but color is ranged between 0..1 (but as far as i remember there is no _real_ floating point type ranging between 0..1; apart from the hackish GLtypes)
The user should know what that data format is or else they will be feeding four elements to an object manipulating texcoords or normals and wondering why in the hell only two or three values do anything. I intended these objects to be a more advanced set of tools for those who have hit the limit of static geometry, and it's not unreasonable to expect someone to know the basics of 3D and OpenGL at that point.
i was talking rather about the interface. people might also wonder why z does nothing in orthogonal viewing.
what i meant is: people need not be aware how the data is stored in reality: if they are feeding texcoords (to their own good: only two values) they might not care at all, whether the 2 values are stored in a 8-element double array or as 2 integer values (they might care a bit, because of the resulting resolution with the integer values, but that is just the way it is (like 32bit-color is just 32bit color))
from an interfacing poin of view, it remains the same (remember that in pd we only have exactly one data-type: floating point)
The idea to have a single object that works on all of the data types is a good one. There's no reason these objects cannot take an argument or message to set the array to be manipulated and the object then choosing the right loop to run.
hey, great we have at least found something we agree on.
Honestly, I vote for no vertex data objects at all over forcing the data into inappropriate containers. I would just change the objects back to the proper formats for my own use which is what I'm doing now.
so what should i do now ?? apperenty saying that "damned, it is not exactly like i wanted it to be; but hey, for the sake of getting it finally done, i agree to those os-x guys and we should sacrifice the whole one-single-array-type idea and do separate arrays for the various data-types (we _might_ think later about unifying this again, when someone has done a performance test and showed me some numbers)" is not enough for you.
what else should i offer ? do i have to pay you to get your ideas done rather than mine ??
finally, it will be me who will have to change to code back.
mfg.a.sr IOhannes
On Fri, 19 Aug 2005, chris clepper wrote:
Vertex data can be of any range for x,y,z,w, but color and texcoods range from 0..1.
Think of out-of-gamut colours as just like out-of-screen vertices.
Have the results of cramming one data type into the other even been proven effective at all?
What is what you call effective? Cramming is a delightful activity. It's also called databending by some people. To me, it's just everyday business, so i don't even bother calling it names.
Personally, when I want to convert texcoords to colours i just multiply them by a matrix like:
1 0.5 0 0 0.5 1
Which causes y's to be mapped to orange and and x's to some bluish cyan. (my "texcoords" have the y before the x; i'm not doing this with GEM)
____________________________________________________________________ Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju Freelance Digital Arts Engineer, Montréal QC Canada