[GSoC 2013] When will it be merged into the Ogre main branch

[Shtuka]

When will the GSoC 2013 projects be merged into the Ogre main branch?

[masterfalcon]

Tough to say exactly. It depends upon the state of each project but probably as quickly as we can.

[duststorm]

Tomorrow is the official evaluation deadline. I think then we will know which of the projects have passed.

[Xavyiy]

Tomorrow is the official evaluation deadline. I think then we will know which of the projects have passed.

I wish all the best to all GSOC mates this year! I've seen a lot of development info of some projects via twitter and also on the forum for the rest of projects, so crossing fingers! 5/5 passed projects would be awesome

[syedhs]

Slightly off-topic.. does official 1.9 wait for certain GsoC projects to be completed before it is released? 1.9RC1 has been released for quite some time...

[holocronweaver]

I've seen a lot of development info of some projects via twitter...

I am guilty of updating way more often on Twitter than the forums. Apologies to whom bird is not the word.

[spacegaier]

Slightly off-topic.. does official 1.9 wait for certain GsoC projects to be completed before it is released? 1.9RC1 has been released for quite some time...

This is still in discussion internally. We haven't yet made up our minds. I personally would probably vote for merging into 2.0 to finally get 1.9 marked as "stable" now and to let the GSoC changes mature a bit in the 2.0 branch.

Any preferences from the community (with reasons please )?

[scrawl]

I personally would probably vote for merging into 2.0 to finally get 1.9 marked as "stable" now and to let the GSoC changes mature a bit in the 2.0 branch.

Any preferences from the community (with reasons please )?

I agree. There really should be a feature freeze now. 1.9 is in RC since quite a while, and the more features we are merging in, the more bugs are going to pop up naturally.
Actually, "official" feature freezes as soon as the RC is released would probably be the best idea. We've had the same problem with 1.8 which was also in RC for a very long time, wasn't it?

[Transporter]

Any preferences from the community (with reasons please )?

I would split the results:

Ogre 1.9

• OpenGL 3+; Geometry & Tessellation
• DirectX 11,Tessellation Samples
• Improve Progressive Mesh

OGL3+ and DX11 already experimental parts of Ogre 1.9. It would be nice to finish them asap. Tessellation is used in modern games so it is useful to push the technique to make Ogre more interesting for developers of new games. The progressive mesh part could improve the performence of existing models.

Ogre 2.0

• Ogre 2.0
• Resource System Redesign

In my opinion the best point of integrating a new resource system design is the Ogre 2.0 cleanup.

An other solution is code close for Ogre 1.9.0 stable and adding the features to a patch version 1.10.0 later.

[Klaim]

I agree with Transporter, Ogre 2.0 and Resource System Redesign are clearly interface breaking while OGL, DX and improved tesslation are basically implementation enhancements or fix. I don't mind if these last ones are in Ogre 1.10 though, since it looks like hard work and 1.9 really needs to be a fixed versions. Right now each time someone point a problem it's hard to figure out which 1.9 it is and if you might be affected or not.

[drwbns]

Completely agree with Transporter as stated above.

[holocronweaver]

I too agree with Transporter.

In addition, I want to point out that the components and render systems are likely to increasingly diverge between 1.* and 2.*. Trying to maintain feature parity will become tedious, so I suggest we set a feature freeze after version 1.9 so that 1.10+ will only receive new 2.* features if someone is willing to make special effort to backport (merge + test + debug). Developer time and energy should be almost exclusively allocated to OGRE 2. Adding new features to OGRE 1.* should not be forbidden by any means, but it should be lowest priority except for mission-critical issues.

OGRE 2 is the vessel of our hopes that will lure patrons to the shore, so we better make sure this dreamboat is seaworthy or else the whole enterprise could sink. I did not spend a whole summer scrubbing decks and greasing gears to see my love at the bottom of the ocean.

[Owen]

Right. I think those 3 projects could be good candidates for a 1.10, but its' awkward timing; 1.9 hasn't even shipped yet.

However, they're of sufficient magnitude that I don't think they should go into 1.9 at this stage either (Hell, ideally I'd say no new features once RC1 is called, no major ones after the first "beta" release). Traditionally, RC spins just fix bugs; the final RC just graduates to release when there aren't any remaining blocking issues and sufficient testing has elapsed.

So maybe the aim should be for v1.9 to be *very soon*; v1.10 testing releases (i.e. traditional alphas) to follow up ASAP; aim to release in ~3 months time?

I think 2.0s' gestation and testing cycle is going to be longer than most; after all, the changes are quite large; there are sure to be bugs.

Additionally, the changes were build against the current codebase (as opposed to the massively changed one coming post refactor). Being as there is no need to backport... it would be nice to push them out for projects currently using the 1.X series. Some of those will never get upgraded to 2.0, but might enjoy the incremental features.

[holocronweaver]

So maybe the aim should be for v1.9 to be *very soon*; v1.10 testing releases (i.e. traditional alphas) to follow up ASAP; aim to release in ~3 months time?

I +1 this idea, including time frames. Maybe release 1.9 in the first half of October?

I think 2.0s' gestation and testing cycle is going to be longer than most; after all, the changes are quite large; there are sure to be bugs.

@Matias & Owen: How long until a industry ready 2.* version is out? I would say animation is a requirement. If it is 6+ months, then perhaps we should feature freeze 1.* later than 1.9. Maybe even feature freeze as far out as 1.11 or 1.12.

[masterfalcon]

I agree, let's merge all but 2.0 and resource manager. Then do some serious bug bashing. I've been trying to get it done all summer but there are some bugs that I am not set up to fix(windows and whatnot) and people have been busy with GSoC.

I think really we should do 1.9, a minor update or two while development shifts to 2.0.

[dark_sylinc]

I agree with Transporter.

GL DX & Progressive Mesh were incremental updates, and can probably be taken back to 1.9
2.0 & Resource System are too ground breaking.

In addition, I want to point out that the components and render systems are likely to increasingly diverge between 1.* and 2.*.

At some point, yes they're gonna diverge a lot. But luckily right now they don't and in the short term it won't.

Developer time and energy should be almost exclusively allocated to OGRE 2. Adding new features to OGRE 1.* should not be forbidden by any means, but it should be lowest priority except for mission-critical issues.

Agreed, we should only still focus some of our effort on 1.9 (or 1.10 or whatever) because it's the stable branch.

OGRE 2 is the vessel of our hopes that will lure patrons to the shore, so we better make sure this dreamboat is seaworthy or else the whole enterprise could sink. I did not spend a whole summer scrubbing decks and greasing gears to see my love at the bottom of the ocean.

That's exactly how I feel too. I worked my ass as if I were in crunch mode for 3 months. That work can't go to waste. That's why I made the pdf (though Google forces you to, but I could have called it a day with the doxygen I make); because I want to make sure people will use it.

@Matias & Owen: How long until a industry ready 2.* version is out? I would say animation is a requirement. If it is 6+ months, then perhaps we should feature freeze 1.* later than 1.9. Maybe even feature freeze as far out as 1.11 or 1.12.

I would prefer keep going ala Blender. Blender wasn't industry ready in 2.50, nor in 2.51, not in 2.52 either, 2.53 "was something"; and started being "industry ready" at around 2.56 IIRC.
So, if you see the Tindalos roadmap, animation refactor happens in 2.1; I'm going to aim to have it by 2.0 though. 2.0 is in a much better state than it was originally planned, we have Compositors!
If we wait a lot of time until "2.0" is ready, the changes will get bigger and bigger (traumatizing the porting efforts), we'll miss feedback from early adopters, and the end result could become a flop (i.e. like Windows XP -> Vista). Generally in SW development, the more we wait "until it's ready", the worse it gets.
I prefer sure but steady releases with an alpha disclaimer or "development build" or "beta team" and a volunteers program.
Animation btw, is working; but is in a lame state (by that, I mean not efficient); though some games may not even be affected by the efficiency drop in animations. I'm working on a few slides for a solution to that.

A few comments on porting:
From some work I've been doing to restore the SampleBrowser; I found out that changes are not that critical as I thought. It can take around 3 days top to get a game compiling again and running; and the engine tells you a lot what you did wrong thanks to well placed asserts and exceptions.
The only exception is porting when you use the compositor from C++ (and porting the scripts can take some time). But overall the system works quite similar to how it used to; functions have the same names, only a few have their parameters changed.

I'm not very knowledge with the Resource GSoC changes, but they do look more intrusive to the end user. By intrusive I don't mean bad, I just mean that to port your existing Ogre project you have to do a bit more code changes to get it compiling again.
I could be wrong but that's my impression.

As for time frames; implementing animations and whatever missing feature that I would like to for Ogre 2.0; it would take around 2 to 3 months full time; but I won't be working full time. It could take anywhere from those 2 months to 6 or 8 months.
I recommend that in 6 months we perform an evaluation to start releasing Release Candidates (RC) with whatever we have at that time; unless it's extremely unstable/buggy or an awesome feature is close to be over.
In 12 months from here on we should have Ogre 2.1

A fully production ready Ogre 2.x that could be used anywhere from AAA games, indies, editors, cinema tools etc. could happen in Ogre 2.2 or 2.3; which doesn't mean that we can not get it sooner

[Owen]

Resource changes are intrusive but not massive.

In other words: The changes aren't difficult to make, its just there are a lot of places you have to make them.

I've been very busy the past week. I hope to get the overlays working again ASAP.

[holocronweaver]

As for time frames; implementing animations and whatever missing feature that I would like to for Ogre 2.0; it would take around 2 to 3 months full time; but I won't be working full time. It could take anywhere from those 2 months to 6 or 8 months. I recommend that in 6 months we perform an evaluation to start releasing Release Candidates (RC) with whatever we have at that time; unless it's extremely unstable/buggy or an awesome feature is close to be over.
In 12 months from here on we should have Ogre 2.1

That might be the timeline if you continued working solo, but remember that you have a whole team at your side! If we dole out tasks to volunteers and everyone does their part, we should have this ship sailing much faster. Not to mention the more eyes on the code the better. Just pull out your blueprint and point us where you need us.

In a month or two there won't be any major tasks left for me to do in the GL3+ RS, so I can then switch focus to 2.0. I plan to be an early adopter of 2.0 in my personal projects since my current scene graph needs are basic, so I will have both developer and user viewpoints.