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.

Ogre 2.0 release discussion

Postby dark_sylinc » Tue Mar 18, 2014 4:36 am

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.

For this message the author dark_sylinc has received 4 kudos
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 2967
Kudos: 449
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Ogre 2.0 release discussion

Postby holocronweaver » Tue Mar 18, 2014 5:02 am

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
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
 
Posts: 273
Kudos: 47
Joined: 29 Oct 2012
Location: Princeton, NJ

Re: Ogre 2.0 release discussion

Postby dark_sylinc » Tue Mar 18, 2014 5:51 am

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
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 2967
Kudos: 449
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Ogre 2.0 release discussion

Postby Klaim » Tue Mar 18, 2014 10:53 am

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.
User avatar
Klaim
Old One
 
Posts: 2565
Kudos: 60
Joined: 11 Sep 2005
Location: Paris, France

Re: Ogre 2.0 release discussion

Postby al2950 » Tue Mar 18, 2014 12:23 pm

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?
al2950
Minaton
 
Posts: 921
Kudos: 54
Joined: 11 Dec 2008
Location: Bristol, UK

Re: Ogre 2.0 release discussion

Postby Zonder » Tue Mar 18, 2014 12:23 pm

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...
My Blog - http://www.dreamwalkerblog.com
User avatar
Zonder
Gargoyle
 
Posts: 1039
Kudos: 34
Joined: 04 Aug 2008
Location: Manchester - England

Re: Ogre 2.0 release discussion

Postby Jabberwocky » Tue Mar 18, 2014 3:01 pm

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

For this message the author Jabberwocky has received 2 kudos
User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
 
Posts: 2819
Kudos: 218
Joined: 05 Mar 2007
Location: Canada

Re: Ogre 2.0 release discussion

Postby Zonder » Tue Mar 18, 2014 4:07 pm

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...
My Blog - http://www.dreamwalkerblog.com
User avatar
Zonder
Gargoyle
 
Posts: 1039
Kudos: 34
Joined: 04 Aug 2008
Location: Manchester - England

Re: Ogre 2.0 release discussion

Postby dark_sylinc » Tue Mar 18, 2014 4:47 pm

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.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 2967
Kudos: 449
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Ogre 2.0 release discussion

Postby TheSHEEEP » Tue Mar 18, 2014 5:06 pm

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

For this message the author TheSHEEEP has received kudos
TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 972
Kudos: 64
Joined: 02 Jun 2008
Location: Berlin

Re: Ogre 2.0 release discussion

Postby Faranwath » Tue Mar 18, 2014 6:17 pm

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
Faranwath
Halfling
 
Posts: 93
Kudos: 7
Joined: 09 Jul 2012
Location: Cuba

Re: Ogre 2.0 release discussion

Postby dark_sylinc » Tue Mar 18, 2014 8:20 pm

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.
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 2967
Kudos: 449
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Re: Ogre 2.0 release discussion

Postby TheSHEEEP » Wed Mar 19, 2014 12:12 am

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
TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
 
Posts: 972
Kudos: 64
Joined: 02 Jun 2008
Location: Berlin

Re: Ogre 2.0 release discussion

Postby holocronweaver » Wed Mar 19, 2014 12:24 am

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.*.
User avatar
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
 
Posts: 273
Kudos: 47
Joined: 29 Oct 2012
Location: Princeton, NJ

Re: Ogre 2.0 release discussion

Postby drwbns » Wed Mar 19, 2014 12:34 am

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.
drwbns
Orc Shaman
 
Posts: 777
Kudos: 23
Joined: 18 Jan 2010
Location: Costa Mesa, California

Re: Ogre 2.0 release discussion

Postby Klaim » Wed Mar 19, 2014 12:40 am

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
Klaim
Old One
 
Posts: 2565
Kudos: 60
Joined: 11 Sep 2005
Location: Paris, France

Re: Ogre 2.0 release discussion

Postby spacegaier » Wed Mar 19, 2014 1:06 am

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...
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
 
Posts: 4290
Kudos: 126
Joined: 04 Feb 2008
Location: Germany

Re: Ogre 2.0 release discussion

Postby hydexon » Wed Mar 19, 2014 1:20 am

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.
hydexon
Gremlin
 
Posts: 162
Kudos: 9
Joined: 14 Apr 2013

Re: Ogre 2.0 release discussion

Postby drwbns » Wed Mar 19, 2014 10:23 pm

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
drwbns
Orc Shaman
 
Posts: 777
Kudos: 23
Joined: 18 Jan 2010
Location: Costa Mesa, California

Re: Ogre 2.0 release discussion

Postby Klaim » Wed Mar 19, 2014 10:37 pm

Indeed a version marker would be far more useful.
User avatar
Klaim
Old One
 
Posts: 2565
Kudos: 60
Joined: 11 Sep 2005
Location: Paris, France

Re: Ogre 2.0 release discussion

Postby Zonder » Thu Mar 20, 2014 8:52 am

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...
My Blog - http://www.dreamwalkerblog.com
User avatar
Zonder
Gargoyle
 
Posts: 1039
Kudos: 34
Joined: 04 Aug 2008
Location: Manchester - England

Re: Ogre 2.0 release discussion

Postby holocronweaver » Thu Mar 20, 2014 4:27 pm

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
holocronweaver
Google Summer of Code Student
Google Summer of Code Student
 
Posts: 273
Kudos: 47
Joined: 29 Oct 2012
Location: Princeton, NJ

Re: Ogre 2.0 release discussion

Postby spacegaier » Thu Mar 20, 2014 4:55 pm

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
spacegaier
OGRE Team Member
OGRE Team Member
 
Posts: 4290
Kudos: 126
Joined: 04 Feb 2008
Location: Germany

Re: Ogre 2.0 release discussion

Postby Klaim » Thu Mar 20, 2014 11:36 pm

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
Klaim
Old One
 
Posts: 2565
Kudos: 60
Joined: 11 Sep 2005
Location: Paris, France

Re: Ogre 2.0 release discussion

Postby dark_sylinc » Fri Mar 21, 2014 4:55 am

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
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
 
Posts: 2967
Kudos: 449
Joined: 21 Jul 2007
Location: Buenos Aires, Argentina

Next

Return to Developer talk

Who is online

Users browsing this forum: No registered users and 2 guests