Seems well-organized, wish I had read that years ago - things I found out about rendering by trial and lots of errors are clearly stated there. It probably helped for comprehension that I struggled with these for years but now things make sense.

Approach is clearly a scene-graph but more involved than libgdx's 3D framework: lots of built-in techniques (e.g. for Shadows), implementations of frequently-used algorithms (BSPs, Octrees), etc.

Own binary model format with pre-computed LODs / edge lists, exporter available from Blender: blender2ogre (supports Blender up to 2.66)

They have scripts for everything (materials, compositor, particle, overlay, font definitions) so no need to rebuild just to change the aspect

Combined with a world editor, scripts mean we can pretty much build the whole graphical environment without rebuilding the game at all

The story engine shouldn't be too hard to implement in C++. Nor should the web server stuff, but I haven't scouted that yet.

Materials are pretty much texture/lighting definitions, made out of techniques, themselves made out of passes.

Compositor are for full-screen post-processing, particles are self-explanatory, overlays are for 2D UI on top of the 3D scene.

Platform: OSX 10.9 Mavericks, XCode 5, homebrew

At first I tried to build Ogre 1.8.1, following OSX+CMake command-line instructions. I grabbed the ogredeps package to try and get all the dependencies built before even attempting to build Ogre3D itself. At the time of this writing, they include:

• AMD_Quad_Buffer_SDK_v11
• Cg
• FreeImage
• NVAPI-R313-developer
• freetype
• ois
• zlib
• zziplib

Ogre has some kind of built-in archive system to load resources, freetype is used to load truetype fonts directly (compare/contrast with libgdx's Hiero that creates bitmap fonts out-of-engine), ois seems to be used for input devices, Cg is nVidia's shader toolkit, FreeImage is for texture loading.

ogredeps's CMakeFiles asks for a 10.6 framework, I used Frederic Devernay's Legacy package to extract + install it from old XCode dmgs.

The following command then seemed to generate makefiles:

cmake -G "Unix Makefiles" -DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk -DCMAKE_OSX_DEPLOYMENT_TARGET=10.6 ..

But the particular XCode version I used to extract the 10.6 SDK apparently creates bad symlinks. These commands seemed to have fixed it:

cd /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/Library
mv Frameworks OldFrameworks
mv OldFrameworks/* .
rmdir OldFrameworks

After that, same command works without any problems. Thank God for cmake legacy-problems-detection routines. Regular ol' make -j4 worked just fine.

make install installs include/ and lib/ in ogredeps/build/ogredeps - that path is useful for the ogre building phase.

Later on, I realized there were pre-built versions of the dependencies in the ogre-dependencies-mac sourceforge project. At this point I realized Ogre 1.8.1 was pretty old and I decided to try and build 1.9.0 instead.

I grabbed the version in 1.9/OgreDependencies_OSX_libc++_20130610.zip. It contains a folder 'Dependencies' which should just be put alongside ogre's sources.

I tried the cmake "Unix Makefiles" way too, but it wasn't worth it - too many troubles with OSX framework versions, sysroots, and what have you not. So instead, I had to go... the XCode way.

The easiest way to get the 1.9.0 sources was through Mercurial - it's hosted on Bitbucket (sinbad/ogre).

Used this command to clone directly to the v1-9-0 tag:

hg clone https://bitbucket.org/sinbad/ogre -r v1-9-0

After that:

cd ogre
mkdir build
cd build
cmake -G Xcode ..

No additional cmake flags required!

This generates an OGRE.xcodeproj folder in build/, it should be opened in XCode. (Note: in theory, xcodebuild is a valid alternative but some settings had to be messed with so it was just easier to do it from XCode).

Things I had to change in the OGRE project globally:

• OSX Target Version: 10.7 (was 10.5 by default, probably because it was the lowest SDK?)
• C++ Standard Library: libc++ (because ogredeps was built with it)

Full build time was probably between 5-10 minutes, hard to estimate.

XCode was built 'for my 64-bit Mac', I haven't checked if those are fat binaries or not.

The Ogre sample launcher is very nice, touch-enabled, there are 77 samples in 1.9.0, with all kinds of effects, from shaders to terrain, to compositors, to instancing, animations (including facial animations with weighting), dynamic textures, fresnel effect (water), etc. They seem to have a GUI system they use in the demos, it's kinda ugly but looks powerful enough, need to investigate.

The Cg samples didn't seem to run even though ogredeps contains Cg. Maybe Cg needs to be installed separately from the official nVidia website?

The Geometry shader things (particles, etc.) didn't work. The CPU-based particle system sample worked fine.

Platform: Windows 8.1 Pro, Visual Studio C++ 2010 Express, DX SDK, TortoiseHg, CMake GUI

Basically, the whole guide on techny tumblr is perfect even for 1.9.0. I used Visual Studio C++ 2010 Express edition, which I registered (it's free).

Windows notes:

• There is a DirectX 11 and a DirectX 9 backend in addition to the OpenGL backend
• HLSL2GLSL I suspect can be used to write portable shaders
• Installing the DirectX SDK bugged because VS2010 runtime was already installed - fix was to uninstall the VS2010 runtime, install the DX SDK and re-install the VS2010 runtime. (For shame, MS)

Sample launcher worked fine, but the DX11 backends had graphical UI glitches and the demos didn't display anything coherent. The DX9 backend worked fine. I didn't test the OpenGL backend.

The Geometry shader things (particles, etc.) didn't work on the DX9 backend - I suspect they're DX11-only. The CPU-based particle system sample worked fine.

Platform: Debian 3.14.2-1 (2014-04-28) x86_64, cmake command-line, mercurial commandline

Clone ogredeps and ogre, cmake generates Unix Makefiles, defaults worked well, building the samples requires XAW (wtf?) so installing libxaw-dev took care of that.

1st try: Launcher works, samples run, a few Cg errors are thrown, normal mapping sample doesn't seem to normal-map at all, changing materials does nothing, possibly because of missing Cg? investigating that.

Installed the .deb package the nvidia cg download page, rebuilding ogre.

I had only installed the 32-bit version, build failed with a link error, installing the x64 package now! Seems it unpacked 'over' the 32-bit version, so both can't be installed alongside. Will have to resort to chroots or VMs to build for both 32 and 64-bit Linux. Note that the deb package installed fine on Debian unstable so they're not Ubuntu-exclusive.

For the 64-bit package, libs were installed to /usr/lib64 and thus not picked up by cmake/make. Had to symlink them to /usr/lib for it to find it.

2nd try: With Cg support in, everything works fine, including the BSP demo and the normal mapping thing. Which only yields more questions because I thought during my OSX tests that Cg support was not there, yet it seemed to work fine? Weird.

I'm still in the process of evaluating Ogre3D for the purpose of a native platform for TSE's final version. My motivations are to get rid of Java, and the rationale is the following: Java is good and convenient for iterating quickly (no compilation times, everyone can run Eclipse, etc.) - but it's not so good for distribution itself (use exe4j? gcj is dead, Java on OSX & Linux are a mess, nobody likes Java runtime in general). Most of the 'intelligence' of the game resides in the editors (web-based) so making even a C++ version of the game shouldn't be too costly.

CMake is confusing at first, but it's very powerful and obviously a lot more than an autoconf replacement. It can generate Unix Makefiles (for Linux/SteamOS/etc.), XCode projects (first-class citizen on OSX), VisualStudio solutions (first-class citizen on Windows). Using it would be a clear departure from my habits (which are to take the road less travelled). It also means cross-compilation isn't an option in the short term, so no automated builds, and since the compilation environment setup process is rather complex, no hope for non-devs to build the game themselves. (However, Ogre3D scripts + in-house editors alleviate this problem).

The next steps would go along the lines of this:

• Get a CMake-based barebones project up on bitbucket where I can reliably iterate from on Windows or OSX and build on all three target platforms.
• Try to distribute the barebones project on all three platforms to get a feel of how the final release process is going to feel like
• Find out how to deal with YAML/JSON in a C++ environment
• Try to load existing 3D models into the barebones project
• Try a few compositors / mess around with shader techniques to see what kind of look we can achieve
• Implement the navigation engine inside the barebones project
• Implement the story engine inside the barebones project

None of these are solved yet, and they're not in any particular order, but things are looking okay.