I’m trying to understand the advantage of the transformation mode (position, scale, rotation) offered by Processing (and p5)
I’m having trouble getting to grips with the fact that I have to modify the position, scale or rotation of the entire coordinate system rather than being able to do so on each element individually.
I’m certainly missing the point… but dealing with the coordinate system seems a lot more complicated to me.
I guess the approach proposed in Processing (and p5) has its own advantages?
Thanks a lot!
(I learned to program mainly in actionscript (years ago) where each element could be positioned, rotated, enlarged individually. Maybe it gave me bad habits… )
While I appreciate the (very good) tutorials about how the transformations work, I don’t think any of these have really answered what I see as the heart of skraboutcha’s original question: why use these counterintuitive transforms instead of something conceptually simpler, like including location and rotation input value for each drawing command?
The closest to an answer that I saw was at the very end of glv’s last link, which has 2 quick videos with titles like “The 12 Rules of Animation”, which include things like the ability to stretch, squash, and move along an arc as being desirable traits for animation. Perhaps these transforms, in the hands of skilled practitioners, make such animation techniques easier than more straightforward position/rotation would. That is the sort of insight I was hoping that answers to this question might give.
Because, skraboutcha, I agree with your premise - that this transformation approach seems frustratingly convoluted, and I have to keep writing code to ‘undo’ it (like using push and pop) so that I can get my images to look the way I intend. I bet there’s a good reason for it, I just don’t see it (yet).
Thanks a lot for your answer scjphysicist !
All the answers kindly posted before yours are very instructive and helpful but yes, you point it : my question was more about the mindset, or the philosophy, of the original choice for the transformation, instead of the how-to-do. Maybe the beginner section was not the best place for answering this.
Because transformations make everything so much simpler and your code so much cleaner.
Everything we draw on computers we describe with Cartesian coordinates (x, y, and maybe z). By a perfectly reasonable default, Processing uses one unit per pixel. When I’m drawing something, though, I don’t want to think in terms of pixels, but rather I would like to use whatever units are appropriate for the object I’m creating. If I’m drawing a house, I might use feet or meters. If it’s a face, I might use inches or millimeters. But then, if I’m drawing them together, I need to scale them into consistent units and scale those units to pixels. So I could include a scale factor in every single drawing call I make, but what a mess that makes of the code. Alternatively, I can just slap a scale( inches to feet conversion ); before my draw call and suddenly the face and house are in the consistent scaling.
Likewise, for convenience, I coded the face sitting about the origin so that I could easily use symmetry for the left and right, but now I want to position the face or even move it around. Again, I could litter my code with adding offsets to each individual draw call, OR I can just say pushMatrix(); translate( posx, posy ); drawFace(); popMatrix(); and leave the graphics calls clean and simple.
because that moves the origin to the center of the window and lets me draw a unit circle with a slight margin around it. Now I can draw stuff either in that circle or using sin/cos polar coordinates and I never have to worry about the screen resolution. If I want to crank the resolution high to print out a poster or make it small for an online GIF animation, my drawing commands needn’t worry about the difference.
If I may play that back in my own words: Although a non-transformations approach might make it easier to do simple diagrams consisting of just a few primitives, real-world drawings are inevitably more complex, often constructed from multiple simpler drawings which are moved, rotated, scaled, and then combined. Transformations allow you to draw each of those simpler drawings in its own coordinate system, which should make them a lot easier to draw than if you had to draw each one already rotated and scaled.
Is that more-or-less your ‘why transformations’ message?
Exactly right. Though I’d say that even on relatively simple sketches, if you have to add or scale more than a dozen or so coordinates, the translate() and scale() calls will be worth it. The transformations are combined into a single matrix and ALL Processing graphics call coordinates are multiplied by that matrix whether you have made any transformation calls or not, so transformations will likely be faster than doing the math yourself.
The transformation stack is a tool of convenience. Any time it’s less convenient to use it, just don’t.
)
!