I can explain why GEM is "backwards" :-) Warning: History lesson for those who want to delete the spam now...
The very 1st version of GEM actually worked with the shape objects (like square, etc) at the start. There was a final object called render which then drew the object. The problem is that it was extremely slow. This is for two reasons. 1) OpenGL is a state based system which draws tri's based on the current state and 2) carrying around all of the extra information to generate the tri's at the start, but draw them at the end was prohibitive on the SGI Indy's I was working on.
I actually did some pieces with GEM like this, but it just ran too slowly and the underlying code was a pain in the neck, since I basically was duplicating OpenGL's state mechanism (and including geometry) and passing lots of pointers around between Pd/GEM objects. One nice thing at the time is that it was trivial to modify the vertices with objects. The tex_coord object is a legacy of this actually.
I re-architected it to be more like the OpenGL functions and it ran faster, was easier to maintain, and easier to extend the functionality through OpenGL.
It might be easier now to do it with the shape objects at the start with things like vertex buffers...but those didn't exist 10 years ago when I created GEM :-)
Mark
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf
Of
B. Bogart Sent: Sunday, July 16, 2006 6:55 PM To: Chris McCormick Cc: pd-list@iem.at Subject: Re: [PD] GEM GOP abstractions
Hi Chris,
I have not had a chance to look at your abstractions yet, but would
you
be interested in making some contribution to pixelTANGO?
Thomas O. F. and yourself have any ideas to foster collaboration
between
us three, since we're making many Gem (GOP) abstractions...
.b.
Chris McCormick wrote:
Grtz,
I've been messing with GEM lately and have made a bunch of GOP abstractions to make things easier. You can find then in the tarball
of
my cvs which is at:
http://mccormick.cx/viewcvs/s-abstractions.tar.gz?view=tar
The gfx stuff is in the sx/ directory and works best if you include
the
parent directory (s-abstractions/) in your path. You'll need the
zexy
(for [repeat]) and Gem libraries.
I have always found it strange how GEM seems to be kind of backwards
in
terms of the flow of data. In Pd you generally make a noise with
e.g.
[osc~] and then run it through some effects, into your [dac~] where
it
is output. In GEM it works the opposite way. You have to place all
your
color, translate, rotate, repeat, texture "effects" before you put
the
basic geom such as [cube], and the whole chain starts with the
"output"
[gemhead]. To address this I've been experimenting with a method of storing geometry in a [list] which is sent through geometry
modifying
"effects" to an object [sx/blob] which draws geometry represented as
a
list of verticies of triangles, to the screen. It's pretty crap and
slow,
and I'd love to know if there is already a better way of doing this.
You can send arbitrary geometry from blender3d into puredata by
using
the script in the utils/ directory. Copy it into your
.blender/scripts/
directory and go File... Export... Raw Triangles across the Net... whilst having sx/netgeom-help.pd open. You can't send very complex geometry or the whole thing starts to chug pretty badly, but I think it's a start for something better.
An example of an effect on geometry is the sx/explode patch which translates all faces along their normals by some amount. This is all done as [list] math so it's hellishly slow on complex geometry.
I am particularly interested to hear if there is a better, faster
way of
doing this [vector level geom manipulation] that I don't know about.
I
have been really inspired by the fijuu stuff and I would like to be
able
to do similar kinds of mesh warping from withing Pd and GEM.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
hey mark!
On Jul 16, 2006, at 11:21 PM, Danks, Mark wrote:
I can explain why GEM is "backwards" :-) Warning: History lesson
for those who want to delete the spam now...
...I dig the history lessons, so keep 'em coming...
...snip...
One nice thing at the time is that it was trivial to modify the vertices with
objects. The tex_coord object is a legacy of this actually.
...snip...
It might be easier now to do it with the shape objects at the start with things like vertex buffers...but those didn't exist 10 years ago when I created GEM :-)
...this sounds exactly like the vertex_array stuff that cgc did some
years ago, tucked away in an esoteric cvs branch of gem: the main
holdup for awhile was a disagreement between iohannes and cgc &
me...Iohannes wanted to extend the buffer sizes to 4 for everything,
so that all buffers could be multiplied by each other (easy matrix
math)...cgc & I didn't like the wasted space, since you would never
have four normals, colors, indices, etc...last time we really
discussed it, iohannes basically threw his hands up, but then no-one
acted on it, as the idea had become quite cold, and somewhat
surpassed by doing the math in vertex programs instead of cpu-based
objects...
...anyway, just a week ago I finally started committing the stuff to
gem's cvs head...the basic idea is that you can create a buffer one
of two ways: either by loading a model ([vertex_model], thanx to
cgc!) or reading a table ([vertex_tabread], thanx to Io!)...then you
can use different objects to process the vertices cpu-side, or go
ahead and upload the buffers to the gpu ([vertex_draw])...at which
point you could insert [vertex_program]'s or [glsl_vertex]'s to do
the calculations on the gpu...
...well, that's the theory, but there are plenty of pitfalls in
practise, I'm sure...currently I'm expanding [vertex_tabread] to
accept single table messages (instead of "all tables at once" as it
is now), plus trying to create an auto-normal generation method,
along the lines of andrew glassner's "Building Vertex Normals from an
Unstructured Polygon List" method in Graphics Gems IV...
...or something like that :-)
jamie
On Tue, Jul 18, 2006 at 05:56:29PM -0400, james tittle wrote:
On Jul 16, 2006, at 11:21 PM, Danks, Mark wrote:
I can explain why GEM is "backwards" :-) Warning: History lesson
for those who want to delete the spam now......I dig the history lessons, so keep 'em coming...
I second that!
...anyway, just a week ago I finally started committing the stuff to
gem's cvs head...the basic idea is that you can create a buffer one
of two ways: either by loading a model ([vertex_model], thanx to
cgc!) or reading a table ([vertex_tabread], thanx to Io!)...then you
can use different objects to process the vertices cpu-side, or go
ahead and upload the buffers to the gpu ([vertex_draw])...at which
point you could insert [vertex_program]'s or [glsl_vertex]'s to do
the calculations on the gpu...
Jamie, this sounds like really cool work, I look forward to seeing it in gem! I wonder if it would be much harder to make something like [vertex_list] which allows you to [add x y z x y z x y z( to the list of faces and the reverse which could turn a [vertex_list] back into a list kind of like [textfile]. This way we could do Pd list-ops on the lists of verticies. Probably I should be writing code instead of feature requests - my apologies.
Best,
Chris.
chris@mccormick.cx http://mccormick.cx
-
Chris McCormick -
Danks, Mark -
james tittle