Ogre 2 and Ogre 1 merge strategy

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
User avatar
altren
Gnome
Posts: 334
Joined: Tue Oct 24, 2006 9:02 am
Location: Moscow, Russa
x 26

Ogre 2 and Ogre 1 merge strategy

Post by 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?
Image
User avatar
altren
Gnome
Posts: 334
Joined: Tue Oct 24, 2006 9:02 am
Location: Moscow, Russa
x 26

Re: Ogre 2 and Ogre 1 merge strategy

Post by altren »

@dark_sylinc, @paroj Any thoughts on this?
Image
paroj
OGRE Team Member
OGRE Team Member
Posts: 2106
Joined: Sun Mar 30, 2014 2:51 pm
x 1132

Re: Ogre 2 and Ogre 1 merge strategy

Post by 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.
User avatar
Ybalrid
Halfling
Posts: 89
Joined: Thu Jul 10, 2014 6:52 pm
Location: France
x 31

Re: Ogre 2 and Ogre 1 merge strategy

Post by Ybalrid »

paroj wrote: Mon Jan 28, 2019 12:36 am 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.
Ogre_glTF Ogre v2-1 GLTF2 loader : topic link github repo
BtOgre21 Fork of btOgre, for Ogre v2-1 : topic link github repo
OIS Current maintainer : Official repository
Annwvyn VR focused game engine using Ogre : https://github.com/Ybalrid/Annwvyn https://annwvyn.org/
User avatar
Zonder
Ogre Magi
Posts: 1172
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 76

Re: Ogre 2 and Ogre 1 merge strategy

Post by Zonder »

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

Would you expect Microsoft to merge windows 10 and 7 together?
There are 10 types of people in the world: Those who understand binary, and those who don't...
User avatar
altren
Gnome
Posts: 334
Joined: Tue Oct 24, 2006 9:02 am
Location: Moscow, Russa
x 26

Re: Ogre 2 and Ogre 1 merge strategy

Post by 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.
Image
paroj
OGRE Team Member
OGRE Team Member
Posts: 2106
Joined: Sun Mar 30, 2014 2:51 pm
x 1132

Re: Ogre 2 and Ogre 1 merge strategy

Post by paroj »

Ybalrid wrote: Fri Feb 15, 2019 3:09 pm 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 ;)
User avatar
Ybalrid
Halfling
Posts: 89
Joined: Thu Jul 10, 2014 6:52 pm
Location: France
x 31

Re: Ogre 2 and Ogre 1 merge strategy

Post by Ybalrid »

paroj wrote: Mon Mar 04, 2019 6:56 pm
Ybalrid wrote: Fri Feb 15, 2019 3:09 pm 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".
paroj wrote: Mon Mar 04, 2019 6:56 pm 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
Ogre_glTF Ogre v2-1 GLTF2 loader : topic link github repo
BtOgre21 Fork of btOgre, for Ogre v2-1 : topic link github repo
OIS Current maintainer : Official repository
Annwvyn VR focused game engine using Ogre : https://github.com/Ybalrid/Annwvyn https://annwvyn.org/