Ogre 2.0 release discussion

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
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Ogre 2.0 release discussion

Post by dark_sylinc »

We've been discussing about an Ogre 2.0 release.

Frankly, if it were by me I would've packaged the repo as is and call it a day. But fortunately the other devs don't agree and persuaded me of polishing it a bit more.

We kept polishing and we narrowed the broken stuff list to quite a small bunch.

TagPoints isn't going to be fixed soon. First we need to integrate the new skeleton system into Entities (which is already in InstancedEntity).
SSAO & Deferred Shading we'll wait until the next update, because porting them then will be a lot easier (and in the case of Deferred Shading, a lot more user friendly).

That leaves shadows and volume component. As for the Volume component, I have no idea what's the status. I'm not quite involved in that component.

Finally... shadows. This is where I can actually make the change. Shadow support has vastly improved in 2.0; but the sample needs to be fully rewritten. And that's where the headaches begin.
The old shaders have a lot of useful functionality (PSM, Regular bias, Slope Bias, linear depth) that my simpler shaders don't have, but at the same these shaders are so heavily modified across the repo history that they're heavily broken (even in 1.x branches); thus it's just better to start from scratch. But it's just a nightmare, because there are many RS to support (HLSL, GLSL, ES, Cg).

So basically to release Ogre 2.0; we'd just need to get Shadow samples working again. But this raises another concern we've been discussing: The next release will be quite disruptive too.
The next release will make Render Queue changes, as well as massive changes in how we handle materials.
The current way of handling materials will be labelled "low level materials". It will still exist and continued to be supported (it is still very useful for i.e. postprocessing effects).

However, the preferred method for using materials for rendering common entities and stuff (probably including UI elements) will be this new "high level" system. This will help us a lot in maintaining shader codebases from all RenderSystems, while making Ogre much user friendlier and easier to make it look good, from newbies to experts. Most Samples will switch to these high level materials.

So, all things considered releasing Ogre 2.0 now "as is" means:
  • Mobile devs will love it. Advanced features (like TagPoints) aren't usually required, and Ogre's 2.0 huge performance benefits will be welcomed in these platforms.
  • Any developer involving too much time in this release will be mad when he finds out the next release strongly suggests to move their material databases to the new system. Their old materials will still work; so if were written 2 years ago, it's ok. But if they're newcomers who decided to give 2.0 a shot and already started writing around their own materials and shaders, they'll be pissed and think their time was wasted.
  • Advanced users will poke a bit with it, but probably won't find it more than a curiosity. No TagPoints could scare them away. And TagPoints will only be supported in the new Animation system, which is quite different from the legacy one. Advanced users won't like to code with a Skeleton interface that's going to change in the next version. They can use the new version with InstancedEntities, but with regular entities, they're stuck. Furthermore, enthusiasts are probably already trying 2.0 from the latest repo.
  • Newcomers may feel these limitations as a sign that Ogre 2.0 is a mess, when this isn't true, but damages our image and reputation.
Murat suggested the idea of releasing a "CPT" Community Technology Preview. I really like this idea.
"Alpha" & "Beta" usually means "this can crash!! and it has memory leaks!!!", which isn't our case. Crashes & bugs in 2.0 are rare(*) and we don't leak. But at the same time, it isn't final and I wouldn't recommend it to be used in AAA production (Torchlight, I'm thinking of you)
A CPT gives us the opportunity to test a stable release (we need feedback), the mobile devs will be happy, advanced users will know what they get, and newcomers know this comes with a label attached "this may change in the future; it's a (stable) work in progress"; that is we avoid damaging our image.

(*)Bugs are rare, but 2.0 doesn't have the extreme flexibility of 1.x and is much less forgiving to user mistakes. For example, altering the camera or creating a light in a RenderTarget listener is forbidden and will trigger an assert. Read the porting manual (also contained in the Docs folder in the repo).

What is so hot that will change in the next release?
The reason of this post is to ask the community about the idea of releasing Ogre 2.0 Community Technology Preview, while we work on the final Ogre 2.0 (or just skip to 2.1 entirely; my team mates disagree in skipping 2.0); the big changes are:
  • New High level material system (HLMS). Easier to use, to extend, to setup, to maintain; and will look much better (basically "make me pretty" magic button).
  • Auto instancing, only possible with the HLMS. This will bring HUGE performance improvements.
  • All samples will use the HLMS except when inappropriate.
  • New Animation system: The same system that is now in InstancedEntity will also be in Entity. If your codebase contains Skeleton/Animation/NodeAnimationTrack pointers, you'll probably have to make a lot of changes there. Legacy skeleton system can still be used (by compiling w/ OGRE_LEGACY_ANIMATIONS in CMake) but they won't have TagPoint support.
  • RenderQueue changes: A brand new RQ. If you have calls to setRenderQueueGroup & Co. you may have to revise them, and RQ listeners will probably no longer work.
The aesthetics improvement from HLMS + ease of use (compared to current low level materials) + the performance gains of 2.0 + auto instancing will put Ogre 2.x competing against AAA engines (CryEngine, UDK, Frostbite & Unity) in the Graphics department (these engines are also game engines, something we are not). We may even be able to beat them in a few areas.
The HLMS benefits cannot be taken lightly!

Btw, the CPT release would be released with a less interactive version of Shadows sample so that we can show how to setup Shadows in 2.0; without much hassle for us (while we prepare a more advanced version in 2.0 Final using the HLMS)

In summary Ogre 2.0 Final can become quite different from 2.0 CTP; which is the whole point of this post.
So guys, what do you think?

Edit: I'm leaving this sticky for 60 days.
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogre 2.0 release discussion

Post by holocronweaver »

dark_sylinc wrote: But it's just a nightmare, because there are many RS to support (HLSL, GLSL, ES, Cg).
I can take care of the GLSL ports for GL3+. Personally I wouldn't worry about Cg - so long as HLSL and GLSL are available, we are good. Cg is bonus.
dark_sylinc wrote: In summary Ogre 2.0 Final can become quite different from 2.0 CTP
Besides the HLMS and the skeleton/animation system, are there any other API that might change between CTP and Final?

At the moment most of my prototypes make little or no use of animation, so I am guessing I am an ideal candidate for trying out 2.0 as is. As I mentioned to you on Twitter, I will be hopping on the 2.0 bandwagon in a couple weeks. :)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre 2.0 release discussion

Post by dark_sylinc »

holocronweaver wrote:
dark_sylinc wrote: But it's just a nightmare, because there are many RS to support (HLSL, GLSL, ES, Cg).
I can take care of the GLSL ports for GL3+. Personally I wouldn't worry about Cg - so long as HLSL and GLSL are available, we are good. Cg is bonus.
Well, that's in relation to the shadow sample (which is quite exponential in features to support)
The HLMS shader data will be divided in 3:
  • HLSL (d3d9)
  • HLSL4 (d3d11+)
  • GLSL (GL & ES; In GL, the glsl lang is 330 minimum)
dark_sylinc wrote: In summary Ogre 2.0 Final can become quite different from 2.0 CTP
Besides the HLMS and the skeleton/animation system, are there any other API that might change between CTP and Final?[/quote]
Not that I can think of.
We have yet to integrate the new resource system that was done in another GSoC; but I'd wait for that one.
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Ogre 2.0 release discussion

Post by Klaim »

dark_sylinc wrote: In summary Ogre 2.0 Final can become quite different from 2.0 CTP; which is the whole point of this post.
So guys, what do you think?
As a non-expert user, I would say that I like the CTP idea too as it immediately suggests that it is not a production-ready version but still can be interesting to "early adopters" (who like to walk on the bleeding edge) and that nothing in it is guaranteed to end up in a normal release. So, it's makes the message clear that it's an non-production-ready version (as maintenance support isn't guarantee) and it's what I need to know before trying to integrate it in some apps.
I believe that Microsoft was successful in getting feedback from a lot of people when they started doing this (also to appease their clients with more releases per year...).

So, CTP looks like a good idea.

The auto-instancing feature looks incredibly useful if it works and I believe my game would hugely benefit from it. So it's certain that I'm interested in using the 2.0 or 2.1 release, but I dont' know if I'll be able to "play" with the CTP yet (it's time consuming). But if I have an opportunity I'll do.
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: Ogre 2.0 release discussion

Post by al2950 »

dark_sylinc wrote:In summary Ogre 2.0 Final can become quite different from 2.0 CTP; which is the whole point of this post.
So guys, what do you think?
I also really like the idea of a CTP, as long as its made very clear what it is. (ie dont just name it Ogre 2.0 CTP).

As for what will make the cut for the first CTP, I am practically jumping up & down on the spot just waiting to port my system to 2.0. The only thing that is preventing me is the animation system, as a result for selfish reasons :wink:, is there anyway to expedite the new animation system so it makes the CTP release? Can the community, ie me, help at all?
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Ogre 2.0 release discussion

Post by Zonder »

CTP is defiantly a good idea gets feedback earlier and people know it's not ready. One question are you planning to do an actual SDK release or are you thinking source code builds only?
There are 10 types of people in the world: Those who understand binary, and those who don't...
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
x 218
Contact:

Re: Ogre 2.0 release discussion

Post by Jabberwocky »

I'm on board with CTP, provided it is clearly labeled as such. There should be a link (perhaps to this thread) of currently supported and unsupported functionality.

We should also warn 2.0 users that many useful tools and plugins (Ogitor? OgreMax? ParticleUniverse, CEGUI, etc) are not ported yet. Ideally, we'd list the most common tools and plugins, and list their compatibility with 2.0. Otherwise, this will definitely catch unsuspecting users by surprise who begin to use 2.0 for any non-trivial purpose requiring more than just a graphics engine.

A couple considerations about throwing the CTP switch:
1. The 2.0 release will cause a lot of help/support requests here on the forums. dark_sylinc, are you ready to deal with this? If not, perhaps wait until a better time.

2. I assume the API and material changes will invalidate a lot of our wiki, documentation, and forum posts. Do we need a strategy for dealing with this?

For example, after the 2.0 release, I can imagine this kind of thing happening all the time:
  • An Ogre 2.0 user searches the forums for something like "manual skeleton bone control".
  • They find an old post describing how to do this in pre-2.0 ogre.
  • They end up being confused and annoyed, as the forum code/advice does not work for them.
  • Our forums fill up with "why doesn't this work for me?" posts.
  • Moderators and users are constantly posting "because that's pre-2.0 code".
How big of problem this will be, I don't know.
But I suppose we should at least consider something like a new 2.0 (sub)forum and wiki section. Maybe the current stuff gets moved into a pre 2.0 (sub)forum. Either way, things get complicated, but it's worth discussing it before any official 2.0 release.
Image
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Ogre 2.0 release discussion

Post by Zonder »

Jabberwocky wrote: But I suppose we should at least consider something like a new 2.0 (sub)forum and wiki section. Maybe the current stuff gets moved into a pre 2.0 (sub)forum. Either way, things get complicated, but it's worth discussing it before any official 2.0 release.
I think this is a very good point, a strategy for this should be decided.
There are 10 types of people in the world: Those who understand binary, and those who don't...
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre 2.0 release discussion

Post by dark_sylinc »

Jabberwocky, I really like your post!
Jabberwocky wrote:We should also warn 2.0 users that many useful tools and plugins (Ogitor? OgreMax? ParticleUniverse, CEGUI, etc) are not ported yet. Ideally, we'd list the most common tools and plugins, and list their compatibility with 2.0. Otherwise, this will definitely catch unsuspecting users by surprise who begin to use 2.0 for any non-trivial purpose requiring more than just a graphics engine.
Yes, true. While some of these could be relatively easy to port but won't work yet (PU, CEGUI) and others may probably still work (OgreMax), others just won't (Ogitor) without extensive changes.
Jabberwocky wrote: 1. The 2.0 release will cause a lot of help/support requests here on the forums. dark_sylinc, are you ready to deal with this? If not, perhaps wait until a better time.
Is that ever gonna happen? :evil:
Jabberwocky wrote:2. I assume the API and material changes will invalidate a lot of our wiki, documentation, and forum posts. Do we need a strategy for dealing with this?
Good point. Yes, it invalidates (but not everything). Yes, we need a strategy. No, I don't have one.
For example, after the 2.0 release, I can imagine this kind of thing happening all the time:
  • An Ogre 2.0 user searches the forums for something like "manual skeleton bone control".
  • They find an old post describing how to do this in pre-2.0 ogre.
  • They end up being confused and annoyed, as the forum code/advice does not work for them.
  • Our forums fill up with "why doesn't this work for me?" posts.
  • Moderators and users are constantly posting "because that's pre-2.0 code".
Ouch! Another good point.
Something we're planning is to make a sudden shift in how we make and present samples. We'll have two major categories: Showcase and API Usage.
Under API usage, there will be samples that its sole reason is to show how to use a particular feature. i.e. a simple demo showing only how to use manual bones, labelled "Manual Bones Demo". Nothing more, nothing less.
Our answer will be "That's because that's pre-2.0 code. Look under 'Samples/ApiUsage/ManualBones' on how to do it"
Either way, things get complicated, but it's worth discussing it before any official 2.0 release.
Agreed.
TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 65

Re: Ogre 2.0 release discussion

Post by TheSHEEEP »

I am also for the release of a CTP version.

IMO, the following steps would be very helpful:
  • Split the Ogre forums into 2.0 and 1.x, at least those that are used regularly for requests, like Help, Developers, Ogre In Practice and Mobile Development.
  • Have two wikis. One for Ogre 1.x (basically the current one, just keep it) and one for 2.x, which will basically be a selective copy of the current wiki - only the most important pages, and those updated to 2.x API. The 1.x wiki should not receive official updates any more.
  • A very detailed and complete porting guide. There currently is a draft, which is a nice start, but we need much more. Like "If you did something like this in 1.x, do it like that in 2.0", tackling topics like "I did a manual RT like this, how to do this with the new compositors". It should be its own section in the wiki.
This would definitely lead to a bigger forum and wiki, but everything else would be a horrible mess. I'd rather have a bigger selection of clean forums than a smaller selection of messy ones.
Just imagining wildly mixed wiki entries for 1.x and 2.x makes little sheep very sad.
Same for a forum that confuses the hell out of people because nobody really knows what version a problem is about (and not all people will specify their version, and we can't force them automatically).

After some time (when 2.1 or 2.2 is out or something like that) we could just combine all 1.x forums into one and eventually close that down, too.
IMO we need a special solution for the time "between" 1.x and 2.x, where we will have mixed usage of both. As the version spread changes in favor of 2.x, we could shut down the old stuff step by step.
My site! - Have a look :)
Also on Twitter - extra fluffy
User avatar
Faranwath
Halfling
Posts: 93
Joined: Mon Jul 09, 2012 2:19 pm
Location: Cuba
x 7

Re: Ogre 2.0 release discussion

Post by Faranwath »

Klaim wrote:As a non-expert user, I would say that I like the CTP idea too as it immediately suggests that it is not a production-ready version but still can be interesting to "early adopters" (who like to walk on the bleeding edge) and that nothing in it is guaranteed to end up in a normal release.
I agree.
Jabberwocky wrote:I assume the API and material changes will invalidate a lot of our wiki, documentation, and forum posts. Do we need a strategy for dealing with this?
I might be available to work on updating some wiki articles (e.g. tutorials, or even creating new ones!) in a month or two, depending on how fast I can finish my undergraduate thesis. And, just to be clear, when I say I could work on it, I mean to actually take it as a priority.

Like Klaim, I'm no expert user, but have some degree of familiarity with Ogre. I also think that it's a nice way of giving back (e.g. dark_sylinc has literally worked his ass off to put this together).
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre 2.0 release discussion

Post by dark_sylinc »

TheSHEEEP wrote:
  • Have two wikis. One for Ogre 1.x (basically the current one, just keep it) and one for 2.x, which will basically be a selective copy of the current wiki - only the most important pages, and those updated to 2.x API. The 1.x wiki should not receive official updates any more.
(...)
As the version spread changes in favor of 2.x, we could shut down the old stuff step by step.
Just to clarify, we won't be dropping 1.x for a "long" time. We'll release a support timeline schedule. We won't be adding major features though, but rather bug fixing or small stuff.
We understand there are important commercial applications who cannot afford to jump to 2.x just like that.
TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 65

Re: Ogre 2.0 release discussion

Post by TheSHEEEP »

Yes, exactly. What I wrote was more in terms of years than months. Probably should have added that ;)
My site! - Have a look :)
Also on Twitter - extra fluffy
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogre 2.0 release discussion

Post by holocronweaver »

I prefer we never shut down any portion of the forum unless archives are created. I continue to find bits of ancient OGRE posts from as far back as 2004 to be very useful, even if the sample code is useless. Reviewing previous attempts and their outcomes is priceless and saves me countless hours otherwise spent following a path to nowhere.

As for the wiki, splitting it into pre- and post-2.0 sub-wikis seems best. If tikiwiki supports multiple wikis, these could have different URLs, otherwise the wiki homepage could present two options: 1.* or 2.*.
drwbns
Orc Shaman
Posts: 788
Joined: Mon Jan 18, 2010 6:06 pm
Location: Costa Mesa, California
x 24

Re: Ogre 2.0 release discussion

Post by drwbns »

Sounds like very good ideas for a release schedule and a seperate sub-forum for 2.0. The wiki concerns me though. Maybe old wiki entries need a pre-2.0 sticker attached to the top so users immediately know it's dated information.
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Ogre 2.0 release discussion

Post by Klaim »

I forgot to ask: would the CTP already contain the new resource system or not yet? (I'm thinking that maybe there will be several CTP, if massive changes are being made after feedback).

For the wiki, I'm not sure it's a good idea to have a separate wiki. In particular if you make the original one read-only, it will prevent people from adding new articles and techniques for 1.x versions that might still be useful.
Maybe a better solution would be to have an obvious marker to each pages which makes obvious which version of Ogre the page is valid about. I thought that was already there by the way.
In any way, duplicating progressively the pages for Ogre 2.0 would be less problematic than duplicating a wiki and trying to convert all the pages.
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4304
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 135
Contact:

Re: Ogre 2.0 release discussion

Post by spacegaier »

We discussed some of those topics and ideas raised in this thread internally today and currently plan to create dedicated, clearly-marked forum sections for Ogre 2.x, but within our current forum.

In regard to the wiki: We do not plan to create a second independent wiki installation but instead will look for a way to clearly link pages to Ogre versions.

We will provide more details, as they situation matures.
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
hydexon
Gremlin
Posts: 164
Joined: Sun Apr 14, 2013 8:51 pm
x 10

Re: Ogre 2.0 release discussion

Post by hydexon »

I see a lot of issues about the animations and shadow techniques issues, i'm working hard in a ambitious project with Ogre 1.9 and we wait fot the 2.0 , with the animation field we using animated character using SmartBody animation middleware, we think the team behind of the middleware will adapt it to the new version without effort, the mechanical parts in the game they are using abstracted classes, so we can replace meanwhile the native and soon legacy Ogre's animation system with Cal3D meanwhile.

I have heavy debuts about the Particle Universe plugin since will be using it extensively and Ogitor which their editing backend is used in our editor, and the material system which uses.
drwbns
Orc Shaman
Posts: 788
Joined: Mon Jan 18, 2010 6:06 pm
Location: Costa Mesa, California
x 24

Re: Ogre 2.0 release discussion

Post by drwbns »

Klaim wrote: Maybe a better solution would be to have an obvious marker to each pages which makes obvious which version of Ogre the page is valid about. I thought that was already there by the way.
I believe the only marker currently on the wiki pages is the optional "Works with current stable Ogre" label
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Ogre 2.0 release discussion

Post by Klaim »

Indeed a version marker would be far more useful.
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Ogre 2.0 release discussion

Post by Zonder »

Yes a version label would be best. As all information is relevent but we don't want to update everything all the time. but it allows someone to find information on something but then can follow the code migration guides for each version to update it.
There are 10 types of people in the world: Those who understand binary, and those who don't...
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
Posts: 273
Joined: Mon Oct 29, 2012 8:52 pm
Location: Princeton, NJ
x 47

Re: Ogre 2.0 release discussion

Post by holocronweaver »

If we follow the path of tagging individual pages with minimum version numbers, we should start by bulk tagging with something like "Written for OGRE version <fill me in>", so users are encouraged to fill in the minimum version number. Otherwise it is likely there will be many pages that never get tagged.

EDIT: Also, if we plan to support 1.* for some time, I am confused how tagging wiki articles will solve the problem of needing documentation for both 1.* and 2.*. Articles which are upgraded to 2.* will be less useful to 1.* users, reducing 1.* documentation.
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4304
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 135
Contact:

Re: Ogre 2.0 release discussion

Post by spacegaier »

Currently the tagging is meant for the forums. In regards to the wiki, we had a solution with a version dropdown per page in mind, much as Microsoft does with their pages.
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Ogre 2.0 release discussion

Post by Klaim »

I'm re-iterating my question in case nobody noticed it: is the new resource management system planned to be merged for the CTP or later?
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5296
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: Ogre 2.0 release discussion

Post by dark_sylinc »

Klaim wrote:I'm re-iterating my question in case nobody noticed it: is the new resource management system planned to be merged for the CTP or later?
It's not going to be in the CTP.
Now as for the final version, we'll see.
I'd like to wait and release final without the resource changes, but at the same time I don't want to introduce another ground-breaking change after saying "this is the final version".
We have yet to analyze the state of the new resource system and evaluate how easy it is to port.

Cheers
Matias
Post Reply