Understanding the gimbal lock

After reading the gimbal lock sections in several books and watching a few videos, what really made it clear to me was this explanation at gamedev.net by Atash:

think about having two sets of coordinate axis. One set can be considered 'local', as in local to the orientation of what you're rotating. The other set can be considered 'global', as in, the world's natural axis (just for a moment, think of it that way. The world is flat right now >_<)

Now, when you have those two sets of axis, imagine that they are standing up aligned, perfectly without an issue. If you take the local axis, and rotate it around 90 or -90 degrees around it's local y-axis, you'll find now that the x-axis is aligned perfectly with the z-axis. Now, the problem is now that if I continued to rotate the object by euler angles (rotating around the global axis) while the local x-axis are aligned with the z-axis, then when I rotate around the global z-axis, I am in fact rotating around the local x-axis, thus having no influence on which way the local x-axis is pointing! (remember that when you rotate around a certain axis, that axis doesn't move. The contra of that statement is true as well.) Okay, now we have a problem... One of our rotational axis has gone caput! Gimbal Lock has totally screwed us over.

It all makes sense now!

C++ std::min/std::max compilation issues

I just came across this issue today: http://support.microsoft.com/kb/143208

Basically, if you have code like this:

#include "windows.h"

...

int minimum = std::min(a,b);

it's going to blow up in your face.

Notice this at the bottom of that page: "This behavior is by design" . Seriously???

I solved the issue using extra parenthesis to prevent macro expansion thanks to stackoverflow:

int minimum = (std::min)(a,b);

And by the way... "windows.h" redefines lots of other stuff, beware! e.g. try to define the function DeleteFile and see what happens!