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.
The ogredeps package includes:
- 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.
Platform: OSX 10.9 Mavericks, XCode 5, homebrew
There are pre-built versions of the dependencies in the ogre-dependencies-mac sourceforge project.
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).