geiger at xdv.org
Wed Jun 4 10:08:10 CEST 2003
> >am i alone in finding GEM really not intuitive?
> >it doesnt really have a "dataflow" feeling to it.
Thats because OpenGL rendering is not about dataflow. It uses a
different paradigm. It is impossible to understand this at
first sight, without any background in 3D modelling.
We hope the tutorial will solve this "first time" problem.
> >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.
More information about the Pd-list