[PD] GEM

chris clepper cclepper at artic.edu
Wed Jun 4 01:50:15 CEST 2003


>hi,
>am i alone in finding GEM really not intuitive?
>it doesnt really have a "dataflow" feeling to it.
>
>For example [cylinder] outputs an cylinder to graphics window,
>but it isnt connected to the [gemwin] block.
>What if i wanted to multiply the pixels of 2 different cylinders and
>then output it to the graphics window? 
>Normally i would think:
>      [cylinder]     [cylinder]
>          \                 /
>             [pix_multiply]
>                 |
>             [gemwin]
>

The problem here is that you are trying to use the pix_ image and 
video objects with an OpenGL 3D object.  The pix_ prefix is the clue 
that all the pix_ objects work together, maybe the 3D objects should 
have been named 3D_cylinder or geo_cylinder but it's a little late to 
do that now.

Also, what would you expect to happen when you multiply these two 
objects?  The cylinder object only sends a set of vertices as a 
description of the cylinder to the video card, so what would 
multiplying those vertices actually do?  Make the cylinder larger? 
If the cylinders were textured there is a way to multiply the 
textures together using a shader, but GEM is not capable of doing 
that just yet.

You could use pix_snap to grab the area of the output window with a 
each cylinder then use pix_multiply on the captured areas.

>maybe it would be more fun if there was more a flow to it, like
>with pd sound. dont shoot me down if im wrong, it's just an impression  :)

I think it might be more 'fun' once the tutorials are more complete 
and integrated with the distributions.  Until then you might want to 
learn about OpenGL, 3D, video processing in general to figure out why 
your patch doesn't work.

cgc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20030603/68e8c19f/attachment.htm>


More information about the Pd-list mailing list