The roadmap to 1.9 and 2.0

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

The roadmap to 1.9 and 2.0

Post by CABAListic »

Hey everyone,

with the release of 1.8 out of the way, it's time to plan for the future. There have been quite a few comments in the forums and in our user survey about what you'd like to see in coming versions, and it's time to assemble a concrete roadmap. The Ogre team has been discussing internally the steps that we deem critical or important for the next two versions, and we'd like to get your opinion to ensure that we don't accidentally head off in a completely different direction from what you need.
Please bear in mind, though: It's not possible to please everybody, and also we'd like to focus on critical and important items, first. That is to say, the list I'm presenting here is not meant to be complete; merely we would like to get a picture of the bare essentials that have to happen before we can release 1.9 and 2.0. Of course, in addition to those items we are hoping again for your contribution to submit patches and new features (small and large).

So here is what we are currently considering for the "essentials" roadmap:
  • Finish our new-generation render systems. This includes the DX11 rendersystem and masterfalcon's work on a new OpenGL renderer targeting GL3+. Also need to complete support for the new-generation additional shader types. This is targeted for 1.9; there's currently a GSoC project for the DX11 rendersystem, so hopefully that one's covered. :)
  • Improved support for current mobile platforms. Most importantly this includes support for the Android platform, but there are other necessary improvements to be made, like using NEON math for ARM platforms. Targeted for 1.9.
  • A state cache for the rendersystems to avoid unnecessary state changes. Already working for GLES2, needs to be ported to the other systems as needed. Targeted for 1.9.
  • Clean up Ogre core and possibly move features to separate components/plugins. While Ogre is already a modular project in principle, with a number of components and plugins in addition to OgreMain, there is still a somewhat large monolithic core, and its size can be an issue on mobile platforms. We should try to identify features that can be easily moved to separate components, and while we're at it, other parts might benefit from a little restructuring. Features to be moved to separate components could include e.g. overlays and animations. The resource system has also been a request to be removed from the core, but personally I'm not sure this is possible without sacrificing quite a bit of ease-of-use. Either way, the resource system could probably need a bit of an overhaul and perhaps be simplified in the process.
    Also getting rid of string identifiers and string comparisons has been highly demanded in our user survey requests.
    To be targeted for 1.9/2.0 on a per-project basis.
  • SceneManager redesign. This is probably the most ambitious undertaking of them all and as such definitely targeted for 2.0. There are several aspects to this, some of which concern very basic performance issues: Our current SceneNode system requires too much memory and is cache-unfriendly. This needs to be reworked, maybe even for 1.9, if possible (without breaking too much of the current interface). But there's also been an ongoing discussion started by sinbad about feature-wise evolution of the SceneManager to better suit large worlds and making multiple SceneManagers work together. The original discussion can be found here, we need to sort through it and assemble a concrete design document for the new SceneManager design.
  • Rework multithreading support. I am not an expert on the field, but here's what I have gathered from previous discussions:
    • Ogre is generally not considered thread-safe and should be restricted to a single application thread. Yet a lot of code in Ogre is guarded by mutexes and other constructs, in particular our SharedPtrs. Given that Ogre is not meant to be thread-safe, we should get rid of the SharedPtr locks and localise locking to the actual background tasks (resource loading) for performance reasons. Might be doable for 1.9.
    • The current Ogre threading system for background tasks strikes me as overcomplicated and requires rather complex synchronisation primitives that few threading libraries implement (not even std::thread). This should ideally be reworked to be able to use std::thread for threading if available, or ideally even something as simple as TinyThreads. Might be doable for 1.9.
    • The Ogre render loop itself should be parallelised where possible, particularly scene graph updates. From my understanding this would require a structure based on microtasks, and given that these microtasks must take precedence over any background resource loading or similar tasks, we either need a sophisticated task scheduler, or perhaps simply separate thread pools for background tasks and microtasks. We could perhaps prepare the infrastructure in 1.9, but the actual parallelisation is better left for 2.0, because it should probably be done in unison with the SceneManager redesign.
Anyway, this is the short form of what we think Ogre's future should hold. As I said, this is basically only the critical list, so it's not exhaustive - for example, there are a number of GSoC projects running right now that will hopefully make it into 1.9. Do you think we missed something really important? Are you generally happy with this roadmap. Any feedback at this stage is welcome! Some of the items will eventually have to be discussed more in-depth, but this is best done in separate topics once we've agreed on the general outline.
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: The roadmap to 1.9 and 2.0

Post by Wolfmanfx »

What are the time frames in general? Are we talking about 6-9 months release cycles?
In which form task planning & project tracking will happen - until now we have mantis (bug tracking) and the wiki were used to keep the todo list (which mostly were maintained by steve).
Also the private forum is used but maybe its better to open up detail planning.
Is it possible to use JIRA for the task planning?

I know i am asking project management questions but thats one area which needs also improvement :)
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: The roadmap to 1.9 and 2.0

Post by CABAListic »

Quite true, but imho one step after the other. Let's agree on the 'what' first, then tackle 'how' :)
As far as time frame goes, we have been asked to shorten our release cycle so that ideally a new major release happens roughly every year. So as far as I'm concerned, that's the target deadline. Of course, if we can make it depends also on the kind of help we get, because I'm pretty sure that we will not be able to complete all items on this roadmap without the community.
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: The roadmap to 1.9 and 2.0

Post by Klaim »

I wish so much I could help with several of these features, I think I could but then I already have too much in my plate TT_____TT that's depressing in these exciting times!

Anyway I think all the big tasks have been listed.
On the multithreading point, I was thinking that Ogre but also a lot of other projects really need to base at least some of it's work on task scheduling stuffs, but there are still no standard thread pool facilities...
Having a task scheduler abstraction (whatever the quality or implementation) would simplify some of the system when multithreading is activated.
I'm doing something similar in a (less complex) project so I'v been thinking and reading a lot about the subject and practicing a bit and I see how to setup everything for my project but I'll choose a specific task scheduler implementation instead of writing one or abstracting one, because it's not a library. So the question is: does Ogre really need to allow the user to choose the threading library, or can it impose it but still be isolated in some ways?

Also, less important point but what about requirements concerning C++11? I see a lot of improvements possible at least just for readability of the Ogre source code, but in the same time I understand the constraints.
So I wanted to suggest: maybe have a way to exploit important C++11 features if it's helpful, but only activated when using a C++ compiler (using a mix of macro maybe?)
Then start requiring a C++11 compiler starting with post-2.0 versions? It's far from it but thinking about the strategy concerning the language might be important as a lot of the improvements planned for ogre are performance and modularity contraints...


About the SharedPtr... I think removing the thread safety might be a problem for users who thinks it behave like a std::shared_ptr. But I understand the cost. I think another strategy could be used to avoid the syncrhonization cost, but it need more thinking (I mean I 'd like to propose a solution but my thinking is not complete yet on the subject).
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: The roadmap to 1.9 and 2.0

Post by CABAListic »

So the question is: does Ogre really need to allow the user to choose the threading library, or can it impose it but still be isolated in some ways?
We do not generally offer a choice when it comes to dependencies, but threading is problematic. Aside from Boost (which is a very heavy-weight dependency) there is not currently a suitable threading library (to my knowledge) that is
a) working for all our platforms and
b) has a liberal, untainted license.
Intel's tbb comes close, but its license is tainted.
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: The roadmap to 1.9 and 2.0

Post by Klaim »

Do you mean that when boost get modularized, requiring boost::thread might be a good way to solve this problem? From what you say of the timeframe for the next versions and what I know is happening in the boost community right now, it looks like boost will do it's move before most Ogre 2.0 work will be done.
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: The roadmap to 1.9 and 2.0

Post by Wolfmanfx »

If we target a 1 year release cycle we should target 9 months for the first beta release - otherwise it could take much longer when the feature freeze is delayed too long.

The most important stuff (from my point of view) the OGRE team could focus on is to decouple/cleanup the code like moving out the overlay system to plugins and stuff like that.(This will increase maintainability)
At the last couple of months i am wandering a lot inside ogres core and render systems and i see massive hacks inside which are not easy to separate from the code (yes i am talking to you animation system ;) ) and such a cleanup will also help to make better code.

The first step should be planning what to do and then when to do then its much easier to pick up a task and make (also for not ogre team members) - also i have to mention that the last year or so i had the feeling the project moves on i mean many things happen (be as patches or team additions) BUT everything happens in plan less fashion (no offense here!).
Big features were added untested or minimal tested and broke a lot functionality. Patches were added without thinking too much about it (yes i am looking also into commit messages) and there is a fraction which do the testing just under DX or just under OGL - what happens to automated tests i mean we had GSOC project?

We need to increase the quality and not just push stuff into the community - but that will only possible with a plan.
andrewfenn
Halfling
Posts: 62
Joined: Fri Mar 23, 2007 2:48 pm
x 2

Re: The roadmap to 1.9 and 2.0

Post by andrewfenn »

I'm totally uneducated on this so maybe ogre already has it, so excuse me if this sounds like a stupid suggestion. I was wondering if there should be a nice implementation for the large scene coordinates problem in the core?

There was talk somewhere of doing something (i can't remember where or what) so I'm just wondering if it would be a nice addition to have? I think that game maps are becoming larger and larger these days so having something you don't have to roll your own would be a big plus for developers.
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: The roadmap to 1.9 and 2.0

Post by Wolfmanfx »

Camera relative rendering is already done.
LarsW
Gnoblar
Posts: 11
Joined: Thu Dec 28, 2006 11:42 pm
Location: Berlin, Germany

Re: The roadmap to 1.9 and 2.0

Post by LarsW »

Hi,

Just want to add two thoughts and a wish.

I think it is a good idea to reduce dependencies for the core even more, putting image loading and compressed archives into extra components would get rid of the freeimage and zlib dependency. Then there is freetype which could be removed by separating font handlig together with the overlays (Even if some are rendering text to non overlay textures alone, but that should be the rare case).

Second it could get complicated to optimise the SceneManager for caching and at the same time implement a parallel SceneTree update. The Microtask management has to keep in mind which thread has handled which nodes to fully utilize the cache. Also creating more overhead in management should be optimized away during the scene manager rework. Maybe an approach for parallel scene traversal in case of multiple viewports could be more beneficial this could accelerate rendering of second views like rear-cameras, stereo viewports or dynamic reflection map generation. This would keep the traversal on one thread and therfore with an optimal cache utilization. If supported this could be even more optimized if the viewports are displayed on different rendering devices, but then that would be more something for 2.1 :-)

A little wish would be a bit more support of Stereo (or even n-number of views) Rendering. For OpenGL this is still missing without a patch and maybe a interface is possible to allow plugins for the different Stereo rendering standards (like AMDs HD3D, Nvidias 3D Vision, Quad Buffer Opengl,...).

greetings
Lars
Transporter
Minaton
Posts: 933
Joined: Mon Mar 05, 2012 11:37 am
Location: Germany
x 110

Re: The roadmap to 1.9 and 2.0

Post by Transporter »

LarsW wrote:I think it is a good idea to reduce dependencies for the core even more, putting image loading and compressed archives into extra components would get rid of the freeimage and zlib dependency. Then there is freetype which could be removed by separating font handlig together with the overlays (Even if some are rendering text to non overlay textures alone, but that should be the rare case).
There is a topic about zzip in Feature Request forum: http://www.ogre3d.org/forums/viewtopic.php?f=3&t=70443

But I agree to change the resource manager. Maybe outsourcing it to a plugin could be a more flexible way to get rid of dependencies. I hate freeimage because it is such an effort to build it under VS. On the other hand freeimage is helpful to have one lib for multiple file formats. It's a lot of work to include every format by hand in ogre. Also this will split up one dependency (freeimage) int a group (libpng, libjpg, etc.).

The discussion about thread safty is a hard one. On one hand boost is a threading library for multiple platforms. In contrast, it also a good idea to get rid of that dependency.
User avatar
Mako_energy
Greenskin
Posts: 125
Joined: Mon Feb 22, 2010 7:48 pm
x 9

Re: The roadmap to 1.9 and 2.0

Post by Mako_energy »

Just going to throw in my 2 cents and explain some of the things I am using Ogre for.

First of all I agree with pretty much everything you have listed on your roadmap, Cabalistic, with a possible exception to the threading support. Rendersystem and Mobile support are necessary for Ogre to stay modern and keep being used. The Ogre Core cleanup and SceneManager redesign in particular interest me though. One thing that always bothered me about Ogre and it's team/moderators is that frequently people make the mistake of calling Ogre a game engine. While I agree that this isn't accurate, nor Ogre's focus, I completely understand the mistake. Ogre seems to be confused in this regard as to what it actually is when it provides so many fundamental utilities, such as it's hulk resource system. A resource system seems to me like something that should just be it's own library (that is or isn't affiliated with Ogre), or something that game makers roll on their own. Removing this into it's own library with hooks to make integration easier would more or less completely resolve this issue. Of course this gets a little more complicated when you try to provide threading and background loading, but I feel compelled to ask, is threading something that should be decided by Ogre and potentially forced upon the game developer?

This kinda also plays into my concern about the threading plans you may have. I am working on making my own re-usable engine. I am not the actual developer working on the multithreading code, and I have little experience with multithreading so forgive me if I am misguided in some of these things. In our engine we have opted for a Dependency Graph of tasks. I'm concerned that too much enforcement on threading may cause compatibility issues with integration with our dependency graph forcing us to have to create a fork of Ogre, or worse, choose another library for rendering(very unlikely). We need complete control over our threads, and having a dedicated thread for anything is simply not acceptable in our threading model.

Backtracking to the splitting of OgreMain into more components/libraries/plugins, I feel I should say I completely agree that Overlays and the animation system should be moved into their own libraries. The overlay system is seldom used outside the demo's as I understand. I for one have decided to roll my own GUI system (originally based on gorilla, but heavily forked at this point). So the binary is larger and there is an additional dependency for something I never use. The animation system I also feel should get this treatment despite the fact that I haven't really needed anything else yet, but looking forward I can see needing to make adjustments for physics integration that would be unreasonable for Ogre to make itself(what with being a rendering engine and all). Being able to drop in my own library, even if it's just a light fork on the official animation library is more desirable then maintaining a fork of Ogre.

Moving on to the SceneManagers, I really like all the idea's for it's redesign I've seen thus far. I can't recall who, but I recall someone with a great deal more Ogre experience then myself suggesting the guts of the SceneManager be replaced with a series of plugins that the developer can choose based on their project's needs and their desired pipeline. This makes a lot of sense to me, but I realize that is too much work to expect any time soon. Some slightly lower hanging fruit however...would be to give better multi-scenemanager support by removing the strict ownership of scene objects on the scene manager. Instead creating objects via their own manager or factory class and then adding them to the scenemanager you want them in after they are configured. This would make swapping objects between managers much easier. In the original thread from Sinbad about Tindalos, I also recall him mentioning making the Scene-Nodes entirely optional, but didn't go into much detail there. If that is still possible at all I think that would be pretty awesome.

As usual, if I have missed anything or am just plain wrong about any of my assumptions then please let me know!
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: The roadmap to 1.9 and 2.0

Post by Kojack »

Camera relative rendering is already done.
It helps hide the problem, but not completely. As it moves further from the origin, the position of the camera will lose precision.
User avatar
ahmedismaiel
OGRE Contributor
OGRE Contributor
Posts: 217
Joined: Wed Jan 25, 2006 11:16 pm
Location: Redmond,WA

Re: The roadmap to 1.9 and 2.0

Post by ahmedismaiel »

i'm glad that the new generation render systems & NEON are getting traction .but i don't feel that 1 GSoc for DX11 will be enough though ,it would be great if more investment goes into it (specially with DX11 is the only way to get an app on the Win8 store).
another thing i would like to see since i consider OGRE to be the owner of the E2E scene management and rendering (with the help of plugins) is to provide simplifications or abstractions to modern graphics problems like :
1- shader explosion management (DX11 have dynamic shader linking ,not sure about OpenGL)
2- provide a unified building blocks to setup a deferred rendering system (every body does has to generate their depth buffers ,mrt compositors ,shaders,... ) .ogre can do a lot of heavy lifting there
3- built-in stereo support (DX 11.1 natively support it )
most of these problems are doable outside OGRE but it have a lot of value add specially for new comers who doesn't have to learn all that to build something decent (they will still need to learn alot more to make something great :) ).

is there a deadline to prepare the full details of the road map? i might come back with more requests as i think more about the learning from the games i worked on with OGRE
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: The roadmap to 1.9 and 2.0

Post by bstone »

I can feel the pain of those who want to get rid of the unneeded dependencies (on a case by case basis) but I should say that before committing to Ogre I was looking at Crystal Space. And one of the reasons behind me discarding it was its "everything as a plugin" because that was quite a mess. :D

I can also feel the pain of those who will be reworking Ogre's internals to make things like Overlays and Animation separation possible.

Anyway, I'm not saying that shouldn't be done. Just that it won't be easy and some good things about Ogre will have to be sacrificed in the process.
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: The roadmap to 1.9 and 2.0

Post by spacegaier »

ahmedismaiel wrote:is there a deadline to prepare the full details of the road map? i might come back with more requests as i think more about the learning from the games i worked on with OGRE
No fixed date set yet,but at some point we should agree and a main list and its prioritization to move on to planning and execution, but that doesn't mean that additional features ca not be discussed or implement then ;) .
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: The roadmap to 1.9 and 2.0

Post by Klaim »

Wouldn't modularization of Ogre result in less Singletons too?
User avatar
Brocan
Orc
Posts: 441
Joined: Tue Aug 01, 2006 1:43 am
Location: Spain!!
x 8

Re: The roadmap to 1.9 and 2.0

Post by Brocan »

My little contribution, although my thoughs are said before.

I think that the resource system needs to be modularized. If I've my own resource system for my engine assets, i want to feed ogre with the same resource system. And now it's very difficult to wrap it.

The math implemented in ogre is fantastic. Sometimes i've found the needed of use that on other projects, or even in a game engine where the core doesn't needed to know anything about ogre itself, but including the whole ogre core for use the math classes is unacceptable for me.

As some people suggest before, ogre should be only a render system, the whole helper utils should be modularized. You could provide implementations for demos and so on, but it should be allow developers to write their own implementations if they wish.

I'm not an expert about threading, but i understand that it's difficult that ogre could be enough general to match the implementation of every game engine threading model.

On another hand, i think that ogre must provide a "super cool demo" showing the last AAA techniques supported. I know that ogre is really great, but its hard to convince my boss for using ogre if i can only show a bunch of graphically out of dated demos, and plus if after that he looks an UDK, CryEngine or Unity video. (I know that it can't be compared, but ogre has the power to show outstanding graphics, but there is not a single reel for demostrating it)

Cheers!
bstone
OGRE Expert User
OGRE Expert User
Posts: 1920
Joined: Sun Feb 19, 2012 9:24 pm
Location: Russia
x 201

Re: The roadmap to 1.9 and 2.0

Post by bstone »

Not having a solution here but I should mention that before I committed to using Ogre I looked into Crystal Space and very seriously. One of the main reasons for discarding it was it's "everything as a plugin" approach. It was a real mess even for me who ate COM (the inspiration behind their interfacing core) for breakfast for quite a while.

As for getting rid of singletons, well... They were invented for a purpose. Furthermore, the variation used by Ogre provides a nice dependency injection as a bonus. Now what I say is that removing them won't be a smooth ride. You will have to replace them with something and most alternatives will be painful 8)

The roadmap looks good. My pet peeve would be getting rid of RTTI in addition to the aforementioned things. This will cut the binaries size for good which is critical for mobile platforms. It's mainly used for animated values and can be replaced with a simplistic ad-hoc implementation that will use something like GUIDs or even smaller representation for type IDs instead of dumping mangled names of every class and method into the binaries.
User avatar
Lee04
Minaton
Posts: 945
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden
x 1

Re: The roadmap to 1.9 and 2.0

Post by Lee04 »

Plugify the code path of DiretX9 specifics and DirectX11 specifics, so we can have a REAL clean move to DirectX11 with no DirectX9 compremisses in the pipe.

I am also intrested in the streamed viewports offered by NVidias Grid Kepler GPUs. Where no screens need to be connected to the GPU, but rather four (up to eight with SLI) screens can be streamed where ever on Internet.

I think this technology will be BIG on all the plattforms like Android, IPad, web pages and mobile devices as well on PC's with not so much graphics preformance.

It's an alternative way to support many platforms.
Ph.D. student in game development
LarsW
Gnoblar
Posts: 11
Joined: Thu Dec 28, 2006 11:42 pm
Location: Berlin, Germany

Re: The roadmap to 1.9 and 2.0

Post by LarsW »

Hi,

Handling the modularization is always a complicated task, there are simple things to modularize and make them available as plugins. The rendering Systems for example, you control them by using the Ogre supplied functions but you never know which rendering system is used. Maybe some functions will return errors, because a feature is not available.
If you have a plugin where no interface in Ogre would exist it would be more cumbersome to use (what many of the above posters are afraid of i suppose).

I also like the concept of being able to do nearly everything with Ogre, including Overlays, particles, animations and so on. But if it would be possible to detach the implementation of many features, like it is done for the particleFX where all base functionality is there, gives the opportunities to reduce code and dependencys without sacrificing usability.

When taking the Overlays for example, it would mean that classes like the OverlayManager, Overlay and OverlayElement would still exist. But the parsing for Overlay Scripts, and concrete Implementations of Overlays like the OverlayPanel and most of the Element are moved to a plugin. Same for fonts, that should be kept in, but without support for truetype fonts without the plugin.

Oh and wenn getting rid of freeimage i would get rid of all imageformats that rely on external libs (except a simple bmpreader or inclusion of nanojpeg). All Freeimage formats would then be in one plugin, and if somebody only needs one format he writes a plugin for a single image format.

Just "removing" the backends and keeping the interfaces would ensure compatibility with existing applications, they just need to add some more plugins to plugins.cfg.

@Brocan: showing of the cool features is very important, but why not show the projects that have been done with Ogre. There must be many Videos on youtube showing Ogre made games, ask those people if sequences can be used and make a short film with some of the best sequences... but who has time for videoediting while programming.

greetings
Lars
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: The roadmap to 1.9 and 2.0

Post by jacmoe »

I don't agree: overlays and fonts should be removed from the core completely.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: The roadmap to 1.9 and 2.0

Post by CABAListic »

Just to clarify: Modularisation does not mean to turn stuff into plugins (unless it is actually suitable for that; the material script system e.g. might be)! It means moving certain functionality into separate libraries (components), like the new Terrain and Paging system. The primary change for the user would be that he has to link to additional libraries; interfaces don't necessarily change, except perhaps that you may need to call a registration function for the particular subsystem or that instances are no longer created by e.g. Ogre::Root or a SceneManager.
We definitely do not intend to hide the actual interface behind some plugin general interface, that's just awful.
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: The roadmap to 1.9 and 2.0

Post by Klaim »

bstone wrote: As for getting rid of singletons, well... They were invented for a purpose. Furthermore, the variation used by Ogre provides a nice dependency injection as a bonus. Now what I say is that removing them won't be a smooth ride. You will have to replace them with something and most alternatives will be painful 8)

I think you misunderstood me or I was not clear so let me explain what I was thinking:

There is a need for singleton for the root because that way you have only one access to one system that represent the "graphic rendering" layer of the context. Now, the root hold all the other systems. If there is some of those systems that become optional, then you have to register them in the root.
Then there is no point in having those modularized systems as singleton (like the resource system). You should just have one attached to the root (maybe managed by it, with somehting similar to std::unique_ptr if possible in C++03) and then all your accesses are through the root interface; or directly by manipulating your specific implementation of a module.

So as those versions are interface breaking anyway, and the fact that most of the systems don't need to be singleton (only root needs to be), then I think if the modularization happen this way; it might benefit some people.

But that's a minor sidenote. Just making OgreMain meaner, having a better or different resource system and having maths isolated would be already very great to me.
User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: The roadmap to 1.9 and 2.0

Post by jacmoe »

Root is a convenience facade class which works great as a singleton.
The rest of Ogre doesn't need to use singletons at all.
You can use Ogre without using Ogre::Root.
It would be a major undertaking to de-singleton-ify Ogre, but I guess it has to be done.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Post Reply