Assignment 1 Question 2

Building the ball, no problem. Displaying the ball...no issues. Interpreting what the question means with panning and zooming...slightly different kettle of fish. I do not know if they are set on having the CAMERA zoom and pan or if they'd like only the EFFECT of zooming and panning. I went with the understanding that the effect is what's required since the question doesn't specifically state which of the two approaches one must use, so used glScale and glTranslate for a rather nifty end result (I also used glRotate for the view angle requirements as it keeps the distance fixed, but creates the impression that the camera has moved by rotating the ball itself.)

The only issues I have at the moment is that the ball doesn't behave nicely when I'm rotating it AND zooming/panning at the same time. The application is also not as responsive as one would like (the continuous calls to the idle func is obviously swamping system resources) so I will look into possible ways of dealing with this (if I have time, otherwise I'll just disable keyboard inputs while rotating or something like that).

Yes, I've now encountered that interpretation problem.

From "object coordinates" point of view:

"Panning in x direction" = moving a certain distance parallel to "object-x-axis" (since the vectors remain almost identical, I suppose it's fair enough to also use vector terms and just say "x-panning is moving on the x axis".

That's what I'd consider the "likeliest right interpretation".

An alternative definition = moving orthogonal to the "AT" vector, in the xz plane?

In other words your path is the solution to a differential equation, solving for the function that a tangent like that would belong to, which is of course a circle. "Panning is orbiting".

The camera frame moves around (which is not the OpenGL model), and the camera doesn't "turn its head" ... which is to say it doesn't "pan".

OK. Now if "panning is orbiting" the logical way to achieve the effect would be to just rotate the ball. (I think it would just be the effect that matters - although getting to the effect would require some learning experiences) That would be quite nice. It would also be something new after what we did in Q1, so perhaps I need to reconsider? I think not. Really, orbiting doesn't match the definition of "panning".

So the way I currently see this part of it, then, is that this part of the question simply takes the Q1 motion and maps it to the left and right arrow keys.

....

OK. So then there's zooming. That has to be a whole new kettle of fish. Again I reckon it's the effect that matters, not where the camera is, etc. The ball must "zoom". Whichever the current view is must get bigger or smaller.

Now I was thinking in terms of moving the object. Calculate the hypotenuse, and make it bigger or smaller. But that's dumb, isn't it? Just call glScale(..) on whatever the current view is, and you'll get a zoom effect. And that's all that's required.

So I'd be inclined to map different calls to glScale(..) to up and down arrows.

There aren't any problems with the definition of zoom. It's just an effect.

.....

Because I've only been on job#1 (this "pan" business, and deciding what it is), I haven't really looked much at the mouse function yet.

Anyway, it would seem we're agreed at least that these things are all EFFECTs, in which the efficiency of achieving them is all that really matters, not whether the camera or object moves, for instance.

And you haven't forgotten your simple little "Quit on Esc" routine, eh? (I'm assuming you don't mention it because it's too trivial to mention; but I'd better not assume too much, and remind you, just in case).

I initially also considered orbiting as that was always my understanding of panning, but some nagging feeling made me look it up and it turns out I was wrong:

http://en.wikipedia.org/wiki/Panning_%28camera%29

I'm not sure if using the walk through calls as in Q1 will do the trick (unless yours does something different to mine...my walk through calls simply changes the axes of perception, i.e. the object remains smack bang in the middle of the "frame" and initially, if you hold down whichever key you were playing with, we move outside of the clipping box). As I mentioned before, I went with translation.

Worth noting for the "zoom" effect. Take care that your scale factor doesn't go into the negatives as this creates a "bouncing" effect...you'll see what I mean...very cool, very not part of "zooming"

I did actually remember the "Esc", but thanks for reminding me as I very nearly did forget and only picked it up reading through the whole question again (so your intuition was rather spot-on ). In case you don't feel like Googling your ass off, the unsigned char for the Esc key is '\033'

The mouse callbacks are easy enough to implement. I decided to go with a menu and sub-menus. Currently everything works perfectly well. I can zoom (scale) and change the view angle (rotate) while rotating the ball itself, but I simply can't get it to translate and rotate at the same time...or rather, it rotates, it translates, but then it starts rotating not only around its own y-axis but also around the Cartesian origin. Still trying to wrap my head around exactly why that is happening.

I've bypassed the "tilt" question for the time being, and have gone on to the menus (which I've also implemented as submenus). I have yet to get my zoom to zoom continuously while held, so it's still "one click at a time" (and rather coarse-grained, too).

There's one little catch in the wording to watch out for with the zoom. They specifically state that zoom in this part of the question must be done by moving the camera, which looks like glTranslate to me. Looks like I need to determine current x, y, z (of the camera) first, and then just multiply by some scaling factor. (Similar triangles says that's OK).

I'm not quite sure whether this also works out to be a little catch in the implementation of the "y-tilt". If one has tilted in y by some rotation trick the first time round, it looks like that, too must be "translated into a translation".

I hope to one day get to muck about with negative zoom factors, but the end is too far away for that now.

The translate and rotate at the same time might be because whichever function goes first holds onto the processor? (Surely?) So somehow or other you must be getting locked into your function/s. I suppose one would have to somehow "bail out" and leave the processor free for other events. (Sorry if this is vague - just a sign of lack of understanding).

Hmm or else your mouse is too finely tuned? So it's picking up fine movements all the time, and firing off mouse events at so much greater a rate than the keyboard ... er no, your keyboard is going to be firing continuously, isn't it? It's something grabbing hold of the processor's entire attention, isn't it? Do you get any different result if you start in a different order? ... I suppose the effect would be too small to see.

Mmmm...I think I'm going to stop speculating and write to Mr Aron. No point in risking it. Will report back as soon as I have feedback.

OK I have what might turn out to be a similar problem. When I click my window the ball stops rotating (I'm defaulting to a rotating ball). I presume that's because the screen is no longer "idle", having been clicked.

I managed to get it hang nicely with an ill-considered while loop testing GLUT_KEY_DOWN and calling the spin(). (The mistaken idea I had was that I could just hack this - add a separate call to the spin during any key-down.)

There seems to be some "excess persistence" attached to the events? Instead of a microscopic pause to note the event, a microscopic reaction, and then perhaps returning to some kind of event queue, it looks like the first event to fire gets to join the front of the queue each time from then on or something weird like that. It'll be interesting to hear what Mr Aron has to say about it.

It's lovely when one manages an infinite loop

The approach to simulate the visual effect is acceptable, which means I think I'm done.

Regarding the stopping of rotation when right-clicking, I agree with you that it's probably due to the application no longer being seen as idle. No way around that as far as I can determine...or rather, knowing computer geeks, there probably IS a way, but it is quite possibly much more intricate than what's expected from us at this point so I'm not bothered about it.

I'll let this assignment lie for a couple of days and carry on with another. I like revisiting my code when I haven't look at it for a day or so as I often see nicer, more elegant options for my solutions this way.

I'm having a merry old time with the "move in y" part of the program, so presume I'm on completely the wrong track. Reading that part of the book for the nth time, I do note that the authors say that the point of view you take (object vs. camera) doesn't really matter. (I mentally note that the nth time, too, but somehow don't take then next logical step from that).

The question at that point says "move the camera", so I thought it was one of those deliberately "otherwise" specifications simply designed to make you think. I have no idea whether this would've been more successful, but without that I'd have been inclined to follow an initial inclination to:

translate to eg. yz plane (Tr)
rotate by -(theta) purely "in yz"
translate back out into space (-Tr)

However I've not done this.

I've been doing a bit of geometry, basically. In object coordinates I've got the path of the camera up to the vertical and down to the floor reduced to formulas that keep it just about on the straight and narrow (conceptually).

And then I look again and see that gluLookAt(..) takes camera coordinates for its eye (the part I'm trying to move). If it's taking eye coordinates then as soon as you've done your "lookAt" you've reset your camera coordinates, I suspect. Your camera moves eg. "up and forward" a bit, still looking parallel to where the last "lookAt" pointed it. (Maybe it's now looking over the ball). Then you call the "lookAt", and the function tilts the camera to look at the origin again, from its new position. That should mean that in camera coordinate terms x==0, y==0, and z== -d once again. Relativity arrives to freak me out.

If this latest view of gluLookAt(...) turns out to be not mistaken then the "tilt" function can only work in small increments. There's no "path". There's a local dz (set arbitrarily), a local dx(following from the dz via a formula), and then finally a local dy, similarly.

It still kind of makes sense to me, but the computer says it's a horrible mess. When I try to pull this stunt the ball just vanishes. Maybe my camera is averting its eyes or looking the other way.

========= Eddyt ====

OK that problem with the single click "one step" operation of some of these keyboard things? I think the way to handle that may well be a while loop. One would set a bool to true on click down, and then inside the loop test for GLUT_MOUSE_UP (??) and if so, set buttondown = false. I've found a page which seems to be set on doing that. Will see. Just thought I'd make an early report on the possibility.

===========Ed2t--->

The eye position is indeed in Object coordinates (and I think I read that somewhere before embarking on constructing all my formulas). No the camera is not returned to (0,0,-d) after a "lookAt".

So my formulas have some fault (maybe I'm keeping a square somewhere or purporting to use similar triangles on squares instead of simple lengths?). I'll have to go that route to fix things. I've taken a few "nifty shortcuts" which I think I must kill before all else.