There are two types of objects in GEM: pix and OpenGL. <br><br>Pix objects do work in the top to bottom manner like Pd DSP objects. One thing to keep in mind is that the pix_ objects use 'in place' processing which means that the pixel data is overwritten by each object. For most types of processing this works fine, but it you want to apply two different processes to the same pixels then you need pix_separator. pix_separator copies the pixels to a new buffer for further processing.<br>
<br>The OpenGL objects mostly map to some GL operation (rotate or translate) or create a piece of geometry (cube). The GL pipeline has its own rules, but in general it works like back to front rendering. Each pixel drawn is put on top of what is already there. For example, the default state of GEM fills the entire view with black pixels. After that any geometry renders on top of those black pixels (alpha blending will give a mixture of the existing and new pixel). <br>
<br>Objects like rotate and translate manipulate various GL matrices and those matrices are used by the graphics card to render the geometry in the correct orientation. Matrices are reset for each frame and the processes are additive (translate) or multiplicative (scale) to the existing values.<br>
<br>Texturing bridges the pix_ and GL objects together allowing for the image pixels to be applied to the geometry. The convention in GEM is to put the GL objects after the pix_ ones showing that once the pix_ processes are done on the CPU it is time for the GL processes on the GPU to start. <br>
<br>You can place GL objects before the pix_ ones and still have it work. For example, the rotateXYZ can be right after the gemhead and before pix_ objects as it just sets a matrix transform up for all of the GL rendering after it and the pix_ objects have nothing to do with it. <br>
<br>There are lots of exceptions to Pd rules in GEM and there is really no way around them. It is kind of like learning English - I before E except after C, excepting all of those words that ignore the rule.<br><br><br><br>
<div class="gmail_quote">On Wed, Mar 25, 2009 at 12:08 PM, John Harrison <span dir="ltr"><<a href="mailto:johnharrisonwsu@gmail.com">johnharrisonwsu@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"> </div>
<div class="gmail_quote">Perhaps I need some rules about how Gem is different than Pd in terms of dataflow. So far it seems to me that a rendering chain in Gem shows conections but does not reveal the order in which these connections are processed i.e. if 3 objects are all connected to each other in a rendering chain in Gem i.e.</div>
<div class="gmail_quote"> </div><br></blockquote></div><br>