Split Ogre in OgreCore and Ogre3d
- syedhs
- 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
The thing is I can see that Ogre team members would not likely (I think, I am not Ogre team member ) 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.
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
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
- 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
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
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...
- 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
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.
I don't see why this can't occur gradually, if the project was set up, code/features can be moved across over time.
Could OgreTools be called OgrePlatform (or similar) instead, i don't think "tools" is appropriate.
These (where possible) shouldn't be interfaces (virtual functions), they should just be normal function calls.Add Abstarcts / Interfaces namespace (should this be a seperate library??)
I don't see why this can't occur gradually, if the project was set up, code/features can be moved across over time.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: Split Ogre in OgreCore and Ogre3d
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.
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.
- 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
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...
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: Split Ogre in OgreCore and Ogre3d
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
- 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
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.
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.
- 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
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.The split would not be OgreCore / OgreTools. It would be more like OgreCore / OgreMath / OgreResources / OgreWhatever.
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?
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: Split Ogre in OgreCore and Ogre3d
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.
- _tommo_
- Gnoll
- Posts: 677
- Joined: Tue Sep 19, 2006 6:09 pm
- x 5
- Contact:
Re: Split Ogre in OgreCore and Ogre3d
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.
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.
- 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
Not necessarily, it can be just a build system thing._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.
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.
- 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
Yes quite true.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
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...
- jacmoe
- 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
That's actually oxymoronic : replacing the rendering engine of Ogre with your own ...
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- 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
Yeah it is a bit contraditory
There are 10 types of people in the world: Those who understand binary, and those who don't...
- 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
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.
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.
- 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
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...
- jacmoe
- 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
Pipeline is a good word for it.
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.
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: Split Ogre in OgreCore and Ogre3d
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.)
- 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
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...
- jacmoe
- 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
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
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.
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
- 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
good catchjacmoe 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
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...
- 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
I've already got way too much on my plate to contribute, but I would love to see this happen.
- 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
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.
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.
-
- OGRE Retired Team Member
- Posts: 2903
- Joined: Thu Jan 18, 2007 2:48 pm
- x 58
- Contact:
Re: Split Ogre in OgreCore and Ogre3d
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...
-
- Gnoblar
- Posts: 18
- Joined: Sun Mar 18, 2007 4:50 pm
Re: Split Ogre in OgreCore and Ogre3d
Hi there!
I found C4 Engine architecture a great example to follow...
Have a look!
http://www.terathon.com/c4engine/architecture.php
Regards,
Roberto.
I found C4 Engine architecture a great example to follow...
Have a look!
http://www.terathon.com/c4engine/architecture.php
Regards,
Roberto.