![]() Then, having my Depth Test set to GL_LESS would make perfect sense, matter of fact this should be the case regardless of what my Z_NEAR and Z_FAR are because of the way that glDepthRange maps the values, if I'm not mistaken. I was under the assumption that glDepthRange(0.0f, 1.0f) would cause objects closer to my Z_NEAR (-0.1) to be closer to 0 and objects closer to my Z_FAR(-1000) to be closer to 1. Now that I had reliable behavior and no more depth-fighting it was a matter of reversing the draw order, and so I changed my call to glDepthRange to the following: glDepthRange(1.0f, 0.0f) This is my first question, why would this line of code cause more reliable behavior? The addition of this line of code caused every bit of z-fighting to go away, except now the depth buffer was completely backwards, vertices further away were being reliably drawn on top of vertices in front. ![]() First, I added this line to the end of my main function in my vertex shader: gl_Position.z = 0.0001+vertexInScreenSpace.z The only time I have no issues is standing inside of the first model being drawn, then nothing flickers and I can view the inside of Suzanne's head just as I should be able to.Īfter weeks of trying anything I could possibly think of I finally worked my way to a solution which involves changing/adding a mere two lines of code. This code results in all transformations and normal calculations (not included) to be done correctly, however each face of my models constantly fighting to be above all the others. Vec4 vertexInDeviceSpace = vec4(_inverseScreenDimensions * vertexInScreenSpace) Transform to device coordinates and store Vec4 vertexInScreenSpace = vec4(_cameraPerspective * vertexInCameraSpace) Vec4 vertexInCameraSpace = vec4(_cameraTransformation * vertexInWorldSpace) Vec4 vertexInWorldSpace = vec4(_modelTransformation *_vertexPosition) Indicates whether a vertex is valid or not, non valid vertices will not be drawn. So any vector representing a position in screen space must be multiplied by this vector before display This is used because GLSL normalizes viewport from -1 to 1 Uniform location of inverse screen dimensions Uniform location of camera transformations Uniform location of model transformation matrix Layout(location = 1) in vec4 _vertexNormal Layout(location = 0) in vec4 _vertexPosition The final segment of code which seems to be involved in the problem is my vertex shader: #version 330 core Which causes my viewport to follow a right handed coordinate system. However, before I go on it may be important to specify the following values: X_LEFT = -1000 ![]() obj files, and initializing instances of a ModularGameObject class, attaching the meshes to them, nothing that touches any relevant glut/glew. ![]() GlOrtho(X_LEFT, X_RIGHT, Y_DOWN, Y_UP, Z_NEAR, Z_FAR) Īnything beyond that point just includes initializing various engine components, loading the. Program uses a right handed coordinate system. These values can be found in constants.h Set scale and dimensions of orthographic viewport Then I initialize my program (Leaving segments out for readability and lack of relevance): //Remove cursor GlutInitWindowPosition(WINDOW_XPOS, WINDOW_YPOS) GlutInitWindowSize(WINDOW_WIDTH, WINDOW_HEIGHT) Size and position attributes can be found in constants.h GlutInitDisplayMode(GLUT_DOUBLE | GLUT_DEPTH | GLUT_RGB) Also, understand that I have fixed the issue, and at the end of my post I will explain what fixed the problem, however I do not understand why the problem was fixed through my solution.įirst I initialize GLUT & GLEW: //Initialize openGL I have been working on the beginnings of an engine for educational pursuit and I've run into an OpenGL concept which I THOUGHT I understood, however I cannot explain the behavior I've been observing. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |