[Announcement] Ogre 2.0 RC1 has just been tagged!

[spacegaier]

Good news! We’ve officially added the v2-0-0RC1 tag (commit) indicating that we reached our first Release Candidate 1 milestone for Ogre 2.0.

Our original plan was to tag this release as “CTP” (Community Technology Preview) and the upcoming AZDO (Approaching Zero Driver Overhead) improvements as “final”. However this proved to be very confusing for the community and in fact presented two practical concerns:

1. v2-0-0RC1 is actually very stable and relatively easy to port to when coming from Ogre 1.9 or Ogre 1.10 (= current unstable default branch). The external API interface is quite similar, with performance benefits from efficient frustum culling and scene graph management (plus it’s multi-threaded). Several users in the community had already started porting to it.
2. The AZDO branch was going to be labelled as “final”. Even though being quite impressive feature- and performance-wise, it is not complete, cannot be considered stable, and is far from actually being final. Furthermore, porting from 1.9 or even from 2.0-RC1 to the AZDO branch is not a trivial task as the external API changes are considerable.

Therefore we concluded that:

1. The “CTP” branch will be released as Ogre 2.0 and is a good stepping stone for projects that require better performance without the high risk associated with porting when there are big engine changes.
2. The “AZDO” branch will be released as Ogre 2.1 at some point in the future. External interface changes are quite significant and porting to this version requires more work and inherently results in more risk.

[...]

Full blog post with more details about the branches: http://www.ogre3d.org/2015/02/06/ogre-2 ... nouncement

[jacmoe]

If major means interface breaking changes, then the AZDO Ogre should be named Ogre 3.0, am I right?
Good work, guys!

[spacegaier]

If major means interface breaking changes, then the AZDO Ogre should be named Ogre 3.0, am I right?
Good work, guys!

Believe it or not, but that was actually in the discussion. But having this lonely 2.0 version without any sibling just felt wrong .

[madmarx]

I was wondering the same .
It's a relief to have these news. Congrats to everyone!

[lingfors]

Doesn't compile for OGRE_CONFIG_DOUBLE...

Edit: With SIMD enabled.

[al2950]

Doesn't compile for OGRE_CONFIG_DOUBLE...

Edit: With SIMD enabled.

Just tried myself. Missing "SSE2/Double/OgreArrayMatrix4.h" header! I did not think there was much point trying to use SSE2 with doubles?

[lingfors]

Doesn't compile for OGRE_CONFIG_DOUBLE...

Edit: With SIMD enabled.

Just tried myself. Missing "SSE2/Double/OgreArrayMatrix4.h" header! I did not think there was much point trying to use SSE2 with doubles?

From OgreArrayMatrix4.h:

Code: Select all

#if OGRE_CPU == OGRE_CPU_X86 && OGRE_USE_SIMD == 1
    #if OGRE_DOUBLE_PRECISION == 1
        #include "SSE2/Double/OgreArrayMatrix4.h"
    #else
        #include "SSE2/Single/OgreArrayMatrix4.h"
    #endif
#elif OGRE_CPU == OGRE_CPU_ARM && OGRE_USE_SIMD == 1
    #if OGRE_DOUBLE_PRECISION == 1
        #error Double precision with SIMD on ARM is not supported
    #else
        #include "NEON/Single/OgreArrayMatrix4.h"
    #endif
#else
    #include "C/OgreArrayMatrix4.h"
#endif

So somebody at least thought about it...

[dark_sylinc]

Doesn't compile for OGRE_CONFIG_DOUBLE...

Edit: With SIMD enabled.

Just tried myself. Missing "SSE2/Double/OgreArrayMatrix4.h" header! I did not think there was much point trying to use SSE2 with doubles?

So somebody at least thought about it...

Indeed. If you want double support you'll have to disable OGRE_SIMD_SSE2 and OGRE_SIMD_NEON until someone makes the implementation (no ETA; keep in mind it's low priority).

Cheers.

[frostbyte]

Doesn't compile for OGRE_CONFIG_DOUBLE...

why be sad? are you running a nuke simulation or sending a spaceship to other galaxies using ogre api?

regarding azdo branch...
sorry for dubm question, but does GL3+ means GL3 and what follows?
so according to this http://store.steampowered.com/hwsurvey/videocard/ i should be able to target 96% users, is that correct?

[dark_sylinc]

It means gl 3.3 minimum plus a couple extensions. In theory that's the 97% you speak about (d3d 10 hw).
However Intel seems to have abandoned driver support for Intel 3000 and below (except HD 2500) and thus are unable to run the azdo gl3+
The only hope for those cards is that mesa's gl implementation for linux catches up.

Additionally OS X lacks key basic features and therefore ATM it is not supported. We'll expand a bit on this in an upcoming news announcement.

[frostbyte]

We'll expand a bit on this in an upcoming news announcement.

thanks, would be nice if you do...
its all very confusing, since i don't know if i should move development to 2.0...
or perhaps just keep 1.x for most cases and use 2.0 where/when available...
i guess that lots of ogre users share the same doubts...indepth clarification is indeed neccessery....

The only hope for those cards is that mesa's gl implementation for linux catches up.

there is always the gles+angle option...right?

[oln]

So, it will not be possible to use Ogre 2.1 with Dx9/OpenGL 2.x hardware at all?

[c6burns]

So, it will not be possible to use Ogre 2.1 with Dx9/OpenGL 2.x hardware at all?

Yes, 2.1 will not work with those. Are you planning on doing some next-level stuff on the oldest deployed hardware? 1.10 is fine for that stuff, I am using it for just that purpose.

[frostbyte]

yep, it seem that 1.10 is for older hardware, 2.0 is for easy transition from 1.x, and 2.1 is bleeding-edge...
anyway precentage of gl2 capable hardware is very low...and getting lower as we speak...
by the time you finish doing what you want to do with 2.1 it will be next to zero...
you can read hardware and other statistics on unity and steam websites...

anyway i think( not sure ) you'll be able to reach this hardware using glES+angle project, but the question is why even bother?