**0**

# Some question about transformation

###
#1
Members - Reputation: **196**

Posted 08 April 2014 - 04:59 PM

Now, the plane will rotate, but it will always look without rotation as shown in figure (a).

I think I need to play around with my glutReshape function which looks like follows:

/*******************************/

void glutReshape(int width, int height)

{

width = glutGet(GLUT_WINDOW_WIDTH);

height = glutGet(GLUT_WINDOW_HEIGHT);

if (width && height)

{

glViewport(0, 0, width, height);

nearDist = 150.0 / tan((kFovY / 2.0) * kPI / 180.0);

farDist = nearDist + 100.0;

aspect = (double) width / height;

glMatrixMode(GL_PROJECTION);

glLoadIdentity();

gluPerspective(kFovY, aspect, 0.1, farDist+20);

glMatrixMode(GL_MODELVIEW);

glLoadIdentity();

gluLookAt( 0.0, 0.0, (nearDist + 5.0), // camera/ eye

0.0, 0.0, 0.0, // center

0.0, 1.0, 0.0); // up vector

}

}

/*******************************/

But I fail to correctly manipulate it. When rotation axis will move from (0, 0, 1) to (ax + by + bz), the eye/ camera will be changed from ( 0, 0, nearDist +5) to {(nearDist+5)*ax, (nearDist+ 5)*ay, (nearDist + 5)*az}. Is it right?

But what about the up vector? How will it change for this rotation? How can I calculate new up vector? Also what other parameters in my glutReshape function needs to be changed?

Please provide me some suggestion so that I can fix this problem.

Thanks in advance.

###
#2
Members - Reputation: **291**

Posted 09 April 2014 - 10:50 AM

from what I am understanding, you wish to manipulate plane by rotating it not in its world transformation but in view transformation. You could effectively do this by making glulookat matrix corespond to plane normal you have as the rotaion definition. In that case you can make eye-at vector to have the direction of that normal. Meaning, have lookat point to be the plane center (or so) always, and compute eye position vector from lookat+rotationnormal*radius - lookat and rotationnormal are vectors and radius is a scalar. With this you would rotate around plane with distance of radius (if rotationnormal is unit vector)

###
#4
Members - Reputation: **1870**

Posted 09 April 2014 - 11:51 AM

glut is not a graphical specification, is just for handling input and output.

glutReshape is intended for other things, it doesn't really care about what you're drawing, that callback is called when you reshape the window: http://www.opengl.org/resources/libraries/glut/spec3/node48.html

You can do whatever you want in that function, but it'll be called only once (when the window is created) if you don't change the size somehow. If you're reshaping your windows every frame based on what's inside ignore what I've said, but it sounds like a really weird idea for a game or an application.

###
#5
Members - Reputation: **291**

Posted 09 April 2014 - 03:31 PM

Thank you very much for the reply. I think I have calculated the new eye point in my posting as you suggested. But how to find the new up vector? Please provide me some suggestion. Thanks

you will set only eye and lookat vectors, keep the up vector constantly (0,1,0). Up vector does not have to change very likely in your case, changing up vector affects camera rotation around the (lookat minus eye) axis, what is the effect of rotating the very screen to left or right moment. It is rarely an intent. As I adviced, keep up vector (0,1,0) and lookat vector constant and compute the eye by formula I have provided- this will result in camera spectating the plane from the direction you have provided by the unit vector- if this is what will work for your intent.

###
#6
Members - Reputation: **196**

Posted 09 April 2014 - 05:27 PM

Please provide some suggestions.

Thanks in advance.

###
#7
Members - Reputation: **291**

Posted 09 April 2014 - 07:04 PM

that is the result of the projection matrix transformation being perspective. if you use orthogonal projection matrix, it will be like figure a. Orthogonal projection is simplified perspective projection. you shoud have a glut function for orthogonal perspective matrix building from parameters.

An identity matrix is an orthogonal projection matrix case witth scale 1.0 in all three directions. Meaning that if you do not use projection transformation matrix at all (setting it to identity), it will be like using orthogonal projection with scale 1.0.

###
#8
Members - Reputation: **196**

Posted 09 April 2014 - 07:46 PM

###
#9
Members - Reputation: **291**

Posted 10 April 2014 - 11:46 AM

perspective projection will always result in deformation by depth, there is nothing to adress about this into view matrix. All you can do is to set the object incredibly far- yet this will only minimize the effect. In case of precise observing, perspective matrix is never used. View frustum of a perspective matrix is a pyramid and it results in not "real" size of objects, while ortho projection view frustum is a cube/quad and it results in real size of objects when onserved, not dependant on distance from camera. Though this effect does not match real phenomena of observing, it is critical for architectural softwares or image manipulation softwares and genaraly softwares that need to see precise placing in all three directions.

you can switch from orthogonal projection to perspective projection though - at any time

###
#10
Crossbones+ - Reputation: **4581**

Posted 10 April 2014 - 12:27 PM

*Perhaps* the goal is to find a position and orientation for the camera (i.e. a view transform) so that the plane does not change w.r.t. the view space although it is changed in the world space? If so, then the math is as follows (I'm using matrices for transformations because problems like this can be described with matrices very compact; I further use column vectors as is common when dealing with OpenGL):

a) The initial situation is given by a world transform **M**_{0} of the plane and a view transform **V**_{0} of the camera. Then the transform of the plane in view space, i.e. its placement relative to the camera, is given as

**V**_{0} * **M**_{0}

It seems from the OP that **M**_{0} is just the identity matrix and **V**_{0} is just the inverse of a simple translation of the camera.

b) When the plane's transform is changed in world space to current **M**_{i}, you want a adapted view transform **V**_{i}. The transform of the plane in view space is again the product of both. However, you want the plane in view space to be the same as in the initial situation, hence

**V**_{i} * **M**_{i} = **V**_{0} * **M**_{0}

Solving this for the unknown view transform gives

**V**_{i} = **V**_{0} * **M**_{0} * **M**_{i}^{-1}

This result makes sense, because it undoes the current plane transform (see the inverse **M**_{i}) and lets the initials transform remain (see the **V**_{0} * **M**_{0} which is what we had in the beginning).

There are several ways of implementing the above solution. The best and future-proof way is to drop usage of OpenGL's matrix routines (with the exception of glLoadMatrix as long as you deal with the fixed function pipeline) inclusive the companion routines of GLU. Instead, use a math library like GLM and handle transforms yourself. As can be seen here, solving problems like this can easily be done in matrices (if matrices itself are understood, of course) but are seriously error-prone when using OpenGL directly.

Are you able to switch to using a matrix library yet, or do you really need to stick with OpenGL's matrix stack?

**Edited by haegarr, 10 April 2014 - 12:29 PM.**

###
#11
Members - Reputation: **196**

Posted 10 April 2014 - 04:22 PM

Thanks again.

###
#12
Members - Reputation: **275**

Posted 11 April 2014 - 03:40 PM

Hi jenny,

RE: " I saw Nate Robbin's tutorial but a confused how to make it work."

Thats not a good sign. You will be struggling with this until you do understand the fundamental concepts that Nate's samples are based on. Have you downloaded the examples and ran them?: Have you played around with the values in them to learn by doing and seeing the effects of changing parameters? You cannot get around doing something like this in order to grasp the fundamental knowledge you need to get to a solution. There are no short cuts. It is a matter of finding material suitable to the way you learn.

So here are a few things to try:

Search on terms like "opengl camera". there is lots of info around: only you know what will suit you.

Start by reading this: http://www.glprogramming.com/red/chapter03.html. Or even scanning it for (more hands on) examples to here:

http://www.glprogramming.com/red/chapter03.html#name8. This stuff is an example of the easiest/simplest and well explained info you must grasp before you try to solve your problem (otherwise you will continually be asking people to hold your hand on every little step of your journey into 3d graphics likely making very little progress).

Let us know if this helps

**Edited by steven katic, 11 April 2014 - 04:04 PM.**