Hi everyone, I’m new to OpenGL and have a problem when I try to render a transparent texture of a container with a bunch of smaller boxes.
I added the alpha channel for the transparent texture (cardboard with crossing tapes on) using GIMP and set the alpha value 0.25.
As you can see from the attachment, I got something similar but not good enough. When I turn the view position from the top right corner of the box, the LEFT and BOTTOM sides are not rendered properly, no tapes show up. When I turn the view to the top left corner, then RIGHT and BOTTOM are wrong again.
Could anyone help me please? Any comments/hints/ suggestions would be appreciate! Thank you so much!
[ATTACH=CONFIG]1515[/ATTACH]
I think it may be the problem because the render indices of whichever incorrect rendered side are always reversed because of the orientation of view. How should I solve this question then? I read something about blending and alpha test but not sure how I should use them.
there are different ways / techniques to achieve transparency. what Silence stated is 1 solution, another is a bit bore difficult, called “Order-Independent-Transparency” (OIT), it allows you to skip the otherwise required depth-sorting of transparent shapes. however, any approach requires backface culling to be disabled, because they are still visible when covered by transparent (front) faces:
glDisable(GL_CULL_FACE);
by default, culling is disabled, which means that you’ve enabled it somewhere in your code (if that’s the issue)
[QUOTE=tri_thinggg;1288043]
I think it may be the problem because the render indices of whichever incorrect rendered side are always reversed because of the orientation of view. How should I solve this question then? I read something about blending and alpha test but not sure how I should use them.[/QUOTE]
Blending must be enabled to get the appearance of translucency. Without it, each fragment that’s rendered simply overwrites the corresponding pixel in the framebuffer.
Alpha testing isn’t relevant here. It’s used when you want to use a texture’s alpha channel as a binary mask.
You need to render primitives in a defined order. Decreasing distance (back to front) is usually simpler, as it doesn’t require the framebuffer to have an alpha channel. Actually, you need to render the fragments in a defined order; sorting the primitives is one solution, but more advanced techniques sort the fragments. In the general case you need to use a topological sort, and you may need to explicitly break cycles. In some cases, you may be able to get away with sorting by the greatest/least/average Z coordinate of the primitive’s vertices.
You can’t use depth-testing because a nearer primitive will completely prevent the rendering of a farther primitive, but translucency requires rendering both.
Thank for all of you! I solved the problem using sorting.
And, now I have a new problem:/
I finished the coding part for my Opengl rendering project in VS 2015 and I used glew, glfw, glm these libraries with spearated camera headerfile and shader headerfile. Right now, the dimension of these cubes are hard-coded in the main.cpp.
Is there any way for me to integrate my code with QT creator to let users input cube dimensions using keyboard, and the UI will receive these data and send to render new cubes?
I read that GLFW and QGLWidget might get conflicts, is that true?
If so, should I rearrange all of the my codes in QT creator and using QTWidget instead of GLFW?
Also, my project involves different 2 threads. Is there anything I need to pay attention to when integrating my code with QT GUI?
If you’re going to be using Qt, you should use QGLWidget rather than GLFW.
Use QThread rather than creating threads using native APIs (pthread_create(), CreateThread(), etc). Don’t call Qt methods from a thread other than the main thread unless the documentation specifies the method as being thread-safe. Ensure that an OpenGL context isn’t current in more than one thread at a time.
You don’t need QtCreator to program with Qt. VS will work as well too.
Qt already provides what GLFW provides. So use one or the other, but not both. It will be the same for glew. And AFAIR Qt also provides vectors and matrices.
You have another option. Other GUI libraries like this one exist. So if you want to move this way, choose carefully the right one. Also note that these libraries might become slow if your user interface will become heavy. If not, then they will certainly run more fast, use less CPU, require less dependencies and less effort for the transition than moving to Qt. Also, and as a side-note, read carefully about the Qt licenses.
Most probably the Qt OpenGL widget will run on the main thread.
Thank you so much for your help!
One more quick question is that is there any difference if I use QGLWidget or QOpenGLWidget? I read that QOpenGLWidget is more updated than QGLWidget? Which one should I use then? I’m using Qt 5.9 and OpenGL 3.3 version.
[QUOTE=Silence;1288091]You don’t need QtCreator to program with Qt. VS will work as well too.
Qt already provides what GLFW provides. So use one or the other, but not both. It will be the same for glew. And AFAIR Qt also provides vectors and matrices.
Thank you so much for your help!
One more quick question is that is there any difference if I use QGLWidget or QOpenGLWidget? I read that QOpenGLWidget is more updated than QGLWidget? Which one should I use then? I’m using Qt 5.9 and OpenGL 3.3 version.
[QUOTE=Silence;1288091]You don’t need QtCreator to program with Qt. VS will work as well too.
Qt already provides what GLFW provides. So use one or the other, but not both. It will be the same for glew. And AFAIR Qt also provides vectors and matrices.
You have another option. Other GUI libraries like this one exist. So if you want to move this way, choose carefully the right one. Also note that these libraries might become slow if your user interface will become heavy. If not, then they will certainly run more fast, use less CPU, require less dependencies and less effort for the transition than moving to Qt. Also, and as a side-note, read carefully about the Qt licenses.
Most probably the Qt OpenGL widget will run on the main thread.[/QUOTE]
Thank you so much for your help!
One more quick question is that is there any difference if I use QGLWidget or QOpenGLWidget? I read that QOpenGLWidget is more updated than QGLWidget? Which one should I use then? I’m using Qt 5.9 and OpenGL 3.3 version.
If you’re going to be using Qt, you should use QGLWidget rather than GLFW.
Use QThread rather than creating threads using native APIs (pthread_create(), CreateThread(), etc). Don’t call Qt methods from a thread other than the main thread unless the documentation specifies the method as being thread-safe. Ensure that an OpenGL context isn’t current in more than one thread at a time.[/QUOTE]
Thank you so much for your reply!
One more quick question is that is there any difference if I use QGLWidget or QOpenGLWidget? I read that QOpenGLWidget is more updated than QGLWidget? Which one should I use then? I’m using Qt 5.9 and OpenGL 3.3 version.
[QUOTE=tri_thinggg;1288100]
One more quick question is that is there any difference if I use QGLWidget or QOpenGLWidget? I read that QOpenGLWidget is more updated than QGLWidget? Which one should I use then? I’m using Qt 5.9 and OpenGL 3.3 version.[/QUOTE]
QGLWidget is deprecated in Qt 5; use QOpenGLWidget instead.