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