Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 5 years ago.
Improve this question
So I've been hammering away at my code for a while, trying to resolve this bug, with absolutely no progress being made.
Mostly due to how utterly random and unpredictable this bug is.
So this is how the scene works when everything is working fine
And when the bug kicks in
As you can see, the bug only prevents my cubemap skybox, model, and light source mesh from rendering, but the ortho projected 2d elements are just fine.
I've ruled out shaders, as even the simplest of shader programs still experience this problem. I use ASSIMP to load in mesh files and SOIL to load textures, but up until about a day ago they have worked flawlessly.
There is absolutely no pattern to when this happens, the only way to resolve it is to just keep restarting the program until the desired output appears. That is obviously not a good solution. I'm at a complete loss and need help, as opengl doesn't push out an error or anything. I don't know where to even begin looking for a solution. Could EBO's or frame buffers cause this? As I have started implementing those recently.
I have searched far and wide for anything that could be related to this, but I have come up with nothing so far.
TL;DR: 3D objects will not render only on some runs and work fine on others, possible issues with recently implemented framebuffers and EBOs.
UPDATE:
It turns out that my mouse look code in my Camera class was causing some odd issues where calculating the change in camera angles caused it to be set to an extraordinarily high negative value. Turning mouse look off permanently resolved the issue.
Related
I apologise for the limited code in this question, but It's tied into a personal project with much OpenGL functionality abstracted behind classes. Hoping someone visually recognises the problem and can offer direction.
During the first execution of my animation loop, I'm creating a GL_R32F (format: GL_RED, type: GL_FLOAT) texture, rendering an orthographic projection of a utah teapot to it (for the purposes of debugging this I'm writing the same float to every fragment).
The texture however renders incorrectly, as it should be a solid silhouette.
Re-running the the program causes the patches to move around.
I've spent a good few hours tweaking things trying to work out the cause, I've compared the code to my working shadow mapping example which similarly writes to a GL_R32F texture, yet I can't find a cause.
I've narrowed it down, to find that it's only the first renderpass to the texture which this occurs. This wouldn't be so much of an issue except I don't require more than a single render (and looping the bindFB, setViewport, render, unbindFB doesn't fix it).
I've
If anyone has an suggestions for specific code extracts to provide, I'll try and edit the question.
This was caused by a rogue call to glEnable(GL_BLEND) during an earlier stage of the algorithm.
This makes sense because I was writing to a single channel, therefore the Alpha channel would contain random garbage, leading to garbled texture.
I'll try to keep this as short as possible, and if there's any info you need you'll have to ask for it because the source is a bit too big to post here.
I have a strange bug when trying to change the projection currently in use. Ortographic works flawlessly but when I switch to using XMMatrixPerspectiveLH, my primitives are no longer visible on the screen. I've made sure the primitives aren't on the far plane, I've disabled culling completely, I've made sure my camera is looking in the right direction and that the primitives aren't behind me but still nothing.
What's even stranger is that XMMatrixPersectiveFovLH seems to work without problems too.
Anyways, I know this is a really broad question but I hope you'll atleast be able to point me in the right direction.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
I am using OpenGL 4.0, I have 3 things in my scene, they are-
1- VBO Plane
2- Cube maps
3- 3D models [3ds/obj]
I am using Assimp library to import 3D models, the code which I built to import models was done with the help of a tutorial on youtube from "TheCPlusPlusGuy".
Here is the issue I am facing, I can render the plane in my scene, I can render the cube maps, a.k.a. skyboxes, in my scene, I can render them together.
But When I am rendering any 3D model, be it .3ds or .obj, the screen doesn't update. Even if i resize the screen its not getting updated.
This only happens when I render a 3D model. I used flags and enabled drawing 3D models at runtime, the program runs fine until I render the models, once I render the models, the models itself do not appear on screen, but the screen again freezes.
I googled it, but no one else seems to be having an issue like this.
My primary diagnostic is because I am using VBO for planes, cubemaps, and 3D models I am having this issue.
Here's a list of suggestions:
Using VBOs is not the problem. Nor is using Assimp.
Make sure you've specified the proper number of indices and primitives in your buffer and draw calls, and that they are properly formatted. The OpenGL docs can be vague on what these numbers need to be (bytes, indices, triangles?) so make sure that's done well. The Wiki does a better job of explaining this.
Does your model actually get past the loading stage? Have you tried a very simple model?
Make sure you are only loading the model once (ie not in the rendering loop, and if so, there's a mechanism to ensure that it only loads once). Repeatedly telling your program to load a model will make it run very slowly and runs the risk of eating up all your memory.
Make sure you've translated the model properly from Assimp's data structures to your own. Check that values are being set properly. Load an OBJ and print the values you're copying - do they line up with the .obj file?
Do you have a valid OpenGL context at the time you're loading the model? Loading from Assimp doesn't require one, but going from that data structure to a VBO does.
I'm sure you've done a number of these things but I've had tricky times doing this task, too. Going through step by step will help you narrow down the problem.
I am using Assimp to import models in my editor, but Assimp is only used to read models and mesh data and the values are stored in my own model/mesh format. I assume we all do this? I have had no problems with Assimp, and I am also led to believe that skyboxes etc should be rendered after all other opaque objects so you can do a few tricks to minimize rendering time (skyboxes are to be considered as one of the furthest distant objects).
I am inclined to agree with Bartek. Assimp seems to be irrelevant to the problem you are having, and I would consider redesigning your rendering methods.
I forgot to do this after rendering the plane->
glBindVertexArray(0);
After that the program was working like a charm.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm trying to learn OpenGL. I've got experience with C and C++, setting up a build environment, and all that jazz, but I'm trying to figure out a good starting point.
I'm aware of the fixed function pipeline that was prominent in OpenGL <= 2.1, and it seems relatively easy to get started with. However, the core profile that OpenGL pushes in OpenGL >= 3.1 makes me want to stay away from the FFP due to deprecation. But I'm confused as to how it all works in 3.1 and above. In 2.1 and below you have your glBegin(GL_WHATEVER) and glEnd() when you're drawing shapes. The first thing I noticed when looking through the core profile API, is that those two function calls are gone. I realize there's probably a simple replacement, but it's quite shocking to see something so (seemingly useful) taken out of such a basic task. It almost seems like deprecating printf() from the c standard library. And when I work through the newest Red Book, they still use the old deprecated code which further muddles my thinking.
When reading through various answers to similar questions I see the typical "shader based" or "it's all done with shaders" etc etc. If I want to draw a simple white square onto a black background (the first example in the newest Red Book), I don't understand how a shader is relevant to drawing a box at all. Shouldn't they do... well.. shading? I've looked into buying the Orange Book and the Blue Book, but I don't want to spend anymore money on something that's going to hide it all behind a library (the Blue Book) or something that's going to talk about programming a shader to perform some lighting task in a 3D environment (the Orange Book).
So where do I begin? How do I draw a box (or a cube or a pyramid or whatever) using nothing but the core profile. I'm not asking for a code snippet here, I'm looking for a expansive tutorial or a book or something that someone could point me to. If this has been answered previously and I didn't find it, please redirect me.
The reason for the sudden "complexity" in the core profile is the fact that the fixed functionality pipeline was not representative of what the GPU actually does for you. Much of the functionality was done on the CPU, and only the actual drawing happened on the GPU. The other problem with the fixed pipeline is that it's a losing battle. The fixed pipeline has sooooooo many knobs and switches! So, not only is it painfully complicated already, it will never keep up with the endless demand of new ways to draw scenes. Enter GLSL, and you have the ability to tell the GPU precisely how you want to draw your scene. This shifts the power to the developer and frees everyone from having to wait for OpenGL updates for new switches/knobs.
Now, regarding your frustration with the sudden loss of glBegin and glEnd... there are simple frameworks that mimic their behavior on the new core profile, and that is a good thing. Again, it shifts the power to developers to choose how they approach the pipeline. However, there is nothing wrong with practicing 3D on the FFP. You need to learn 3D math and concepts first anyway. Those concepts apply regardless of API. (Matrix math will save your life both in OpenGL and Direct3D.) So, first you practice with simple triangles and colors. Then you move onto textures (with texture coordinates). Then you add normals (with lighting). Then, after you understand all those concepts, you stop using glBegin/glEnd, and you start batching large amounts of vertex data into buffers. You will not understand glDrawElements all that well if you do not understand glBegin/glEnd anyway. So, it's OK to learn on those tools.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 1 year ago.
Improve this question
I have a problem while running my game. The model that I import in the game is quite big, making the fps drop down. That's okay but when I get the camera off from the model, it still stays slow. As other games do, when looking at a high resolution model, the game slows down but when not looking at it, it gets faster. However my game stays slow all the time. Can anyone help me?
You need to implement clipping, so that you don't render the object (i.e. pass it through the graphics pipeline) when it's not visible.
There are many techniques and algorithms/data structures for this, ranging from manual view frustum-testing, to more advanced spatial-querying data structures (BSPs, quadtrees, octrees and so on).