Jakub M.
Jakub M.

Reputation: 33827

OpenGL: Implementing transformation matrix stack

In a newer OpenGL there is no matrix stack. I am working on a simple display engine, and I am going to implement the transformation stack.

What is a common strategy here? Should I build a push/pop stack, and use it with a tree representing my model? I suppose this is the "old" approach, that was deprecated in the newer OpenGL versions. Maybe then it is not the best solution (it was removed for some reason, unknown to me)

Upvotes: 6

Views: 1578

Answers (4)

Robinson
Robinson

Reputation: 10122

Not sure if it's any use to you, but I implemented two things for this. The first is a simple matrix stack class with all the usual methods and the second is a stack based RAII structure that allows me to scope matrix changes with braces, i.e. on construction it stores a reference to the matrix stack and on destruction it restores the matrix stack back to its previous state. So you can write:

MatrixStack stack;

stack.push(rotate...)
stack.push(translate...)

{
    MatrixScope(stack);

    stack.push(rotate...)    
}

... back to previous stack state.

And to add to this, it's just for convenience with certain kinds of transforms. Generally for models composed of a tree structure of meshes, all transformed relative to one another, I will combine the matrices from the root node down before I do anything with the model. So each mesh has a local transform and a global transform, the global transform being the actual transform for that mesh relative to the root node. So no need to use a matrix stack there.

It's a bit different if you want to animate a part of the mesh independently of the rest, so that's why I also store the local transform rather than throwing it away.

Upvotes: 2

Michael Slade
Michael Slade

Reputation: 13877

The fixed-pipeline functionality was deprecated because, essentially, it was fixed.

To support new tricks and such generally required new OpenGL functions, and it became clear that to continually support requested features would mean growing the size of the OpenGL API and making it progressively more and more unwieldy.

Meanwhile, hardware was becoming increasingly more sophistocated and powerful, and was not being fully exploited by OpenGL. Thus the programmable pipeline was conceived.

With OpenGL3 the Kronos group "deprecated" the fixed pipeline functionality. This caused a huge uproar as there was so much code and so much talent invested in the well-established fixed pipeline, so they partially backpedalled on their decision, introducing the "core" and "compatibility" profiles. The core profile encompasses the new programmable pipeline model, and the compatibility profile includes the core plus most/all of the fixed functionality, allowing applications to use either model.

We are up to OpenGL 4.2 now and the compatibility profile is still there, and shows no sign of disappearing.

In short, the reason for the deprecation is not because the old model was not suitable for application programmers; rather, it was a heavier burden for the implementors. The actual model is quite sound, and many applications/developers that use the programmable functionality find themselves re-impllementing the fundamental parts of the fixed functionality (glBegin, glEnd, matrix stacks, transformation calls etc).

So go ahead, implement your own matrix stacks. But, if you come up with an even better idea, please share it with us :)

Upvotes: 2

Andrew Rasmussen
Andrew Rasmussen

Reputation: 15099

I'm not super experienced in this specifically, but I've done a fair bit of graphics/game development. I have more of an idea than an answer. In my opinion, the glPushMatrix and glPopMatrix stuff is deprecated because many developers wanted full control of the transforms rather than OpenGL taking care of that for them. So my idea is that they aren't deprecated because a matrix stack isn't the way to go, but rather because GL developers are supposed to take care of the matrices themselves, or use another library to do that for them.

In other words, a matrix stack is still probably the way to go, you just have to do it yourself, use deprecated functionality, or use an external library.

Upvotes: 2

datenwolf
datenwolf

Reputation: 162164

(it was removed for some reason)

It was removed, because in modern 3D applications the whole OpenGL matrix manipulation functionality was highly redundant. Any modern 3D application needs to deal with matrices anyway, and since OpenGL is not a proper matrix math library you'd use something like Eigen oder GSL or something homebrewn anyway.

A stack is still a very viable structure.

Upvotes: 7

Related Questions