1

I'm making a program using openGL with transparent objects in it, so obviously I have to paint those last. Unfortunately I was unaware of this requirement when beginning this project and now it would be a real pain to reorder it painting those at last.

I'm drawing objects by calling my drawing functions after translating and rotating the scene. There can be multiple translations and rotations before an actual drawing (e.g. first I draw the ground, then translate, then call the drawing of the house, which repeatedly translates and rotates, then calls the drawing of the walls and so on).

So my idea was saving the current modelview matrices in a list instead of painting the transparent objects when I normally would, then when I'm done with the opaque stuff, I iterate through my list and load each matrix and paint each object (a window, to be precise).

I do this for saving a matrix:

GLdouble * modelMatrix = (GLdouble *)malloc(16 * sizeof(GLdouble));
glGetDoublev(GL_MODELVIEW, modelMatrix);
addWindow(modelMatrix); // save it for later painting

And this is the "transparent stuff management" part:

/***************************************************************************
 *** TRANSPARENT STUFF MANAGEMENT ******************************************
**************************************************************************/

typedef struct wndLst {
    GLdouble * modelMatrix;
    struct wndLst * next;
} windowList;

windowList * windows = NULL;
windowList * pWindow;

void addWindow(GLdouble * windowModelMatrix) {
    pWindow = (windowList *)malloc(sizeof(windowList));
    pWindow->modelMatrix = windowModelMatrix;
    pWindow->next = windows;
    windows = pWindow;
}

void clearWindows() {
    while(windows != NULL) {
        pWindow = windows->next;
        free(windows->modelMatrix);
        free(windows);
        windows = pWindow;
    }
}

void paintWindows() {

    glPushMatrix(); // I've tried putting this and the pop inside the loop, but it didn't help either
        pWindow = windows;

        while(pWindow != NULL) {
            glLoadMatrixd(pWindow->modelMatrix);

            Size s;

            s.height = 69;
            s.width = 49;
            s.length = 0.1;

            glEnable(GL_BLEND);
            glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
            glDepthMask(GL_FALSE);

            glColor4f(COLOR_GLASS, windowAlpha);
            drawCuboid(s);

            glDepthMask(GL_TRUE);
            glDisable(GL_BLEND);

            pWindow = pWindow->next;
        }
    glPopMatrix();
}

/* INTERFACE
 * paint all the components, that are not yet painted,
 * then clean up.
 */
void flushComponents() {
    paintWindows();
    clearWindows();
}

/**************************************************************************/

I call flushComponents(); at the very end of my drawings.

The problem is, that the windows don't get in their place, instead I get weird-shaped blue objects randomly appearing and disappearing in my scene.

Am I doing something wrong? Or such matrix manipulations cannot even be used like this? Then what other method could I use for doing this?

Here is the full code if you need it: farm.zip Matrix-saving is at components.c line 1548, management is at line 142. It might not work on Windows without some minor hacking with the includes, which should probably be done in global.h.

Edit: I can only use C code and the glut library to write this program.

Edit 2: The problem is glGetDoublev not returning anything for some reason, it leaves the modelMatrix array intact. Though I still have no idea what causes this, I could make a workaround using bernie's idea.

KáGé
  • 823
  • 2
  • 12
  • 23
  • 1
    If you `#include `, you do not need to cast the return value from `malloc(3)` and friends -- in fact, those casts can actually hide mistakes. I suggest removing the casts. (And good luck with your actual problem. :) – sarnold Dec 04 '11 at 01:28
  • shouldn't it be `GL_MODELVIEW_MATRIX`, not `GL_MODELVIEW`? – Dmytro Dec 20 '17 at 22:45

2 Answers2

3

OpenGL is not a math library. You should not use it for doing matrix calculations. In fact that part has been completely removed from OpenGL-3. Instead you should rely on a specialized matrix math library. That allows you to calculate the matrices for each object with ease, without jumping through the hoops of OpenGL's glGet… API (which was never meat for this kind of abuse). For a good replacement look at GLM: http://glm.g-truc.net/

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • Thanks! This looks good, but unforunately I think I can't use it. This is a handin homework, which I have to write in C, I cannot use C++. Also, at class we use the plain old glut/openGL functions and I suppose they expect me to use those in this program as well. So is there no way I could fix this issue using only the tools that glut already provides? But thanks anyway, if I do an openGL project for my own good I'll definitely try this. – KáGé Dec 04 '11 at 14:22
  • 1
    Well, matrix math it not terribly difficult, it can be done in well under 1k LOC (so I'd just implement that instead). Tell your teacher, that using OpenGL matrix manipulation is discouraged and should not be done in newly written programs. If the teacher insists on you learning OpenGL matrix manupulations, give him a hardcopy of the OpenGL-3 core profile specification and ask him to show you the matrix functions there (he won't find them, except in which functions have been removed) and tell him you're learning for the future, that's you're not sitting through a computer history class. – datenwolf Dec 04 '11 at 15:22
  • 1
    Perhaps it's too much for a homework near the end of a semester :) Besides, even though what datenwolf said is true, I would be very surprised if that's the source of your problem. – bernie Dec 04 '11 at 16:18
1

Try adding glMatrixMode(GL_MODELVIEW) before your paintWindows() method. Perhaps you are not modifying the correct matrix.

The basic idea of your method is fine and is very similar to what I used for transparent objects. I would however advise for performance reasons against reading back the matrices from OpenGL. Instead, you can keep a CPU version of the current modelview matrix and just copy that to your window array.

As for your comment about push and pop matrix, you can safely put it outside the loop like you did.

edit

Strictly speaking, your method of rendering transparent objects misses one step: before rendering the list of windows, you should sort them back to front. This allows for overlapping windows to have the correct final color. In general, for 2 windows and a blending function:

blend( blend(scene_color, window0_color, window0_alpha), window1_color, window1_alpha )
!=
blend( blend(scene_color, window1_color, window1_alpha), window0_color, window0_alpha )

However, if all windows consist of the exact same uniform color (e.g. plain texture or no texture) and alpha value, the above equation is true (window0_color==window1_color and window1_alpha==window0_alpha) so you don't need to sort your windows. Also, if it's not possible to have overlapping windows, don't worry about sorting.

edit #2

Now you found something interesting with the erroneous matrix readback. Try it out with the following instead (you certainly don't need double precision):

GLfloat* modelMatrix = (GLfloat*)malloc(16 * sizeof(GLfloat)); // glass
glGetFloatv(GL_MODELVIEW, modelMatrix);
addWindow(modelMatrix); // save it for later painting

If that still doesn't work, you could directly store references to your houses in your transparent object list. During the transparent rendering pass, re-render each house, but only issue actual OpenGL draw calls for the transparent parts. In your code, putWallStdWith would take another boolean argument specifying whether to render the transparent or the opaque geometry. This way, your succession of OpenGL matrix manipulation calls would be redone for the transparent parts instead of read using glGetxxx(GL_MODEL_VIEW).

The correct way to do it however is to do matrix computation on the CPU and simply load complete matrices in OpenGL. That allows you to reuse matrices, control the operation precision, see the actual matrices easily, etc.

Community
  • 1
  • 1
bernie
  • 9,820
  • 5
  • 62
  • 92
  • Thanks! I've tried setting the matrix mode, but it didn't help. But as I was messing around, my program started crashing and flooding stdout with this: Mesa 7.10.2 implementation error: bad datatype in interpolate_int_colors Please report at bugs.freedesktop.org Mesa 7.10.2 implementation error: Invalid datatype in _mesa_convert_colors Please report at bugs.freedesktop.org I've googled it, and found [this thread](https://www.virtualbox.org/ticket/9718), which says that this error might be caused by using linux in a VM (which I do). So I ported my program to Windows and... – KáGé Dec 04 '11 at 11:41
  • ... this error did not occur, also the randomly appearing window-chunks were gone, but still no glass :( I really don't know what am I doing wrong, perhaps I will have to go with non-transparent or shitty-looking windows. – KáGé Dec 04 '11 at 11:43
  • By the way, what you've said about keeping a CPU version of a matrix instead of reading them back; how exactly do I do that? Sorry, I'm just a beginner with ogl, I haven't even heard of such thing before and my friend google didn't help either :P It might even work that way... – KáGé Dec 04 '11 at 11:49
  • If you render them non-transparently like the other objects, do they show up at the correct place? – bernie Dec 04 '11 at 16:19
  • Ah! Well in that case this narrows down the possible culprits to the actual model-view matrix you use or the `drawCuboid` function. – bernie Dec 04 '11 at 17:21
  • Now I've gone into some more detailed debugging with Visual Studio and found that the matrices remain intact after the call to glGet: I print them after the malloc then after the glGet and they're all filled with -0.00 somethings both times. I've googled about and this thread was the closest thing I could find: http://stackoverflow.com/questions/5419960/glgetintegerv-glgetfloatv-android-ndk There they say that it's unimplemented for that implementation, could that be the problem for me as well? – KáGé Dec 04 '11 at 22:51
  • Thanks! I've tried the float version and that did the same as well, but I like your other idea, I haven't thought about that. :P – KáGé Dec 05 '11 at 09:34