@interface GLQuad_gtPlugIn : QCPlugIn
@property double inputX;
@property double inputY;
@property double inputZ;
@property double inputRotationX;
@property double inputRotationY;
@property double inputRotationZ;
@property double inputX1;
@property double inputY1;
/* We need to declare the input / output properties as dynamic as Quartz Composer will handle their implementation */
@dynamic inputX, inputY, inputZ, inputRotationX, inputRotationY, inputRotationZ, inputX1, inputY1, inputZ1, inputX2, inputY2, inputZ2, inputX3, inputY3, inputZ3, inputX4, inputY4, inputZ4, inputA1, inputA2, inputB1, inputB2, inputC1, inputC2, inputD1, inputD2, inputColor, inputImage;
Finally, we get to where the rotation itself "happens".
Currently, the plugin contains:
/* Save and set modelview matrix */
glTranslatef(self.inputX, self.inputY, self.inputZ);
glRotatef(self.inputRotationX, 1.0, 0.0, 0.0);
glRotatef(self.inputRotationY, 0.0, 1.0, 0.0);
glRotatef(self.inputRotationZ, 0.0, 0.0, 1.0);
This is pretty straightforward. Note that there are 3 lanes in each line. These correspond to x, y and z. By making the x lane in the first line 1.0, it allows the input to manipulate X rotation. For Y, this is moved to the 2nd lane, and for Z, the 1.0 value is moved to the 3rd lane.
The thing that's really handy about this plugin (and project) for me, is that it can be used in ways similarly to the stock line plugin, as opposed to something like a sprite.
Some situations lend themselves to manipulating corner positions, instead of translate happening from a center point. With a Sprite, it becomes really hard to have it act in a line like way (interfacing with something like Hough Lines or the OpenNI User Tracker comes to mind). Similarly, a GL Quad gives that kind of control, but many times I wish to address the Quad like a Sprite, and just move it around or rotate without having to do maths for every single corner. Having the texturing offsets built in is a nice freebie; one can skew the quad to a non rectangular shape, and then use the A1~D2 controls to go and correct aspect ratio.
No extra maths have to be done for the texturing since rotation the entire object wouldn't be expected to "do anything" to the texture.
The modelview matrix MUST be restored after color, texture, and vert point calcs happen; this is shown in the Xcode project. All of this should really be looked at in context of the actual XCode project, so that one understands the good (and important) stuff I'm glossing over for the purpose of semi-succinctly explaining the rotation addition.