GameDev.net Posting Guidelines (please read before posting)
For Beginners Forum FAQs (please read before posting)
Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.
Posted 08 April 2014 - 04:59 PM
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)
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.
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.
Posted 09 April 2014 - 05:27 PM
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.
Posted 09 April 2014 - 07:46 PM
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
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.
Posted 10 April 2014 - 04:22 PM
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.
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.
GameDev.net™, the GameDev.net logo, and GDNet™ are trademarks of GameDev.net, LLC.