Sign in to follow this  
kibokun

OpenGL OpenGL coordinate system

Recommended Posts

kibokun    122
I'm very confused about why OpenGL defines the coordinates it uses when you call glVertex as offsets from the center of the screen. It's extremely counter-intuitive for just about everything I want to do. I need a bit of help understanding how to make this work logically with a grid-based collision system (and later, some sort of tree-based subdivision structure). Currently, the objects I want to display are just points drawn using glVertex2. Their position vectors are stored as offsets from the center of the screen, which is for some reason (0, 0). However, I want their coordinates in screen space. That is, the rect defined with an upper left point of (0,0) and the bottom right being (window width, window height). Is there a way to make OpenGL vertex calls work on regular coordinates or do I have to write some sort of function to translate them every time I want to use an object's position to draw a vertex? This would also be a solution (a computationally wasteful one, however.) to the problem of only having OpenGL offset coordinates when I wanted to check which grid cell an object resides in. Thanks.

Share this post


Link to post
Share on other sites
kibokun    122
hmm, glOrtho definitely does what I want for the most part. However, what if I still want to have depth? Should I be using glVertex3f(...) instead of glVertex2f and just keep the Z component at zero?

I ask because I might want to zoom the camera back to show a larger landscape, but still only operate in 2 dimensions for everything else.

This seems to be more logical, as it's only the illusion of 2d.

Share this post


Link to post
Share on other sites
lightbringer    1070
Quote:
Original post by kibokun
hmm, glOrtho definitely does what I want for the most part. However, what if I still want to have depth? Should I be using glVertex3f(...) instead of glVertex2f and just keep the Z component at zero?


This will just make it possible to "occlude" something because higher Z will overdraw lower Z. With glOrtho you are literally mapping XY coordinates to screen space. You could zoom out by scaling your coordinates or changing the values you pass to glOrtho.

If you want 3D then stick to perspective mode. The "center of the screen" thing is an illusion. You are specifying ModelView coordinates but the View is the identity matrix. So you start at the origin looking down the negative Z axis. Try adding some glTranslate / glRotate calls before your glVertex calls and observe how the "camera" changes.

By the way, all the glVertex etc calls are now deprecated (but it's still ok to use them if you want to).

Share this post


Link to post
Share on other sites
haegarr    7372
Quote:
Original post by kibokun
Is there a way to make OpenGL vertex calls work on regular coordinates ...
Why do you think that the one co-ordinate system is regular and the other is not? In fact none system is superior to another in general. Its just more convenient to do some task in the one system instead of the other.

Quote:
Original post by kibokun
... or do I have to write some sort of function to translate them every time I want to use an object's position to draw a vertex? This would also be a solution (a computationally wasteful one, however.) to the problem of only having OpenGL offset coordinates when I wanted to check which grid cell an object resides in.
OpenGL does a transformation anyway, and that is much more complex that just a single 2D translation (i.e. it is a 4D matrix by vector product).

Quote:
Original post by kibokun
... However, what if I still want to have depth? Should I be using glVertex3f(...) instead of glVertex2f and just keep the Z component at zero?
Read this:
Quote:
Manpage of glVertex
When only x and y are specified, z defaults to 0 and w defaults to 1. When x, y, and z are specified, w defaults to 1.


Quote:
Original post by kibokun
I ask because I might want to zoom the camera back to show a larger landscape, but still only operate in 2 dimensions for everything else.
Zoom has nothing to do with depth; it cannot even be faked by moving the camera because you utilize orthographic projection. Instead, adapt glOrtho's parameters accordingly.

Share this post


Link to post
Share on other sites
szecs    2990
I wouldn't suggest to use scale (maybe it's just me, but simply I don't like scaling). If you give greater values to glOrtho, that means more stuff can "fit" into it, thus to the screen, so there you have zooming out. Twice as big values, you zoomed out with two. It's that simple.

Share this post


Link to post
Share on other sites
kibokun    122
Thanks for the replies. Very informative. :)

I think I'm going to stay with gluPerspective because it's more natural for me. However, I'm still not understanding how I can accomplish this:

When a user clicks on a point on the screen, a particle should be created at that X and Y position. However, the X and Y positions I get from the SDL event are on the range of 0-800 for X and 0-600 for Y.

I'd like to find the corresponding X and Y positions I need to pass to glVertex to place a vertex under the mouse cursor.

Thanks!

Share this post


Link to post
Share on other sites
JackTheRapper    150
If you use ortho mode it is fairly straight forward, if you use projection mode it's a little more fiddly as you have to transform the screen space mouse coordinates into world space but not a major ball ache with gluUnproject.

Share this post


Link to post
Share on other sites
lightbringer    1070
The basic idea is that you unproject the mouse coordinates twice to get a ray, then intersect that ray with whatever plane you want the particle at (let's say y=0, meaning ground plane).

Share this post


Link to post
Share on other sites
kibokun    122
After a lot of struggle with UnProject, I switched to glOrtho. It seems to work great for what I need, except zooming in and out. This was trivial with gluPerspective. :(


My problem is when I zoom out, it's as if the vanishing point in gluPerspective were the top left corner of the window. Everything shrinks into that corner when I really just want to zoom out and have objects stay in their place on the screen. What do I have to do to accomplish this?

Here's my function to change the glOrtho arguments



void GameplayState::SetProjection()
{
GLint viewport[4];
glGetIntegerv(GL_VIEWPORT, viewport);

int zoomedWidth = viewport[2] / (2.0f*this->zoomFactor);
int zoomedHeight = viewport[3] / (2.0f*this->zoomFactor);

glOrtho(0, zoomedWidth, zoomedHeight, 0, 0, 1);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
}

Share this post


Link to post
Share on other sites
lightbringer    1070
You can either translate the objects to the new position or, ironically, make glOrtho work with the origin being at the center of the screen. Something like glOrtho(-zoomedWidth/2, zoomedWidth/2, zoomedHeight/2, -zoomedHeight/2, 0, 1); should do the trick.

Share this post


Link to post
Share on other sites
jyk    2094
Quote:
Original post by kibokun
After a lot of struggle with UnProject, I switched to glOrtho. It seems to work great for what I need, except zooming in and out. This was trivial with gluPerspective. :(


My problem is when I zoom out, it's as if the vanishing point in gluPerspective were the top left corner of the window. Everything shrinks into that corner when I really just want to zoom out and have objects stay in their place on the screen. What do I have to do to accomplish this?

Here's my function to change the glOrtho arguments



void GameplayState::SetProjection()
{
GLint viewport[4];
glGetIntegerv(GL_VIEWPORT, viewport);

int zoomedWidth = viewport[2] / (2.0f*this->zoomFactor);
int zoomedHeight = viewport[3] / (2.0f*this->zoomFactor);

glOrtho(0, zoomedWidth, zoomedHeight, 0, 0, 1);

glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
}
glOrtho() taks the left, right, bottom, and top bounds of the visible region as arguments. In your case, the view remains achored at a corner because you always make the top-left corner (0, 0). If you don't want the view to be anchored at the top-left corner, then don't achor the view at the top-left corner :)

It might help to think of your orthographic projection in terms of a center (focal) point, an aspect ratio, and a zoom value. Here's an example of how you might derive the glOrtho() arguments from these values:
float yExtent = zoom;
float xExtent = yExtent * aspectRatio;
float left = center.x - xExtent;
float right = center.x + xExtent;
// You can swap these if you want +y to go from top to bottom:
float bottom = center.y - yExtent;
float top = center.y + yExtent;
You can then move your virtual camera around by modifying its 'center' value, and zoom in and out by modifying the 'zoom' value.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Similar Content

    • By Zaphyk
      I am developing my engine using the OpenGL 3.3 compatibility profile. It runs as expected on my NVIDIA card and on my Intel Card however when I tried it on an AMD setup it ran 3 times worse than on the other setups. Could this be a AMD driver thing or is this probably a problem with my OGL code? Could a different code standard create such bad performance?
    • By Kjell Andersson
      I'm trying to get some legacy OpenGL code to run with a shader pipeline,
      The legacy code uses glVertexPointer(), glColorPointer(), glNormalPointer() and glTexCoordPointer() to supply the vertex information.
      I know that it should be using setVertexAttribPointer() etc to clearly define the layout but that is not an option right now since the legacy code can't be modified to that extent.
      I've got a version 330 vertex shader to somewhat work:
      #version 330 uniform mat4 osg_ModelViewProjectionMatrix; uniform mat4 osg_ModelViewMatrix; layout(location = 0) in vec4 Vertex; layout(location = 2) in vec4 Normal; // Velocity layout(location = 3) in vec3 TexCoord; // TODO: is this the right layout location? out VertexData { vec4 color; vec3 velocity; float size; } VertexOut; void main(void) { vec4 p0 = Vertex; vec4 p1 = Vertex + vec4(Normal.x, Normal.y, Normal.z, 0.0f); vec3 velocity = (osg_ModelViewProjectionMatrix * p1 - osg_ModelViewProjectionMatrix * p0).xyz; VertexOut.velocity = velocity; VertexOut.size = TexCoord.y; gl_Position = osg_ModelViewMatrix * Vertex; } What works is the Vertex and Normal information that the legacy C++ OpenGL code seem to provide in layout location 0 and 2. This is fine.
      What I'm not getting to work is the TexCoord information that is supplied by a glTexCoordPointer() call in C++.
      Question:
      What layout location is the old standard pipeline using for glTexCoordPointer()? Or is this undefined?
       
      Side note: I'm trying to get an OpenSceneGraph 3.4.0 particle system to use custom vertex, geometry and fragment shaders for rendering the particles.
    • By markshaw001
      Hi i am new to this forum  i wanted to ask for help from all of you i want to generate real time terrain using a 32 bit heightmap i am good at c++ and have started learning Opengl as i am very interested in making landscapes in opengl i have looked around the internet for help about this topic but i am not getting the hang of the concepts and what they are doing can some here suggests me some good resources for making terrain engine please for example like tutorials,books etc so that i can understand the whole concept of terrain generation.
       
    • By KarimIO
      Hey guys. I'm trying to get my application to work on my Nvidia GTX 970 desktop. It currently works on my Intel HD 3000 laptop, but on the desktop, every bind textures specifically from framebuffers, I get half a second of lag. This is done 4 times as I have three RGBA textures and one depth 32F buffer. I tried to use debugging software for the first time - RenderDoc only shows SwapBuffers() and no OGL calls, while Nvidia Nsight crashes upon execution, so neither are helpful. Without binding it runs regularly. This does not happen with non-framebuffer binds.
      GLFramebuffer::GLFramebuffer(FramebufferCreateInfo createInfo) { glGenFramebuffers(1, &fbo); glBindFramebuffer(GL_FRAMEBUFFER, fbo); textures = new GLuint[createInfo.numColorTargets]; glGenTextures(createInfo.numColorTargets, textures); GLenum *DrawBuffers = new GLenum[createInfo.numColorTargets]; for (uint32_t i = 0; i < createInfo.numColorTargets; i++) { glBindTexture(GL_TEXTURE_2D, textures[i]); GLint internalFormat; GLenum format; TranslateFormats(createInfo.colorFormats[i], format, internalFormat); // returns GL_RGBA and GL_RGBA glTexImage2D(GL_TEXTURE_2D, 0, internalFormat, createInfo.width, createInfo.height, 0, format, GL_FLOAT, 0); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); DrawBuffers[i] = GL_COLOR_ATTACHMENT0 + i; glBindTexture(GL_TEXTURE_2D, 0); glFramebufferTexture(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0 + i, textures[i], 0); } if (createInfo.depthFormat != FORMAT_DEPTH_NONE) { GLenum depthFormat; switch (createInfo.depthFormat) { case FORMAT_DEPTH_16: depthFormat = GL_DEPTH_COMPONENT16; break; case FORMAT_DEPTH_24: depthFormat = GL_DEPTH_COMPONENT24; break; case FORMAT_DEPTH_32: depthFormat = GL_DEPTH_COMPONENT32; break; case FORMAT_DEPTH_24_STENCIL_8: depthFormat = GL_DEPTH24_STENCIL8; break; case FORMAT_DEPTH_32_STENCIL_8: depthFormat = GL_DEPTH32F_STENCIL8; break; } glGenTextures(1, &depthrenderbuffer); glBindTexture(GL_TEXTURE_2D, depthrenderbuffer); glTexImage2D(GL_TEXTURE_2D, 0, depthFormat, createInfo.width, createInfo.height, 0, GL_DEPTH_COMPONENT, GL_FLOAT, 0); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); glBindTexture(GL_TEXTURE_2D, 0); glFramebufferTexture(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, depthrenderbuffer, 0); } if (createInfo.numColorTargets > 0) glDrawBuffers(createInfo.numColorTargets, DrawBuffers); else glDrawBuffer(GL_NONE); if (glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE) std::cout << "Framebuffer Incomplete\n"; glBindFramebuffer(GL_FRAMEBUFFER, 0); width = createInfo.width; height = createInfo.height; } // ... // FBO Creation FramebufferCreateInfo gbufferCI; gbufferCI.colorFormats = gbufferCFs.data(); gbufferCI.depthFormat = FORMAT_DEPTH_32; gbufferCI.numColorTargets = gbufferCFs.size(); gbufferCI.width = engine.settings.resolutionX; gbufferCI.height = engine.settings.resolutionY; gbufferCI.renderPass = nullptr; gbuffer = graphicsWrapper->CreateFramebuffer(gbufferCI); // Bind glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo); // Draw here... // Bind to textures glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, textures[0]); glActiveTexture(GL_TEXTURE1); glBindTexture(GL_TEXTURE_2D, textures[1]); glActiveTexture(GL_TEXTURE2); glBindTexture(GL_TEXTURE_2D, textures[2]); glActiveTexture(GL_TEXTURE3); glBindTexture(GL_TEXTURE_2D, depthrenderbuffer); Here is an extract of my code. I can't think of anything else to include. I've really been butting my head into a wall trying to think of a reason but I can think of none and all my research yields nothing. Thanks in advance!
    • By Adrianensis
      Hi everyone, I've shared my 2D Game Engine source code. It's the result of 4 years working on it (and I still continue improving features ) and I want to share with the community. You can see some videos on youtube and some demo gifs on my twitter account.
      This Engine has been developed as End-of-Degree Project and it is coded in Javascript, WebGL and GLSL. The engine is written from scratch.
      This is not a professional engine but it's for learning purposes, so anyone can review the code an learn basis about graphics, physics or game engine architecture. Source code on this GitHub repository.
      I'm available for a good conversation about Game Engine / Graphics Programming
  • Popular Now