Ugly Irrlicht class templates

With a sigh of relief, I have completed implementation of the last of the float/int irr.core class templates, triangle3d<T>. Most of these types, including but not limited to triangle3d, have very significant problems when T is an integer type. A number of member functions actually generate compiler errors, usually due to ambiguous overloads of stdlib math functions like fabs(); they're overloaded on float types, so when an int type comes along all the overloads are equally attractive, and the compiler is forced to ask for clarification. Considerably more member functions generate ugly conversion warnings; converting a signed int either to or from a float generates a warning, and often ill-considered typecasts littered throughout the Irrlicht code makes the problem even worse. Many member methods, like the intersection tests or normalization, really can't sensibly work with integer instantiations at all. I generally had those either return float types or raise exceptions. Lastly, a number of methods generate bogus results, even if they compile cleanly. For example, there are a number of places where you see code doing a divide by 2 like so: x = y * (T)0.5; Of course, if T happens to be int, 0.5 immediately truncates down to zero, and so the expression will always return zero. Those had to be completely reimplemented inside Pyrrlicht.

Since I don't want to maintain a custom version of Irrlicht, I've made workarounds for all these problems without touching the Irrlicht source. This ended up making the wrapper code for these types significantly messier than it ought to have been. For the triangle3d types, as an example, I had to hand-code fully half of the member functions due to various issues with the Irrlicht codebase. I wouldn't have done it, except for the existence of explicit typedefs for irr::s32 versions of most of these class templates like irr::core::triangle3di. It's pretty clear, though, that if Niko has ever used the int versions at all, its been only very superficially.

So, the moral of this story is, if you have a choice you probably shouldn't try to use most of the irr::core class templates with integer types. It's ugly.