which version I should choose?

[Kinfoin]

hellow everyone.
i have a projection which is developed on Ogre1.8.
now,I want to update my projection to support GL3+,but i don't know which version of ogre i should choose.
i had try in Ogre1.9.but after a few day's work,i found it is (EXPERIMENTAL)....
can anybody tell me,which version i should choose?
thanks.

[Wolfmanfx]

Hi,

Sure check this out http://www.ogre3d.org/about/what-version-to-choose

[Kinfoin]

thanks Wolfmanfx ,i had read it very carefully,but i want to make sure which one is support GL3+ perfectly.
i had wasted too much time to Porting to 1.9.

[Wolfmanfx]

GL3+ works in 1.10 (with some small bugs for sure) and it works on 2.1 (GL3+ was the first RS supported all badass features like AZDO).

[Kinfoin]

GL3+ works in 1.10 (with some small bugs for sure) and it works on 2.1 (GL3+ was the first RS supported all badass features like AZDO).

thak you !
now i need consider carefully to choose which one,it's lots change from Ogre1.x to Ogre2.1,if i choose Ogre2.1,it means i need to rewrote my projection in a very short time,this is realy make me feel bad

[paroj]

you can see the status of GL3Plus in 1.10 here.

This roughly reflects the default branch on bitbucket - on github I have some fixes that make more tests pass.

Still most notably everything stencil related is broken with GL3Plus.

[scrawl]

you can see the status of GL3Plus in 1.10 here.

Some of these look very close, only the lighting is ever so slightly different, resulting in the test to fail.

I wonder, does the RTTS perform light clamping? You'll need to do something like

Code: Select all

lighting = clamp(lighting, 0.0, 1.0);

for compatibility with the fixed function pipeline.

Alternatively, the light settings for the tests could be modified so that the maximum amount of lighting would never exceed (1,1,1).

[Wolfmanfx]

It's hard to compare FF images to shader based ones.

[TheOnlyJoey]

I personally do not agree with the list on the website.

We have done some back and fourth testing with 1.10 and 2.0 (using GL2.1 and GL3.3 renderer) and have found that in most cases, there is no notable performance difference.
Also in combination with 2.0 being not complete for actual product development (since it lacks and breaks quite a bit).

I also thinks 2.1 still needs a big warning, it is still in constant development and after a couple of breaking updates in the past, we found it not suitable for current day to day development yet.
Though I really like the progress in 2.1 and that people are experimenting with it, as I do myself, suggesting this to developers working on a serious project is not recommended due to documentation, breaking things and support.
I recommend using a big "Warning, experimental" in all red for 2.1 on the website, so there is no false expectation of the stability in it's current state.

Support is a big issue as well, on IRC almost all users are on 1.10 or older and we get daily support questions, mostly from people who need the wiki documentation or do projects on a time deadline, our fist rule is: Use 1.10.

The website also states HLMS is not available for 1.10, which is wrong.

[xrgo]

We have done some back and fourth testing with 1.10 and 2.0 (using GL2.1 and GL3.3 renderer) and have found that in most cases, there is no notable performance difference

between 1.10 and 2.0 there should be performance increase when you have many many objects. And I don't think GL3+ is better than GL2 in those branches... GL3+ got a lot of love in 2.1 and it has AZDO in its core, so when we jump from 1.9 (GL2) to 2.1 (GL3+) the performance boost was incredible

I also thinks 2.1 still needs a big warning, it is still in constant development and after a couple of breaking updates in the past, we found it not suitable for current day to day development yet.

That's not true, we are using it for commercial products with very success. The only breaking update that I remember was a mesh format change when dark_sylinc introduced the new shadows optimization a few months ago (and he made a sticky in the forums to warn us all), that took us 10 mins to integrate it in our code. Most of the development is more features and bug fixes. I can say its stable enough (in breaking updates) and superduper stable (in crashes and bugs)

about documentation on 2.1 I agree, but if you have experience in 1.X ogre, its not that hard to make the jump. I was using 1.9, then changed to 2.0 for like 3 days and 2.1 came out and started using in that moment (so basically I skipped 2.0) and I got my engine running with 2.1 in just a few days

go 2.1! lol

[paroj]

I wonder, does the RTTS perform light clamping? You'll need to do something like

very good catch. It indeed does not do clamping. This following commit further minimizes the GL3-GL difference:
https://github.com/OGRECave/ogre/commit ... 466c2429a9

Next I have to figure out whether this is the right way to fix it or whether I should use the RTSS to generate the clamp instruction when appropriate.

[paroj]

here are the results of the up to date git version with the above fix applied:
https://ogrecave.github.io/ogre/gl_stat ... 3Plus.html

[Fedakl]

Hi,

My question is : ogre1.10 GL3+ status on OSX same as this topic conclusion or not?

with regard to the following ogre 2.1 info on OSX :

Hi,

Ogre 2.1 does not currently work on OS X due to it having an extremely outdated (and buggy) version of OpenGL and lacking the necessary extensions. It might work using the proprietary NVIDIA drivers though.

We're working on a Metal port for El Capitan, but no ETA.

I have some error on osx gl3+ however on windows gl3+ or osx gl (glsl120) not :

GLSL program pipeline validation result:
Validation Failed: Sampler error:
Samplers of different types use the same texture image unit.
- or -
A sampler's texture unit is out of range (greater than max allowed or negative).

thx

[Fedakl]

Sry this is not true:

I have some error on osx gl3+ however on windows gl3+ or osx gl (glsl120) not :

Osx with gl same error as osx with gl3+, but not this error is the essence.

The essence is i want to know the next : gl3+ osx status same as windows linux ... or worse.

(maybe development forums is not my place ?, i noticed this after submit the question... )

thx...

[TheOnlyJoey]

We have done some back and fourth testing with 1.10 and 2.0 (using GL2.1 and GL3.3 renderer) and have found that in most cases, there is no notable performance difference

between 1.10 and 2.0 there should be performance increase when you have many many objects. And I don't think GL3+ is better than GL2 in those branches... GL3+ got a lot of love in 2.1 and it has AZDO in its core, so when we jump from 1.9 (GL2) to 2.1 (GL3+) the performance boost was incredible

I also thinks 2.1 still needs a big warning, it is still in constant development and after a couple of breaking updates in the past, we found it not suitable for current day to day development yet.

That's not true, we are using it for commercial products with very success. The only breaking update that I remember was a mesh format change when dark_sylinc introduced the new shadows optimization a few months ago (and he made a sticky in the forums to warn us all), that took us 10 mins to integrate it in our code. Most of the development is more features and bug fixes. I can say its stable enough (in breaking updates) and superduper stable (in crashes and bugsl

This is not true, at all, currently most samples are broken (PBS among others are broken) (Gl3.3 on Linux) and there are huge performance drops (current Forward3D runs about 100/150FPS lower then 2 month's before).
I am sure this will get fixed soon (as it always will), but these kind of regressions is what makes the 2.1 still highly experimental and not suitable for use in a commercial product, unless you are willing to keep with certain versions and patch everything up until the next 'more stable version' is out.

I would love to port over to 2.1 and endorse doing so, since I love the development that is going on and would love to see Ogre in the new generation of graphic engines, but currently I can only recommend people staying at 1.10 for the moment.

[xrgo]

This is not true, at all, currently most samples are broken (PBS among others are broken) (Gl3.3 on Linux)

I don't test the samples so often but last time I checked (2 weeks ago?) they where all working fine on linux, sad to read that are broken, its one of the most important things!

and there are huge performance drops (current Forward3D runs about 100/150FPS lower then 2 month's before).

Again, can't confirm or deny this because my previous statement about the samples. But in my app/engine everything is working great since ever, I update Ogre every few weeks/days and I have never noticed performance drop when I update.

Can I encourage you to report this kind of things (broken samples, performance drop, etc) when you notice them? so they can get fixed =)!

[dark_sylinc]

This is not true, at all, currently most samples are broken (PBS among others are broken) (Gl3.3 on Linux) and there are huge performance drops (current Forward3D runs about 100/150FPS lower then 2 month's before).

I'd like to see this being reported... none of the samples are broken at the moment (both Windows and Linux).

It is possible sometimes they break because of one bad commit which gets fixed within the next day or two.
But if you see a broken sample please report it on the 2.0+ forums.

there are huge performance drops (current Forward3D runs about 100/150FPS lower then 2 month's before).

I haven't noticed noticeable performance drops. However comparing in FPS is useless as FPS is non-linear. i.e. dropping from 450 to 350 FPS is not huge (it's just 0.63 ms; if it had been running at 60FPS, it would drop to 57.81 FPS) and the Forward3D sample is heavily dependent on screen resolution.

We did make a feature upgrade in the Forward3D in the last few weeks to make it much more manageable and aesthetically pleasing. It can be turned off. Something like that might explain a 0.5ms drop.

Another problem is that measuring on Linux is tricky because of:

• The X Compositor (there's HUGE variations caused by this. You have to be running on LXDE or similar no-compositor desktop environments to get maximum perf.)
• A bug in the linux kernel causing really poor power mode state switching which was fixed in Kernel 3.16 (but Ubuntu 14.04 ships with 3.13)

I have literally variations of around a 100 of FPS between subsequent runs of the same sample on Ubuntu 14.04 (when running at high FPS such as >200 FPS).