I was just wondering how one would rotate a 3d world in either LuaGL or OpenGL. The problem I have is that when I rotate, at somepoint when I am near a wall in my program, I end up either in the wall or outside of the room I built. Not exactly sure why this is, and it's even harder because a lot of programming code I look at is either C or C++ oriented. I have checked out NEHE already and again it is C or C++ oriented, not Lua oriented.
the problem is that you are rotating everything about their world space coordinates, to fix this, you would need to make the origin of your object equal to the point around which you wish to rotate, then rotate and then translate it to where it should be.
So for example if you just want to rotate your world, you would need to make sure that the world matrix of each object you are drawing is equal to the identity matrix.
In graphics we go by the principle of scaleMatrix * rotationMatrix * translationMatrix.
Here is an example of what your draw method for an object might look like.
You should consider looking at glm for handling your matrices though, I've found it to work much better.
glPushMatrix();
glLoadIdentity();
glScale();
glRotate();
glTranslate();
glPopMatrix)();
Related
After reading on the coordinate systems in OpenGL, I figured to move the camera around the world I just need to translate the view coordinates. If I say use view = glm::translate(view, glm::vec3(0, 0, -50));, I'm translating the camera 50 units back (by translating the world 50 units forward). After thinking I had it figured out, I encounter LookAt function. I can't understand why I would need to use this function, if I just can move around my camera by translating and rotating the view. The whole thing is a bit hard to wrap the head around, so I'm sorry if this doesn't make much sense!
glm::LookAt or mat4x4_look_at of linmath.h or gluLookAt, and so on, are all just there for your (= the programmer's) convenience. That's all.
If you want to setup the view portion of the modelview transform with a different method, because it suits you better, then by all means you should to that then.
I'm not quite sure on how I should be making things move using openGL.
Am I supposed to be moving the camera's position around the 3D world, or moving/translating the objects around the camera?
I read online that the camera should stay at the origin and everything else should move around the camera, but wouldn't that be an intensive operation? Like if I have 1000 objects and I'm moving, we'd have to move all of these objects. Would it not be easier to move the camera and keep the world objects where they are?
The way OpenGL works is, conceptually, the camera is always in the center, Y axis up and Z axis forward. If you want to move or rotate the camera, you actually move everything else the opposite way.
This is opposed to Direct3D for example, where you have a separate camera matrix.
It's a minor detail though because mathematically speaking they're exactly the same. Whether you move everything forward or the camera back, it's exactly the same end result. You could even argue that having only one matrix as opposed to lugging around two and multiplying them is a performance gain, but it's extremely minor and usually you'll separate your camera matrix from your world building matrix anyway.
In Opengl, the camera is always located at the eye space coordinate (0., 0., 0.). To give the appearance of moving the camera, your OpenGL application must move the scene with the inverse of the camera transformation.
You don't need to worry about moving/translating objects in your scene. gluLookAt() function does it for you. This function computes the inverse camera transform according to its parameters and multiplies it onto the current matrix stack.
I am trying to rotate over the 'x' axis and save the transformed matrix so that I can use it to rotate further later; or over another axis from the already rotated perspective.
//rotate
glRotatef(yROT,model[0],model[4],model[8]);//front over right axis
//save model
glGetFloatv(GL_MODELVIEW_MATRIX, model);
Unfortunately I noticed that openGL must buffer the transformations because the identity matrix is loaded to model. Is there a work-around?
Why, oh God, would you do this?
I have been toying around with attempting to understand quaternions, euler, or axis rotation. The concepts are not difficult but I have been having trouble with the math even after looking at examples *edit[and most of the open classes I have found either are not well documented for simpleton users or have restrictions on movement].
I decided to find a way to cheat.
edit*
By 'further later' I mean in the next loop of code. In other words, yRot is the number of degrees I want my view to rotate from the saved perspective.
My suggestion: Don't bother with glRotate at all, they were never very pleasant to work with in the first place and no serious program did use them ever.
If you want to use the fixed function pipeline (= no shaders), use glLoadMatrix to load whatever transformation you currently need. With shaders you have to do the conceptually same with glUniform anyway.
Use a existing matrix math library, like GLM, Eigen or linmath.h to construct the transformation matrices. The nice benefit is, that you can make copies of a matrix at any point, so instead of fiddling with glLoadIdentity, glPushMatrix and glPopMatrix you just make copies where you need them and work from them.
BTW: There is no such thing as "models" in OpenGL. That's not how OpenGL works. OpenGL draws points, lines or triangles, one at a time, where each such called primitive is transformed individually to a position on the (screen) framebuffer and turned into pixels. Once a primitive has been processed OpenGL already forgot about it.
So i'm learning openGL and one thing I find very strange is that the camera has the stay at the origin and look in the same direction. To achieve camera movement and rotation you have to move and rotate the entire world instead of the camera.
My question is, why can't you move the camera? Does directx allow you to move the camera?
This is an interesting question. I think the answer depends on what you actually mean, when you are talking about a fixed camera.
As a matter of fact instead of saying openGL has a fixed camera I'd rather tend to say there isn't any camera at all in openGL.
On the other hand I wouldn't agree with your interpretation that the openGL API moves or rotates the world.
Instead I'd say the openGL API doesn't move or rotate the world at all.
I think the reason why there isn't any concept of a camera in the openGL API is, because it isn't meant as a high level abstraction layer, but rather linked to the computational necesissities in displaying computer graphics.
As I suggest you're mainly talking about displaying 3-dimensional scenes this means transforming 3D vertex data to a 2D raster image.
For every frame rendered this involves transforms transforming the 3-D coordinates of every vertex in your scene to their corresponding 2D location on the screen.
As every vertex has to be placed at the right position on screen it doesn't make any computational difference at all if you conceptually move something like a camera around or just move the whole world, you'll have to do the same transformation nonetheless.
The mathmatics involved in computing the "right" position for a vertex on screen can be described by a mathmatical object called matrix that, when applied (the mathmatical term used for this application is matrix-multiplication) to 3-D data will result in the desired 2D screen coordinates.
So essentially what happens in rendering a 3-D scene - regardless of the fact if there is any camera at all or not - is that every vertex is processed by some transformation matrix, leaving the original 3-D data of your vertex intact.
As the 3-D vertex data doesn't get changed at all, I'd say the openGL doesn't move or rotate the world at all, but this "observation" may depend on the observers perspective.
As a matter of fact leaving the 3-D vertex data intact without changing it all is essential to prevent your 3-D scene from deforming due to accumulated rounding inaccuracy.
I hope I could help by expressing my opinon on who or what moves whom when or why in the openGL API.
Even if I couldn't convice you there is no word-moving involved in using the openGL API don't forget the fact it doesn't weight anything at all so moving it around shouldn't be too painful.
BTW. don't bother to investigate about the proprietary library mentioned in your question and keep relying on open standards.
What's the difference between moving the world and moving the camera? Mathematically... there isn't any; it's the same number either way. It's all a matter of perspective. As long as you code your camera abstraction correctly, you don't have to think of it as moving the world if you don't want to.
I'm learning some OpenGL game programing, and I'm stuck in how to implement so the camera follows the mousepointer. Like in a fps game you want to look where your mouse is pointing, but I can't find a nice solution to this while I'm moving. I was thinking of saving one matrix for the move, like walkking and strafing, while using quaternions to handle the rotation. Then make the quaternion to a rotationmatrix, load the identity for the modelview matrix and time this matrix with both matrixes.
There is ofcourse some problems with this, like which matrix we should use in the multiplication first, and the code will be ugly.
So I'm wondering if anyone have a good solution to solving this, so I don't have to find out which matrix to use first, and which gives cleaner code.
Store the camera's view details as a position vector, a view-vector and an up-vector (think of pointing with your thumb stuck out: your finger is the view-vector, and your thumb is the up-vector). Keep these vectors normalized and at 90 degrees to each other. You should be able to see that these three vectors are sufficient to represent any camera position and orientation.
You can use these vectors to transform world-coordinates to camera-coordinates:
Translate by -position;
Rotate around (up-vector 'cross' y-axis) by -(angle between up-vector and y-axis);
Rotate around up-vector by -(angle between view-vector and z-axis).
(I might have got some of my signs the wrong way around there).
You can transform these vectors as the user moves the mouse:
As the mouse moves sideways, rotate the view-vector around the up-vector (or rotate both view-vector and up-vector around y-axis, if you prefer).
As the mouse moves back/forwards, rotate both the view-vector and up-vector around (view-vector 'cross' up-vector).
I don't really have a solution for your problem, but i know the open-source 3d engine Irrlicht has a FPS camera that does exactly what you're looking for and, usually, it has a well-documented source.
You could try looking at how the FPS camera is implemented in Irrlicht or you could even use Irrlicht itself for your project; i used it for a couple of mine when i was in college and it always worked like a charm :)