|
|
GTTextureTransform ("skanky" sdk patch): Release http://www.georgetoledo.com/2011/03/gttexturetransform.html This is skanky Quartz Composer plugin, environment macro, that transforms the GL Texture matrix. GTTextureTransform from George Toledo on Vimeo. ...so, this means that in this environment you can do things like zoom, offset, or rotate texture through OpenGL function. For example, one can rotate the texture on a sphere while keeping vertex positions the same, or one can zoom image on a sprite without using core image, etc.
|
isn't that the same as ImageTexturingProperties ? ....
There is overlap but:
-There's more than one rotation exposed, which is handy for non 2D objects like spheres (and maybe a little weird for sprites, but it's handy anyway).
This means one can rotate every direction, instead of the one exposed by image texturing properties.
-Image texturing properties is a patch that goes inline between the image and the renderer. This is an environment macro that changes everything inside of it, which can be handy for grouping.
-Image texturing properties also has no implicit bypass (besides doing multiplexer routing or something). So, it's easy to just make macro, wrap in this (transmutate, if you have kinemecore), and your renderer/macro automatically has that type of function, with a built in bypass.
...and... I don't really know how much it has in common with image texturing properties, because I haven't seen the code for that behind the scenes. This is pretty similar to Apple 3D transform macro with scale/transform/rotate, standard GL stuff (that's what I was starting out with... a re-emulation of that, based in a GL Tools type layout), but for texture matrix instead.
Image texturing properties also works kinda weird, in the case of wanting to use that kind of function with an openCL type kernel/renderer setup. You can't just pop in image texturing properties to CL kernel, because things go kind of crazy (at least the one or two times I messed with it...maybe it warrants more testing, but I don't think so...it makes sense it wouldn't work with the CL kernel, and it's output down the road.)
Hey George!
Congratulations on your first QC plugin! First of many, hopefully. I keep promising myself I'll get around to making some myself, but I will probably never get around to it... Did you find the learning-curve steep? In the past, I've tried a couple of general books on Objective-C and I have the OpenGL Red Book and SuperBible (which has some great background on general 3D graphics concepts, incidentally), but I've always found it pretty hard going, to be honest, particularly wading through all the stuff that I know has no relevance to QC plugin coding.
Anyway, as has been mentioned, there are some overlaps between this and the existing Image Texturing Properties patch. It's also worth noting that it's relatively trivial to achieve something very similar using matrix transformations on the texture coordinates in a GLSL Vertex Shader. Having said that, of course, not everyone wants to get their hands dirty with GLSL code, so don't interpret that as discouragement.
Thanks toneburst! I've put a few standard API plugins out, at my website over the past week.
This goes back to the first comment; I've been working with plugin projects since I started QC, and gradually understanding more and more. Looking through all of the leopard era projects, looking at every line, looking up stuff that you don't understand when you find it, etc.
Vade's published source was also really helpful, in that if you see a super basic consumer example like Apple provides for QCPlugin, and then you see how someone adds even one method, things can really click. I think the watersheds for me were making a custom Freeframe plugin that loads differently, and then understanding how the matrix to params plugin for ARToolkit worked. I totally think you should poke your nose into it more, because with what you already know, I think it would be really reasonable for you to try out.
The learning curve is something I could best describe as gradual and long... and then when you get over the hill, you get momentum. Working with openCL and openGL a lot more hasn't hurt. I would look at the basic consumer example from Apple, because it's a good starting point... at least I think.
So, I've had some lingering around in private for some time, and something someone said not too long ago made me think about putting more out there, and putzing around with it more in general. I've messed around with some "skanky" stuff in the past, but nothing that I felt warranted publishing...only enough to generally understand what's going on.
With the skanky sdk release, and the fact I'd done a few QCPlugins lately, I decided to try my hand at an environment... especially since that's the one thing you can't do in a QCPlugin. This is completely based in staring at the GL Tools "GL Scale" patch for a long time, and then going, "oh yeah, the texture matrix can be called on too." It seemed like a reasonable thing to try.
Yeah, Richard Wright's Super Bible (err, w/ GL Tools...but not THAT one...how funny) is pretty interesting (even if the projects look reallly super duper oldschool graphics-wise), and lays out a lot.
I tend to stare at spec on stuff a lot, see what functions I don't understand, and then try stuff out. I've found that some of that stuff seems like it doesn't relate at first glance, but much of it does, save for stuff not supported on Mac, because of them being behind the times on GL versions (arguably).
I find it interesting to have had it pegged as similar to image texturing properties, because it's macro environment, whereas texturing properties is an inline patch. With the GLSL, you can definitely do similar things... but..it's all on one object, or you can do that trick where you map textures to colors of objects, and then offset, etc. All kind of "non easy" ways of interacting with it I think.
Some objects in QC get their textures automagically (like qcmesh renderer/collada importer). Changing texturing offset on that stuff is a pain. What I find nice about this is that something like image texturing doesn't have to go inline. This doesn't enforce gl_repeat or anything like that (yet...that's not really where I was going with it/anything I was trying to achieve, but doesn't seem like a horrible idea after thinking more. It would be interesting to offer repeat in x and/or y.).
Mainly, it always irritated me that texturing properties didn't expose every rotation (just Z, not X and Y), for stuff like spheres as well (which this does). Having the X/Y rotate is kind of cool to me as well. Not having to hook up a bunch of patches inline seems like a nice option too.
You could make 100 sprites, leave all of the imagery you already have hooked, pop them in this environment and immediately do texturing operation en masse... so the small relation to image texturing properties doesn't bother me :) It's sort of like the similarity between a 3D transform environments, and the fact that some renderers have some translate and rotate controls while others don't.
Thanks for the encouragement btw!