Hi!
I'll try to answer your answers. Please read the
Ogre 2.0 slides to know more about the state of the art of Ogre 1.9 and how far you can push it (these slides were written as a proposal, i.e. Ogre 2.0 had not been written at that time).
This is my main concern. Currently, a very small scene with 20K triangles, a few 2k maps, 15 lights and physics, SSAO, AA etc runs at only ~50fps in full HD. This computer was used to build a Unreal 3 game, with scenes going up to 500K triangles, with handcoded shaders ; it was running smoothly.
Games like Crysis 3 (which outputs, litteraly, millions of triangles with animated vegetation) also run smoothly.
Obviously something is very wrong. Even if deferred shading scales very well, the performance looks off by a factor of ten. I am very aware that my implementation is probably the culprit, but I have heard rumors of bad performance in Ogre 1.x, so I would love some inputs from people who push the engine a bit.
All you mentioned (triangle count, texture resolution, number of lights, SSAO, AO, screen resolution) depends on your video card and to a lesser extent, the cpu. So if THAT's the culprit, it's your own fault (shaders, inefficient passes, etc)
That being said, where Ogre is most likely at fault is in the Entity count and the number of Compositor passes. As you may see from the slides, Ogre 1.9 is very stupid when performing compositor passes, thus traverse a lot of the scene graph unnecessarily.
The other thing that hurts directly is the number of Entities. Regardless of how many triangles you have, the more Entities you create, the much slower it gets.
Ogre 2.0 solves the Compositor inefficiencies (note the script syntax changed a little, but it is easy to port) and scales very, very well with high number of Entities. It is however advised that you use Instancing (see NewInstancing example) whenever possible (this applies to both 1.9 and 2.0).
Improvements like 3x or 5x are common when porting from 1.9 to 2.0 unless you had too many texture and shader switches.
There are still big inefficiencies we need to address (like the RenderSystem API management and the RenderQueue) though if you use instancing these will affect you very little; and these won't be improved in Ogre 2.0; but probably in 2.1 or 2.2
As for the particular case Crysis comparision, beware that on the GPU side they use extremely optimized algorithms: They work with framebuffers in YUV space to halve the bandwidth usage, pack their vertex data using a technique called QTangents, compress normal map's GBuffers into just 24-bit using an algorithm they called "Best Fit normals", etc.
Though these techniques are up to you to implement, we're trying to ease some of them (i.e. try to support QTangent generation natively in the exporter) but it will be a long time until we reach then. Right now we've got various elephants in the room.
They also use D3D11 which allows for some optimizations currently not possible due to Ogre's highly compatible RS (D3D9, D3D11, GL, GL3.0; GL ES, etc)
Beware though, we're still working on Animations, and if you've got too many skeletal animations, Ogre 2.0 may perform worse than 1.9 did.
Gwenn_ wrote:
2. API, compositors, overlays
I love the compositor system. I use it for everything.
I understand that it is one of the Ogre components that is being rewritten in Ogre2 (actually I can't build my Ogre2 branch, with OgreCompositorLogic.h misisng). Is there any kind of up-to-date sample, generated documentation or help to try out the new Ogre ?
The compositor has been rewritten, but the script syntax is almost the same; if you were using scripts, porting is very easy. If you used to heavily control the Compo from C++, then the code changes could be massive.
There is no working example of the new Compositor yet and that's my fault. After I'm done with animations, I will focus on these samples.
Gwenn_ wrote:
What about overlays ? Not that I plan on keeping them for long, but are they gone from Ogre (can't find the headers either) ?
They're still on Ogre 2.0 (look in the Components folder). AFAIK we don't have any plans for them (to remove, improve, nor anything)
Gwenn_ wrote:
3. Shaders and RTSS
Okay, so I'm pretty much a low-level guy (C++ looks actually very high-level and abstract in my current line of work) and I love writing shaders. Please don't shoot me.
I see RTSS everywhere in forum threads, I understand what it's used for but I have no interest in it, since most of my scenes are made from very, very similar materials (diffuse/spec/normal map with a metallic look) and use mostly one shader with 4/5 parameters.
Will Ogre2 force RTSS or similar concepts onto the user ?
We don't plan to force high level shaders on users. For many users writing their own shaders is tricky, and no system currently offers something easy for them (that includes RTSS, hence a hot topic).
Additioanlly, RTSS is currently the best way to deal with mobile; because these mobile platforms don't support fixed function pipelines; and writing a shader for each trivial thing like showing up an overlay with alpha blending is a PITA even for us low level coders (this also includes D3D11).
Gwenn_ wrote:
4. Windows build
Okay, not everyone is perfect, I work with Windows.
I got the last revision of the 2.0 branch built, at least for OgreMain, the OpenGL plugin and a few other things. Some others (Terrain, OpenGL3, etc) won't build, the install target also won't (I had to copy headers by hand, that was fun).
That's ok. Some samples and components are very low priority and hence not being giving attention; besides I'm the main guy behind 2.0; and there are a few components I've never even looked at; like the Terrain component. Eventually they'll get fixed I guess.
Sometimes, some RS (like OpenGL3) stop working because I don't use them too often and get out of sync, but that's only temporary and get fixed easily afterwards. Perhaps GL3 not the best example because it is a big exception: have been major developments on another branch (it was a parallel GSoC project) and I want to wait until I merge those change into 2.0 before I keep touching GL3.
Gwenn_ wrote:
The question here is not "y u no work ??". Of course it doesn't, it's a work in progress. The question is : when will Ogre2 be considered usable for development ? Like in beta or RC state ?
I personally use it, and some few people already started using it. But beware it comes with a "use at own risk" moniker attached. I would say it's somewhere between alpha and beta. Don't be surprised if your scene suddenly glitches, or it has got memory leaks.
For example, yesterday I happen to fix a nasty memory corruption problem that was going unnoticed.
The current version is actually very stable, and we would love to hear early developer feedback.
