 |
Author |
Topic: questions about background() & rotate() (Read 590 times) |
|
kevinP
|
questions about background() & rotate()
« on: May 6th, 2004, 12:27pm » |
|
Hi all,
A couple questions, more to satisfy my own curiousity.
1. Why does rotate() use radians instead of degrees (which seems to be the default for glRotate()). Is there an advantage (better that one immediately learn to work with radians, faster to calculate)?
2. Without an explicit background() call, a Processing sketch defaults to background( 128 ), but if I want to use it in the loop() to clear the background I can't simply enter "background()" but need to specify a value. Why not "background()" using the same default value?
3. Even more esoteric (and really just "asking aloud" here) - I've found that with openGL one can set up a simple 'sketch' very quickly and with fewer callbacks and parameters than in most "simple" demos I've seen. For example I was surprised to see that you do not need to worry about matrix modes, viewport configuration, etc. (initially). The default config. has a coordinate system that runs from -1 to +1 in both (all three) directions, with the 0,0 origin at the center of the screen. This seems very easy and simple to deal with initially. It seems to me that this way one can even postpone learning to use translation for a day or so and still use rotation.
Why does Processing choose to use a window-based (if that is the right term) traditional coordinate system? Is it less confusing as things become more complex, or is it because less values need to be calculated as floats, or is it "just wait until later and you will understand"? 
Thanks for any and all responses! (as always)
|
| « Last Edit: May 6th, 2004, 12:28pm by kevinP » |
|
Kevin Pfeiffer
|
|
|
fry
|
Re: questions about background() & rotate()
« Reply #1 on: May 6th, 2004, 3:23pm » |
|
1. because all the math functions (sin/cos), often used in tandem, are in radians, which is something that drives me nuts about opengl. for in a future release, angleMode() will be added, which will allow you to specify whether you want to use radians for everything or degrees for everything.
2. we're still deciding what functions with no args mean. i.e. framerate() returning the frame rate might be a nono, like stroke() returning the stroke. it's a bit confusing to have methods that sometimes act as functions, and other times act as procedures.
3. because almost always, in the context of processing, you're mixing 2D and 3D graphics. the -1 to 1 model tends to be super confusing for people just getting started, who have just gotten over the notion of screen coordinates. of course this doesn't limit you from setting up a standard opengl-style matrix, through the use of beginCamera/endCamera.
3a. perhaps this sort of setup could be added as a secondary option, but to be honest, the 3D parts of the api haven't received as much attention recently.
3b. as a historic note, this 2D/3D model used to be called 'mazo', and was developed by tom white of acg:
http://acg.media.mit.edu/people/tom/
for use in our opengl/c++ library that we used to build all our work. i was initally not into it myself, but over time, i've come around, and i think in processing it particularly makes sense.
|
|
|
|
|
|
