t208898:
hi, 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.
Guenter
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