Ogre 2 and Ogre 1 merge strategy

[altren]

I'm doing some fixes that can hit anyone using both ogre 1.x and 2.x and I see that some of them can be applied to the 2.x as well.
Also, I looked through the repository log and it seems that these branches have diverged a long time ago.
So my question is is there any plans to merge 1.x into 2.x? Should I do two pull requests, if they are good for both branches?

[altren]

@dark_sylinc, @paroj Any thoughts on this?

[paroj]

as you have noted the two branches diverged too far by now to be merged - this leaves

Should I do two pull requests, if they are good for both branches?

as the only option.

[Ybalrid]

as you have noted the two branches diverged too far by now to be merged

Ogre 2.x is definitively a hard fork.

IMHO this is something the community should think about: Something should be done to simplify the transition between 1.11 to 2.x, and only have 1.x being there for legacy support. I know 2.x has still some missing features (e.g. Morph animations on v2 Items), that it's basic setup is more complex (has to setup a compositor and rendering node, can't just tell a camera to render to a viewport without it), and that Android support is a problem due to the GLES 2/3 RenderSystems.

As of now, between 1.x and 2.x it's a bit like having 2 separated projects that inherit from the same code-base, not just a new development branch for 2.x... Heck, the main development of each actually happens in separated "upstream" repositories (a git one on github, and an hg one on bitbucket), they just happen to have their respective v1 and v2 branches synced from time to time.

[Zonder]

They have different major versions for a reason.....

Would you expect Microsoft to merge windows 10 and 7 together?

[altren]

No, but both Ogre branches are under development as separate projects, unlike windows 7/10 where only one is under active development and another is on support only.

[paroj]

IMHO this is something the community should think about: Something should be done to simplify the transition between 1.11 to 2.x, and only have 1.x being there for legacy support.

as this is something that regularly comes up (e.g. in the running user survey):
The difference between Ogre1 and Ogre2 is more than just the API and some features; it is also about development principles that is much harder to overcome.
E.g. in Ogre1 test-ability is a priority and a substantial amount of development time is dedicated to fix & extend the visual tests:
https://ogrecave.github.io/ogre/gl_stat ... 3Plus.html

Also keeping the API backwards compatible is the top priority Ogre1. New features come second. Therefore there is a separation between public and private API in Ogre1.

Still new features & performance improvements can be done as is obvious by comparing 1.9 to 1.11. With 1.12 there will be also integrated depth shadows via the RTSS.
Generally the RTSS concept was not exploited in Ogre1 at all so far. Most likely due to its bad implementation. Yet conceptually I think it is superior to the HLMS.

The bottom line is probably that there are more reasons to stick to Ogre1 than legacy support and your choice should not only be based on the version number.

A question that naturally falls out from the above is "why dont you just do it in Ogre2?" Well, where we currently stand this is equivalent to merging Ogre1 and Ogre2

[Ybalrid]

IMHO this is something the community should think about: Something should be done to simplify the transition between 1.11 to 2.x, and only have 1.x being there for legacy support.

as this is something that regularly comes up (e.g. in the running user survey):
The difference between Ogre1 and Ogre2 is more than just the API and some features; it is also about development principles that is much harder to overcome.
E.g. in Ogre1 test-ability is a priority and a substantial amount of development time is dedicated to fix & extend the visual tests:
https://ogrecave.github.io/ogre/gl_stat ... 3Plus.html

Also keeping the API backwards compatible is the top priority Ogre1. New features come second. Therefore there is a separation between public and private API in Ogre1.

Still new features & performance improvements can be done as is obvious by comparing 1.9 to 1.11. With 1.12 there will be also integrated depth shadows via the RTSS.
Generally the RTSS concept was not exploited in Ogre1 at all so far. Most likely due to its bad implementation. Yet conceptually I think it is superior to the HLMS.

I agree on the fact that, and especially with your work, substantial improvement to Ogre1 have been made since the 1.9 days, and I also understand that one of it's main goals.

I haven't delved into RTSS (and what you did to bring it up to snuff), for me it seemed stuck in "hey, we're gonna spit out shader that will simulate what the fixed function pipeline used to do like... 10 years ago".

The bottom line is probably that there are more reasons to stick to Ogre1 than legacy support and your choice should not only be based on the version number.

A question that naturally falls out from the above is "why dont you just do it in Ogre2?" Well, where we currently stand this is equivalent to merging Ogre1 and Ogre2

Yes, and I can imagine that this version number thing is a bit more confusing than it should. It should be clearly stated that these 2 version of Ogre are now 2 separated project, developed in parallel, and they receive different features and improvement. A bit like what happened with Python 2 and 3...

That's just an idea, but this could probably be explained better on this page of the website : https://www.ogre3d.org/about/what-version-to-choose