Split Ogre in OgreCore and Ogre3d

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
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2703
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 51

Re: Split Ogre in OgreCore and Ogre3d

Post by syedhs »

The thing is I can see that Ogre team members would not likely (I think, I am not Ogre team member :mrgreen: ) do this, so this idea can only go forward if there is someone (who presumable have great interest for this feature) step forward and does all the changes needed. I can see the changes can be quite huge - separation of Ogre into core, resource manager etc at first probably doesn't sound too difficult but the changes in the end have to be beneficial ie

1) the high percentage of Ogre users who use Ogre as it is doesn't face difficulties after the modifications.

2) the users who will benefit from Ogre separation do indeed get the benefit. The component they have (non-Ogre) can be plugged in without too much difficulties - it is fair that you shouldn't expect plug and play anyway.

3) Other necessary features like multithreading can be done easily anyway without extra burden to Ogre team and contributors. Eg if Ogre core is multi-threaded, the resource portion should be friendly (ie you can choose to multithread or remain single-threaded).

I think achieving all 3 is quite an uphill task, but I could be wrong.
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Split Ogre in OgreCore and Ogre3d

Post by Zonder »

I would see this as a multi stage process as well.

Somthing like below

1. Rename Ogre to OgreCore
2. Create OgreTools project
3. Move all classes from OgreCore into OgreTools that don't belong in OgreCore (This should ne non breaking no namespace changes)
4. Make a list in order of features to abstract
5. Add Abstarcts / Interfaces namespace (should this be a seperate library??)
6. Create the interfaces for each feature in order that ogre needs
7. Implement 1 feature at a time into OgreTools and OgreCore at the same time from the list

This would probably create alot of individual jobs but you would need to break this down into small chunks to be able to do it
There are 10 types of people in the world: Those who understand binary, and those who don't...
User avatar
Chris Jones
Lich
Posts: 1742
Joined: Tue Apr 05, 2005 1:11 pm
Location: Gosport, South England
x 1

Re: Split Ogre in OgreCore and Ogre3d

Post by Chris Jones »

I'd definitely like to see this happen but sadly won't have time to contribute until my project has reached a place where i can use this.

Could OgreTools be called OgrePlatform (or similar) instead, i don't think "tools" is appropriate.
Add Abstarcts / Interfaces namespace (should this be a seperate library??)
These (where possible) shouldn't be interfaces (virtual functions), they should just be normal function calls.

I don't see why this can't occur gradually, if the project was set up, code/features can be moved across over time.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: Split Ogre in OgreCore and Ogre3d

Post by CABAListic »

Please keep in mind that what you are proposing here is essentially a redesign of Ogre. As such this is a colossal amount of work that would need detailed planning and careful execution. So far, all of the posts in this thread are relatively superficial, not really more than a vague idea.
Don't get me wrong, I like the idea as much as you, but to really work on it we'd need to dig deeper. And it would be work towards an Ogre 2.0.

Realistically speaking, though, I'm not convinced such a major break for Ogre 2.0 will ever happen. I find it more likely that this decoupling of responsibilities in OgreMain could happen in smaller chunks; we might begin with a separate math library as has been requested over and over again. There's also been suggestions to move the script parsing functionality to a separate plugin. I think those are smaller, contained projects which are far more realistic to be happening for Ogre 1.8 or 1.9, and we could continue from there.
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Split Ogre in OgreCore and Ogre3d

Post by Zonder »

Yes it is somthing that has to happend gradually. Just making the decision to have the 2 dlls is the important bit the other dll could be empty but as long as it's there and part of the build. As cabalistic says individual units can then be split out. I don't think I was making my self clear above I was not thinking all at once it was a process that would go over many versions of ogre.
There are 10 types of people in the world: Those who understand binary, and those who don't...
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: Split Ogre in OgreCore and Ogre3d

Post by CABAListic »

The split would not be OgreCore / OgreTools. It would be more like OgreCore / OgreMath / OgreResources / OgreWhatever. Just splitting in half doesn't really make sense if your goal is to reduce individual responsibilities of the libraries ;)
User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
x 13
Contact:

Re: Split Ogre in OgreCore and Ogre3d

Post by sparkprime »

How much stuff would need to be included in order to satisfy the dependencies of the RenderSystems?

I'm thinking things like Pass, Textures, GPUProgram, etc.

I think that collection of stuff would be a good base level API. It would be useful for people who want to implement their own engine at the level of D3D/GL but want the platform abstraction OGRE provides.

On top of that can be scene managers, entities, nodes, cameras, etc. Also another component could be scripting as mentioned.

As for Vector3 and friends, perhaps that can be a level even below the render systems, but I don't care personally either way as I am not interested in using Vector3 outside of ogre.

As for plugins, I don't see any reason to add more plugins. In fact I don't see any reason to keep the existing plugins. All we need is the ability to include and link in a subset of the codebase, which most libraries provide without needing plugins. E.g. Bullet has a math layer, various utilities, optional shapes (gimpact, softbody) a collision layer for just finding out about colliding pairs, and a dynamics layer if you also want to simulate motion. You can link in as much or as little as you want. Very similar to OGRE but much simpler.
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Split Ogre in OgreCore and Ogre3d

Post by Klaim »

The split would not be OgreCore / OgreTools. It would be more like OgreCore / OgreMath / OgreResources / OgreWhatever.
That would be an excellent idea : that would greatly encourage Ogre code modification as it would limit the link time to each module modified instead of whole OgreMain project.
Added to the repo cloning, I think it would make (at least me) a bit more easy to gather energy to try to fix or add something in the Ogre code.

The progressive view of it would be like Qt module splitting : really helping.

That said, those modules would still be required by OgreCore, or could we identify some that could be isolated enough to allow a "lightweight" Ogre setup?
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: Split Ogre in OgreCore and Ogre3d

Post by CABAListic »

Well, the idea would be that OgreCore is self-contained (except for math, perhaps); instead, some (most?) of the other libraries would likely depend on OgreCore.
User avatar
_tommo_
Gnoll
Posts: 677
Joined: Tue Sep 19, 2006 6:09 pm
x 5
Contact:

Re: Split Ogre in OgreCore and Ogre3d

Post by _tommo_ »

Another idea:
to me an API-level retrocompatibilty in an effort like splitting Ogre would be nearly impossible to obtain.
It would be very much like a fork, at least in the near period where it would be really unstable and unreliable.

On the long run retrocompatibilty could be implemented mapping each "Ogre Classic" feature on some other component library, so that a project that just links all of them can use everything the current Ogre has.
OverMindGames Blog
IndieVault.it: Il nuovo portale italiano su Game Dev & Indie Games
User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
x 13
Contact:

Re: Split Ogre in OgreCore and Ogre3d

Post by sparkprime »

_tommo_ wrote:Another idea:
to me an API-level retrocompatibilty in an effort like splitting Ogre would be nearly impossible to obtain.
It would be very much like a fork, at least in the near period where it would be really unstable and unreliable.
Not necessarily, it can be just a build system thing.

Ultimately, we have a set of classes. All we are doing is choosing what directories the source code for those classes lives in, and which libraries those classes are compiled into.

It may be that in the course of restructuring, we discover that there are strange dependencies, e.g. maybe RenderSystem depends on Camera whereas really it just needs a matrix (I have no idea if it currently does or doesn't). In that case we may change some APIs slightly but that should be rare and hopefully not happen at all.
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Split Ogre in OgreCore and Ogre3d

Post by Zonder »

CABAListic wrote:The split would not be OgreCore / OgreTools. It would be more like OgreCore / OgreMath / OgreResources / OgreWhatever. Just splitting in half doesn't really make sense if your goal is to reduce individual responsibilities of the libraries ;)
Yes quite true.

I do like the idea of the core render been seperate. Gives people a base for there own rendering engine without the bloat of the full ogre library may actually make the community grow even more (not that it needs it really :))

Thinking about it the renderer is probably the easier part to split as it's right at the top/bottom depending on how you see abstraction :)
There are 10 types of people in the world: Those who understand binary, and those who don't...
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: Split Ogre in OgreCore and Ogre3d

Post by jacmoe »

:)

That's actually oxymoronic : replacing the rendering engine of Ogre with your own ... :wink:
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Split Ogre in OgreCore and Ogre3d

Post by Zonder »

Yeah it is a bit contraditory :wink:
There are 10 types of people in the world: Those who understand binary, and those who don't...
User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
x 13
Contact:

Re: Split Ogre in OgreCore and Ogre3d

Post by sparkprime »

Not really. If you give it a better name that 'rendering engine' it becomes perfectly reasonable:

Rendersystem portability layer
|
Render pipeline
|
Scene graph
|
Scripting

It is perfectly reasonable for someone to implement their own render pipeline that is highly threaded, or a scene graph that is not based on SceneManager, just as it is for them to replace the render system with some new thing.

The reality may be that these things are too tangled to make this possible, but the theory is sound.
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Split Ogre in OgreCore and Ogre3d

Post by Zonder »

we wen't saying it isn't valid. we just mean you come here for a rendering engine but then implement your own on top of the 3D API abstraction layer :)
There are 10 types of people in the world: Those who understand binary, and those who don't...
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: Split Ogre in OgreCore and Ogre3d

Post by jacmoe »

Pipeline is a good word for it. :wink:

If you people could cook up possible library names and what goes into them and how they're connected, it would probably help it move towards possible realisation. :)
/* 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: Split Ogre in OgreCore and Ogre3d

Post by CABAListic »

Keep in mind, though, that the probability of realisation increases considerably if suggested splits do not require *major* rewrites/redesign. Ogre has been designed as a higher-level 3D engine, so the likelyhood of it becoming a lower-level abstraction layer with additional tools on top of it is not very large, imho. (It's also not what I would personally want Ogre to be.)
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Split Ogre in OgreCore and Ogre3d

Post by Zonder »

I think this is more coming about because of the phone market and needing libraries that can be optimised to the apps needs. Phones won't get huge amounts of of ram and any ram going should be for textures!! :). Ogre is a beast in size but that is fine for the desktop/laptop/arcade machine market not the lower hardware and been a high level rendering engine you currently can't chop out the bit you don't need. This also effects consoles as well thinking about it
There are 10 types of people in the world: Those who understand binary, and those who don't...
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: Split Ogre in OgreCore and Ogre3d

Post by jacmoe »

Right.

Look in http://code.google.com/p/gamekit/ I am sure I saw a TinyOgre folder in there somewhere.. :)

<edit>
It's OgreLite:
http://code.google.com/p/gamekit/source ... 2FOgreLite
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
Zonder
Ogre Magi
Posts: 1168
Joined: Mon Aug 04, 2008 7:51 pm
Location: Manchester - England
x 73

Re: Split Ogre in OgreCore and Ogre3d

Post by Zonder »

jacmoe wrote:Right.

Look in http://code.google.com/p/gamekit/ I am sure I saw a TinyOgre folder in there somewhere.. :)

<edit>
It's OgreLite:
http://code.google.com/p/gamekit/source ... 2FOgreLite
good catch :)

see people want it and are doing it lol
There are 10 types of people in the world: Those who understand binary, and those who don't...
User avatar
voyvf
Kobold
Posts: 28
Joined: Sat Jul 04, 2009 4:01 am
Location: United States
x 2
Contact:

Re: Split Ogre in OgreCore and Ogre3d

Post by voyvf »

I've already got way too much on my plate to contribute, but I would love to see this happen. :D
User avatar
nec
Gremlin
Posts: 175
Joined: Fri Sep 29, 2006 5:56 pm
Location: Rosny Sous Bois, France
x 11
Contact:

Re: Split Ogre in OgreCore and Ogre3d

Post by nec »

OgreCore should only be the default implementation of a virtual system interface set. So you can use as it is or you can override a part of it.

Exemple :

virtual system define interfaces for
- Memory Access
- File Access
- Timers
- ... Other system relative concepts.

There could be one OgreCore for each supported platform which would implement the whole set of system abstraction interfaces. If i want to use my own memory manager, i can implement the memory management interfaces and give it to OgreCore which override the default implementation.
You all know how hard it is to gather all middlewares under the same memory manager. it might be easier if all middlewares made the abstraction of the system.

Ideally Ogre should only focus on 3d graphics services so it should not come with OIS and stuff like that and should be abstracted from the system. But as Ogre offert many samples to make the learning easier it becomes more like a GameEngine with many missing parts (sound, network, ...).
So to avoid Ogre to become a full game engine it should abstract some parts a little bit more to made it more pluggable.

In few words : i should be able to remove all system parts from ogre easily to put mine. So moving them to OgreCore could allow demo sample to use OgreCore default implementation and allow me to use my own implementation if i want to.
CABAListic
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2903
Joined: Thu Jan 18, 2007 2:48 pm
x 58
Contact:

Re: Split Ogre in OgreCore and Ogre3d

Post by CABAListic »

Uhm, OIS is not a part of Ogre; it's only used in the samples, Ogre isn't tied to it in any way whatsoever. Just to avoid confusion...
che1404
Gnoblar
Posts: 18
Joined: Sun Mar 18, 2007 4:50 pm

Re: Split Ogre in OgreCore and Ogre3d

Post by che1404 »

Hi there!
I found C4 Engine architecture a great example to follow...
Have a look!
http://www.terathon.com/c4engine/architecture.php

Regards,
Roberto.
Post Reply