and this time i have loaded a model successfully! yay!!
but theres a slight problem, one that i had with another obj loader...
heres what it looks like:
http://img132.imageshack.us/i/newglitch2.jpg/
heres another angle if u cant see it right away:
http://img42.imageshack.us/i/newglitch3.jpg/
now this is supposed to look like a cube, but as you can see, the edges of the faces on the cube are being very choppy
is anyone else having this problem, or if anyone knows how to solve this then let me know
also comment if theres any code that needs to be shown, ill be happy to post it.
hey i played around with the code(changed some stuff) and this is what i have come up with
ORIGINAL:
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(50.f,(double)800 / (double)600,0.f,200.f);
glTranslatef(0.f, 0.f, -10.0f);
result: choopy image(look at images)
CURRENT:
glMatrixMode(GL_MODELVIEW);
gluPerspective(50.f,(double)800 / (double)600,0.f,200.f);
glTranslatef(0.f, 0.f, -50.0f);
glLoadIdentity();
result: model is not choppy but cannot move camera(model is right in front of me)
gluPerspective(50.f,(double)800 / (double)600,0.f,200.f);
^^^
|
That's your problem right there ---------------+
The near clip distance must be greater than 0 for perspective projections. Actually you should choose near to be as far away as possible and the far clip plane to be as near as possible.
Say your depth buffer is 16 bits wide, then you slice the scene into 32768 slices. The slice distribution follows a 1/x law. Technically you're dividing by zero.
Well this looks like a projection setting issue. Some parts of your cube, when transformed into clip space, exceed near/far planes.
From what I see you are using orthogonal projection matrix - it's standard for making 2D UI. Please review nearVal and farVal of your glOrtho call. For 2D UI they are usually set as -1 and 1 respectively (or 0 and 1), so may want to either scale down cube or increase view frustum depth by modifying mentioned parameters.
Related
Please see the following image:
Which mathematical method or POV-Ray/OpenGL command will lessen the convergence of a grid like this? (The grid converges too quickly; theta should be 90 degrees, matching the center line, for this purpose.)
Perspective is still desired, but convergence should happen at a slower rate, as if the distance was shorter or you were using a telephoto lens.
Although this image is from Blender, the methods being used are OpenGL and POV-Ray so a solution in either method would be appreciated.
I have some lines modeled in OpenGL and POV-Ray.
I have tried location, look--at, angle, right and up in POV-Ray, including camera transformations like rotate, scale, translate and matrix.
In OpenGL I have tried gluPerspective, glFrustum and glDepthRange.
Does anyone have a solution to this problem?
(Also, looking down on the grid is not an option in this case)
You're after an orthographic projection...
glOrtho()
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(left, right, bottom, top, near, far);
glMatrixMode(GL_MODELVIEW);
It's always nice to be able to swap between orthographic and perspective though since moving around a scene in orthographic can take a while to get used to.
There's an image here... https://blender.stackexchange.com/questions/648/what-are-the-differences-between-orthographic-and-perspective-views
edit
To keep using perspective, but with less perspective effect, you can decrease the field of view parameter. Unfortunately this will make the projection appear to zoom in. To undo the zoom, move the camera back. You can then update the near/far accordingly if need be.
I'm new to OpenGL and I've been experiencing the "Black Screen Effect". I've spent ages trying to work out why I'm not seeing anything and I haven't had much success. I'm using LWJGL and here is the piece of code I'm trying to run:
glViewport(0,0,DISPLAY_WIDTH,DISPLAY_HEIGHT);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho( 6200000.0f, 6300000.0f, 350000.0f, 380000.0f, -10000000.0f, 100000000.0f);
gluLookAt(368000.0f, 6250000.0f, -10000.0f, 368000.0f, 6250000.0f, 10000.0f, 0.0f,1.0f,0.0f);
glPushMatrix();
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glPushMatrix();
if(ready)
{
glColor3f(1.0f,0.5f,1.0f);
glPointSize(100);
glBegin(GL_POINTS);
for(int i = 0; i < data.length; i += 100)
{
glColor3f(1.0f,1.0f,1.0f);
glVertex3f((float) data[i][1], (float) data[i][2],0.0f);
System.out.println((float) data[i][1] + ", " + (float) data[i][2]);
}
glEnd();
System.out.println("\n\nfinished drawing\n\n");
glFlush();
I am drawing in a different colour that i used to clear the screen.
My data set is quite large (over 100 000 points) so I tried plotting every hundredth point, but that's not working.
I am also trying to plot points at positions such as (400 000, 6 800 000) would this be presenting me with problems? I'm pretty sure that 32bit floating point numbers should be able to handle these values.
I am pretty certain that a pixel with size=1 will try to plot as 1 pixel on the screen, regardless of how small it is compared with the bounds of the orthographic projection.
Maybe I'm dealing with the projection matrix incorrectly.
First, like said in my comment don't use gluLookAt on the projection matrix. It defines the camera (view) and therefore belongs to the model view matrix. This isn't the cause for your problem and it should also work this way, but it is conceptually wrong.
Next, if you call this code every frame, you push a new matrix onto the stack every frame, without calling glPopMatrix. glPushMatrix is generally there to save the current matrix and restore it later with a call to glPopMatrix, because every other command (like glLoadIdentity, but also gluLookAt and glOrtho) modifies the current matrix (the one selected by glMatrixMode).
Otherwise, you should always keep the size of your scene in relation to the viewing volume (the glOrtho parameters in your case) in mind. At the moment you're looking from point (368000, 6250000, -10000) to point (368000, 6250000, 10000). Together with the glOrtho parameters this should define your viewing volume to be the [368000-6300000 , 368000-6200000] x [6250000+350000 , 6250000+380000] x [-10000000-10000, 100000000-10000] box. If you don't transform your points further by any local transformations, their coordinates should ly in these intervals to be visible. Keep an eye on the minus in the x-interval. This is due to the fact that you actually rotated the view volume 180 degrees around the y-axis, because you defined the view to look from -z to z, whereas GL's default eye-space defines the viewer to look from z to -z (which usually is not that much of a problem with an origin-symmetric viewing volume, but yours is highly asymmetric).
Although your numbers are extremely strange they should be handlable by 32bit floats. But are you really sure you want your points to have a size of 100 pixels (if this is even supported)?
And if you only draw 2D points in an orthographic view, I'm also not sure if you need such a HUGE depth range.
I am learning OpenGL and having a problem with gluPerspective. Here is the code I use in Init()
// Calculate The Aspect Ratio Of The Window
// The parameters are:
// (view angle, aspect ration of the width to the height,
// The closest distance to the camera before it clips,
// FOV, Ratio, The farthest distance before it stops drawing)
gluPerspective(45.0f,(GLfloat)width/(GLfloat)height, 0.5f, 3000.0f);
My scene works right.. but as soon as I go a little bit away from my objects they dissapear (As the red balls in image). :
Web where I took graph from
I understand that red balls are outside of view and won't be shown. So what I want is to increase the distance where it stops drawing. I tried increasing 3000.0f but is not working!.
gluPerspective(45.0f,(GLfloat)width/(GLfloat)height, 0.5f, 3000000.0f);
So my question is : How can I increase distance where openGL stops drawing objects?
Some pics about the problem:
Pic1
Pic2
I figured out what was happening so I answer this myself to help other people in the future:
Changing zfar works ok. The problem I had was (not included in the question for simplification) was my skybox. Skybox was small and was hiding the objects with the sky. In pic2 is easy to see!
So if you have a similar problem just double check your skybox. If it were a zfar problem everthing should
be black instead of having a sky texture!
The near and far values define the precision of the depth buffer. The higher the ratio between near and far is the more depth buffer precision errors you will get. Thus your depth buffer might actually allow to draw the objects but if they are small and close to each other they still might not be visible (rejected or be overdrawn).
If you increase from 3000.0f to 10000.0f it might still work. How big are your objects?
Why do you need that big viewing distance in the first place? Maybe there are other approaches that better fit your needs.
i have implemented first person camera in OpenGL, but when i get closer to an object it starts to disappear, so i want to set near plane close to zero so i could get closer to the objects. So if anybody can tell me what is the best way to do that.
Thank you.
Other responses focus on using glut. Glut is not recommended for professional, or even modern, development, and the OP says nothing about using glut - just OpenGL. So, I'll chime in:
A little background
zNear, the distance from the origin to the near clip plane, is one of the parameters used to build the projection matrix:
Projection Matrix
Where
SYMBOL MEANING TYPICAL VALUE
------ -------------- -------------
fov vertical field of view 45 – 90 degrees
aspect Aspect ratio around 1.8 (frame buffer Width / Height)
znear near clip plane +1
zfar far clip plane. 10
SYMBOL MEANING FORMULA
---------- ------------------------------- --------------
halfHeight half of frustum height at znear znear∗tan(fov/2)
halfWidth half of frustum width at znear halfHeight×aspect
depth depth of view frustum zfar−znear
(More nicely-formatted version on http://davidlively.com/programming/graphics/opengl-matrices/perspective-projection/)
When the perspective divide takes place - between the vertex and fragment shaders - the vertices are converted to normalized device coordinates (NDC), in "clip space." In this space, anything that fits in a 2x2x1 (x,y,z) box will be rendered. Any fragments that don't fit in a box with corners (-1, -1, 0) - (+1, +1, +1) will be clipped.
Practical Upshot Being
It doesn't matter what your zNear and zFar values are, as long as they offer sufficient resolution & precision, and zFar > zNear > 0.
Your collision detection & response system is responsible for keeping the camera from getting too close to the geometry. "Too close" is a function of your zNear and geometry bounds. Even if you have a zNear of 1E-9, geometry will get clipped when it gets too close to the clip space origin.
So: fix your collision detection and stop worrying about your zNear.
So if anybody can tell me
gluPerspective.
The near plane is set when you set the projection matrix, either with glFrustum or glOrtho. One of the parameters is the near plane. Notice that the distance to the near plane must be > 0.
You don't have many options.
Cast some rays from the camera (for instance in the 4 corners and in the center), take the shortest minus epsilon, clamped to a decent value > 0. 0.1f will do.
Simply forbid the camera to be here in the first place ! For this you can link it to a sphere in your physics engine, check whether it intersects something, and it it does, move it (how and where to move it is your problem since it's for a large part gameplay. Think of Super Mario Galaxy)
Never set a too little nearPlane. You will run in precision issues with your z-buffer. The farPlane can be quite large though. Values like (0.1, 1000) can be all right depending on your application
I'm trying to do a simple rotation in OpenGL but must be missing the point.
I'm not looking for a specific fix so much as a quick explanation or link that explains OpenGL rotation more generally.
At the moment I have code like this:
glPushMatrix();
glRotatef(90.0, 0.0, 1.0, 0.0);
glBegin(GL_TRIANGLES);
glVertex3f( 1.0, 1.0, 0.0 );
glVertex3f( 3.0, 2.0, 0.0 );
glVertex3f( 3.0, 1.0, 0.0 );
glEnd();
glPopMatrix();
But the result is not a triangle rotated 90 degrees.
Edit
Hmm thanks to Mike Haboustak - it appeared my code was calling a SetCamera function that use glOrtho. I'm too new to OpenGL to have any idea of what this meant but disabling this and rotating in the Z-axis produced the desired result.
Ensure that you're modifying the modelview matrix by putting the following before the glRotatef call:
glMatrixMode(GL_MODELVIEW);
Otherwise, you may be modifying either the projection or a texture matrix instead.
Do you get a 1 unit straight line? It seems that 90deg rot. around Y is going to have you looking at the side of a triangle with no depth.
You should try rotating around the Z axis instead and see if you get something that makes more sense.
OpenGL has two matrices related to the display of geometry, the ModelView and the Projection. Both are applied to coordinates before the data becomes visible on the screen. First the ModelView matrix is applied, transforming the data from model space into view space. Then the Projection matrix is applied with transforms the data from view space for "projection" on your 2D monitor.
ModelView is used to position multiple objects to their locations in the "world", Projection is used to position the objects onto the screen.
Your code seems fine, so I assume from reading the documentation you know what the nature of functions like glPushMatrix() is. If rotating around Z still doesn't make sense, verify that you're editing the ModelView matrix by calling glMatrixMode.
The "accepted answer" is not fully correct - rotating around the Z will not help you see this triangle unless you've done some strange things prior to this code. Removing a glOrtho(...) call might have corrected the problem in this case, but you still have a couple of other issues.
Two major problems with the code as written:
Have you positioned the camera previously? In OpenGL, the camera is located at the origin, looking down the Z axis, with positive Y as up. In this case, the triangle is being drawn in the same plane as your eye, but up and to the right. Unless you have a very strange projection matrix, you won't see it. gluLookat() is the easiest command to do this, but any command that moves the current matrix (which should be MODELVIEW) can be made to work.
You are drawing the triangle in a left handed, or clockwise method, whereas the default for OpenGL is a right handed, or counterclockwise coordinate system. This means that, if you are culling backfaces (which you are probably not, but will likely move onto as you get more advanced), you would not see the triangle as expected. To see the problem, put your right hand in front of your face and, imagining it is in the X-Y plane, move your fingers in the order you draw the vertices (1,1) to (3,2) to (3,1). When you do this, your thumb is facing away from your face, meaning you are looking at the back side of the triangle. You need to get into the habit of drawing faces in a right handed method, since that is the common way it is done in OpenGL.
The best thing I can recommend is to use the NeHe tutorials - http://nehe.gamedev.net/. They begin by showing you how to set up OpenGL in several systems, move onto drawing triangles, and continue slowly and surely to more advanced topics. They are very easy to follow.
Regarding Projection matrix, you can find a good source to start with here:
http://msdn.microsoft.com/en-us/library/bb147302(VS.85).aspx
It explains a bit about how to construct one type of projection matrix. Orthographic projection is the very basic/primitive form of such a matrix and basically what is does is taking 2 of the 3 axes coordinates and project them to the screen (you can still flip axes and scale them but there is no warp or perspective effect).
transformation of matrices is most likely one of the most important things when rendering in 3D and basically involves 3 matrix stages:
Transform1 = Object coordinates system to World (for example - object rotation and scale)
Transform2 = World coordinates system to Camera (placing the object in the right place)
Transform3 = Camera coordinates system to Screen space (projecting to screen)
Usually the 3 matrix multiplication result is referred to as the WorldViewProjection matrix (if you ever bump into this term), since it transforms the coordinates from Model space through World, then to Camera and finally to the screen representation.
Have fun