Hey,
Any chance of some more info on how this might work? Would there be a new object to apply any transformation to vertex positions and colours, or would it be based on getting and setting arrays? I think both could be quite useful, with the 'transform-vertex' (or whatever) object being (presumably) more efficient and ok for simpler stuff, and arrays for anything more complicated.
Sorry for all the questions, but this sounds just like what GEM is currently lacking (for my needs). Sorry if any of this has been answered: I haven't been able to find much about it.
Cheers, Stefan
Message: 14 To: timon botez timon@sosolimited.com Subject: Re: [PD] Gem .OBJ quest. Date: Fri, 02 Jan 2004 10:13:44 -0600 (CST) From: cgc@humboldtblvd.com Cc: pd-list@iem.at
Hi
Per vertex manipulation of models is not possible with the current version of GEM, but I have written a new way of rendering models and 3D objects that will allow exactly this. I was hoping to have it ready to go by the first of the year but that hasn't happened. Look for something in the next few months.
cgc
Quoting timon botez timon@sosolimited.com:
Halo, another Gem q. Does anyone know if there is a way to access the
polygons on a imported
.obj file? Im drying to distort a model over time and has no
idea how to go about
it.
Any clues are welcome HNY
Timon.
PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list
___________________________________________________________ WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards www.yahoo.co.uk/internetcafes
On Mar 30, 2004, at 8:36 AM, Stefan Turner wrote:
Hey,
Any chance of some more info on how this might work? Would there be a new object to apply any transformation to vertex positions and colours, or would it be based on getting and setting arrays? I think both could be quite useful, with the 'transform-vertex' (or whatever) object being (presumably) more efficient and ok for simpler stuff, and arrays for anything more complicated.
Nothing about vertex arrays is set at this point. Right now it's just a collection of objects on my HD that I'm trying to make into a coherent set of tools for 'dynamic geometry'. The current idea is to have a set of vertex generators like a grid or a .obj model loader and a set of vertex manipulators for color, position and so on. The idea is to process vertex, color, normal and texture coordinate data just like pixels or audio. Pd/GEM is not a very effective environment for representing large data sets to the user, so very fine editing of the data might not be all that possible. The goal is to have a way to algorithmically alter geometry over time - think about something like newwave or Cyrille's pmpd applied any model you load into GEM and you start to get the idea. There will probably be lots and lots of of problems to solve before these objects become all that useful.
Sorry for all the questions, but this sounds just like what GEM is currently lacking (for my needs). Sorry if any of this has been answered: I haven't been able to find much about it.
By all means let us know what you find lacking about GEM. The past year has been spent getting 'the basics' on each platform up to par and improving performance and stability. Now it's time to get some really interesting things going.
cgc
Cheers, Stefan
Chris,
Thanks for the reply. If it's of any use, an idea I had for transforming vertex positions and colours is just something like:
[gemhead]
|
| [1.2\ [3.4
| | |
[transform-vertex $fx $fy+$f1 $fz*$f2]
|
[model whatever.obj]
where 'transform-vertex' takes any number of floats referenced $f1, $f2...etc (like expr: apologies if I got the syntax wrong, I don't have pd on this computer) and has $fx,$fy,$fz for the current vertex coords. The example above would therefore shift by 1.2 in the y axis and scale by 3.4 in the z axis. A similar thing could be done with colours. I think even though this is quite simple it would do for many applications.
This could be more useful in conjunction with a 'gem-moses' which would act as two 'separators', the relevant one being chosen depending upon the vertex position, or something along these lines. (I am not sure if this would work as I know nothing about how Gem builds the rendering network etc.)
I would try to code these myself but I don't think I am up to doing externals yet... Anyway these are just ideas and I'm sure you have something similar going on. Good luck and make sure you tell us all when you've got something!
Cheers Stefan.
--- chris clepper cgc@humboldtblvd.com wrote: > On Mar 30, 2004, at 8:36 AM, Stefan Turner wrote:
Hey,
Any chance of some more info on how this might
work?
Would there be a new object to apply any transformation to vertex positions and colours, or would it be based on getting and setting arrays? I think both could be quite useful, with the 'transform-vertex' (or whatever) object being (presumably) more efficient and ok for simpler
stuff,
and arrays for anything more complicated.
Nothing about vertex arrays is set at this point. Right now it's just a collection of objects on my HD that I'm trying to make into a coherent set of tools for 'dynamic geometry'. The current idea is to have a set of vertex generators like a grid or a .obj model loader and a set of vertex manipulators for color, position and so on. The idea is to process vertex, color, normal and texture coordinate data just like pixels or audio. Pd/GEM is not a very effective environment for representing large data sets to the user, so very fine editing of the data might not be all that possible. The goal is to have a way to algorithmically alter geometry over time - think about something like newwave or Cyrille's pmpd applied any model you load into GEM and you start to get the idea. There will probably be lots and lots of of problems to solve before these objects become all that useful.
Sorry for all the questions, but this sounds just
like
what GEM is currently lacking (for my needs).
Sorry if
any of this has been answered: I haven't been able
to
find much about it.
By all means let us know what you find lacking about GEM. The past year has been spent getting 'the basics' on each platform up to par and improving performance and stability. Now it's time to get some really interesting things going.
cgc
Cheers, Stefan
___________________________________________________________ WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards www.yahoo.co.uk/internetcafes
On Mar 31, 2004, at 7:52 AM, Stefan Turner wrote:
Chris,
Thanks for the reply. If it's of any use, an idea I had for transforming vertex positions and colours is just something like:
[gemhead] | | [1.2\ [3.4
| | | [transform-vertex $fx $fy+$f1 $fz*$f2] | [model whatever.obj]
It's actually even simpler than that right now:
[gemhead] | [vertex_model my.obj] | | 1.0 0.5 2.0 range 100 1200 | | | [vertex_offset] | [color_scale 1 1 1 .5] | [vertex_draw]
This chain will open a .obj model then offset vertices 100 to 1200 by 1.0,0.5,2.0 and then adjust the alpha to 50 for the entire array. I have no idea if this will even be the final structure of the vertex arrays, but it should give you an idea of where it's headed. Serious development of these objects will resume in the next few weeks after some more little details are ironed out of the current version of GEM.
where 'transform-vertex' takes any number of floats referenced $f1, $f2...etc (like expr: apologies if I got the syntax wrong, I don't have pd on this computer) and has $fx,$fy,$fz for the current vertex coords. The example above would therefore shift by 1.2 in the y axis and scale by 3.4 in the z axis. A similar thing could be done with colours. I think even though this is quite simple it would do for many applications.
An expr type object for both vertex and pixel manipulation would be quite interesting to have. I think the development for such an object would be quite involved though.
This could be more useful in conjunction with a 'gem-moses' which would act as two 'separators', the relevant one being chosen depending upon the vertex position, or something along these lines.
Yes, something like this is a planned object ( vertex_separator or split or something like that).
cgc
I would try to code these myself but I don't think I am up to doing externals yet... Anyway these are just ideas and I'm sure you have something similar going on. Good luck and make sure you tell us all when you've got something!
Cheers Stefan.
-
chris clepper -
Stefan Turner