1.9 to 2.0+

[mageonline]

Hey Team,

Now that I have have upgraded from 1.8 to 1.9, i was wondering if i should stop here?
Is there any stable 2.x RC you could recommend for testing?

How much API changes should i expect after 1.9?

Any target day for binary SDK release? I still use VS. 2010, will it be supported? I like the SDK releases as the Virus Applications won't report false detection on widely used dlls.

[Crystal Hammer]

I think you could call 2.0 stable.
See this topic:
http://www.ogre3d.org/forums/viewtopic.php?f=25&t=83128
IIRC has reworked compositor with workspace.
Details are in porting manual in docs/2.0
https://bitbucket.org/sinbad/ogre/src/d ... /Docs/2.0/
or in 2.1
https://bitbucket.org/sinbad/ogre/src/b ... /Docs/2.0/

[Jayray]

Hi,

In my project I have upgraded from Ogre 1.8 to Ogre 2.0, then to Ogre 2.1.
On my point of view, upgrading to 2.0 is quite simple because there are no major API changes expect for the compositor, but I do not feel like there is much gain to upgrade from 1.9 to 2.0.

2.1, however, is... fabulous
The performance gain is huge, especially if you did not use instancing in Ogre 1.x, which is my case (I had planned to do it but never took the time for it).
The HLMS component is also amazing, it gives great shaders - better than the ones I had done by myself - with almost no development effort, and it keeps getting improved over time

But the downsides of Ogre 2.1 are :
- An important porting cost from Ogre 1.x / 2.0 (many major API changes)
- Still under development => not all functionalities are present and there might be some bugs
- Artistic adjustments may be needed if you want to use HLMS

Despite these downsides, I recommend trying Ogre 2.1 if you have the opportunity to spend some time porting your code.
For my needs, Ogre 2.1 is great, and there are just a couple of things missing to be used in a stable release of my project (MSAA and DDS cubemap loading in D3D11, transparency in PBS HLMS).

Also, Ogre 2.1 works well with VS2010.

[TheOnlyJoey]

I would personally say stay on the more stable 1.10 branch (current trunk).

1.10 also gained HLMS and has a lot more stability and well documented (and not a drastic changing) API.

Moving towards 2.1 might be a better idea when the spec is set and a beta/rc is announced.
If updating your sources using a constant moving API is not a problem for you, you could use 2.1 as a early adopter, but if you want JustWorksTM, stay on 'mainline'.

[flavio]

Hi folks,

I have the same question, but with few extra constraints.
At IRCAD(http://www.ircad.fr), we are about to release an Ogre backend of our framework, FW4SPL (https://github.com/fw4spl-org).

We have worked with the branch 1.9 so far, using the standard OpenGL RenderSystem, on Linux, Windows and OsX. It is ok on Linux on Windows, but on OsX we don't manage to get something decent with this RenderSystem as it is limited, as far as I know, to OpenGL 2.1. However G3Plus doesn't seem to be stable enough on this branch and on other platforms, lots of feature do not work, or crash. Which is sad because we could get more fancy features by the way.

So considering this, especially for the OsX support, what would be the best solution for us ? Moving to 1.10 ? Port to 2.0 ? Or wait until a new stable release ? Will there be really a 1.10 release or only 2.0 ? I insist on stability because our framework is used daily by researchers, so we can't use something that is less stable than 1.9.

Thanks !

[dark_sylinc]

Hi!

The improvements from 1.9 to 2.0 were merely in terms of performance. The RenderSystems in terms of stability and quality are in similar state between 1.10 and 2.0 since the branches are merged regularly. There are no changes in the state of GL3Plus.
Unless you're severely bounded in terms of CPU performance by frustum culling or the amount of objects and nodes in the scene, moving to 1.10 would be wiser than moving to 2.0

In Ogre 2.1 the GL3+ & D3D11 RenderSystem were completely revamped to a whole new level. Performance & stability greatly improved. However:

• Ogre 2.1 uses bleeding edge D3D11 & OpenGL. In your particular case (sensitive medical application where stability comes first) this is often a bad idea. Your customers would have to run on modern GPUs with the latest drivers. We've been having multiple reports of crashes, or even entire system hangs due to old GPUs or outdated drivers, particularly on Linux. If you're willing to make an installer that checks if it's running on an up to date driver then it won't be an issue (and provide support to your customers to update their drivers).
• OS X is not supported for the same reason. Its OpenGL implementation is too old and too basic (and too buggy). We're working on a Metal port though (no ETAs, we don't know when it will be ready) and even then, El Capitan isn't out yet.

Technically any D3D10-capable hardware is supported, but due to the historically poor quality of OpenGL drivers, these older cards no longer receiver driver updates and hence can only run well on D3D11 RenderSystem under the Level 10 compatibility mode. Running a good experience on Linux often means a D3D11-capable card (GeForce 400+, Radeon HD 5000+, Intel HD 4000+) with latest drivers.

[flavio]

Thanks for your answer, we followed your advice for now and switched to 1.10. A small effort was needed to get our code compatible.

We are currently working to make everything working with GL3Plus instead as classical GL seemed too limited on OsX. We are almost done, at least on Linux, except a problem on multiple windows (I created a specific thread for this).