One of the projects which I had been working on, while my Hewlett-Packard laptop was running Windows 8.1 and named ‘Maverick’, was to compile “OGRE 1.10″ on it to the best of my ability. And one mistake which I was adhering to, was to insist on using the ‘MinGW’ compiler suite. OGRE developers had already tried to convince me to use the MS compiler, since that was a Windows computer, but I did not comply. This was particularly pedantic of me, since by now a free version of Visual Studio is available, that can compile OGRE.
So now that the H/W has Linux installed on it, I recommenced compiling OGRE, with native compilers and tools. But the results were not exactly spectacular.
One reason for the lackluster results is, the fact that ‘Klystron’ currently has ‘Mesa’ drivers loaded for its Radeon graphics card, instead of having the proprietary, binary ‘fglrx’ driver. Mesa will give it OpenGL 3.3 tops, while ‘fglrx’ would have given it OpenGL 4.5. And the latest OGRE samples include samples with Geometry Shaders, other OpenGL 3 features, and even some Tessellators, which would be OpenGL 4 features.
Apparently, when one pushes any Mesa Drivers to their limits, these will bug out and even cause the X-server to freeze. Thus, when I switched from testing the OGRE OpenGL 2 rendering engine, to its OpenGL 3+ rendering engine, I ran in to an X-server freeze.
This did not force me to hard boot, because often, during an X-server lockup, I can <Ctrl>+<Alt>+F1 to a console window, from there do a user and a root login, and then issue an ‘
init 6‘ command, which will usually do a controlled reboot, in which all file systems are unmounted correctly before the restart.
There is one detail to what the Mesa Driver does, which I like a whole lot.They allow for shader code written in the language Cg to run, even though Cg is a legacy toolkit developed by nVidia, for use on nVidia graphics cards and not on Radeon.
The fact that the Mesa Drivers allow me to do that, differently from the limitations which were only imposed on me under Windows 8.1, means that with OGRE 1.10, the Terrain System finally works 100%. OGRE 1.10 uses GPU-generated terrain, whereas most graphics engines rely entirely on their CPU, to create terrain. The earlier inability to get terrain to work with this system, was more crippling than anything else.
But as long as I am not using the ‘fglrx’ drivers, all attempts to get OpenGL 3 features to work with OGRE utterly fail, including any hope of ISO surfaces, which rely on Geometry Shaders, and any hope of GS-based particles. My particles will be limited to Point Sprites then.
What one does in a situation such as this, is not just to throw out OGRE 1.10, but rather, to disable modules. And so I disabled the GL3+ rendering engine, as well as one ‘HLMS Sample’, and am now able to get many of the samples to run, including, importantly, the Terrain Samples.
Also, there remains an advantage to using Mesa Drivers, which was pointed out to me already on the Kanotix site. The Mesa Drivers allow hardware-acceleration of high-bandwidth, 2D video streams, via ‘vdpau’, while if I was to use ‘fglrx’, the decoding of MP4 Videos would be limited to CPU decoding, which is in itself lame, if we ever wanted to watch serious video streams. And since that laptop has a screen resolution of 1600×900, wanting to watch videos on it eventually, remains a very realistic prospect.
(Edit : ) I suppose that one question which I should be asking myself, about why perhaps, the OGRE 1.10 GL3+ Rendering Engine does not work, would be whether this could be due to some incompatibility with the GL3.1 Desktop Compositing which I am already running on the same machine. There have been past cases, where OpenGL 2 from an application did not agree with OpenGL 2 Desktop Compositing, but those cases have generally been solved by the developers of the desktop managers.
On ‘Klystron’, I have rich desktop effects running, that use GL 3.1. So it does not seem obvious, that the Mesa Drivers as such, have problems implementing GL 3.
Also, there is a follow-up thought, as to why maybe, Cg was not working before. Whether or not our graphics cards support Cg, it is a necessary component of OGRE, to build their Cg Program Manager. Under Windows 8.1, I was always unsure of how to provide the OGRE Dependencies when building OGRE. But among those dependencies I always linked in a file named ‘
Cg.dll‘, the origin of which was unknown to me.
It is exactly the sort of goofy mistake I would make, perhaps to have taken this DLL File from the install folders of Cg on ‘Maverick’, but for some reason simply to have taken a 64-bit DLL, into my 32-bit OGRE build, or to have taken a DLL from somewhere, which may not have been compatible for some other reason.
At least when we install dependencies under Linux from the package manager, such issues as linkage of code and location of folders, are also taken care of by the package manager. So I am sure that the Cg Program Manager belonging to OGRE, recognized the nVidia Cg packages when compiling now. It is just a bit odd that those were native Cg libraries with header files, while my graphics drivers remain the Mesa Drivers.