[GSoC 2013 - accepted] Ogre 2.0

Threads related to Google Summer of Code
Post Reply
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

[GSoC 2013 - accepted] Ogre 2.0

Post by dark_sylinc »

Edit: Repository Fork

Hi everyone!
Here is my proposal for GSoC:

Motivation
As I've posted in the main Ogre 2.0 thread, Ogre is aging. And it's slow. Very slow. In circa 2008 we were the best free alternative and had comparable features. Today we're indirectly competing with game engines (Unity, CryEngine, UDK 4) and can no longer compete in price. We give Developers access to the source code, but as a downside, our features & performance is below of today's industry standards.
I'm always wanting to contribute to open source communities, and I feel I can a lot for Ogre. My devotion for Ogre doesn't start with GSoC and doesn't end with it; but it's nice that since I'm a student, Google is giving me the chance to focus myself full time on Ogre alone.

Project
The scope of the project is to bring Ogre to 2.0 state.
As the wiki roadmap says, I would be integrating the Array math component I've been developing in my spare time to Ogre core, writing a major overhaul of Entity, SubEntity, SceneNode, and Node for cache friendly layout, refactoring the SceneManager for much clever scene update, culling and rendering.

Didn't you say Ogre 2.0 was too big for GSoC?
I did say that. But my initial idea was to conceive Ogre 2.0 as a start-from-scratch project. Gladly, I was persuaded against that, and community feedback allowed me to prepare together a plan (the one in the wiki) that involves progressively converting the current code base in steps, not as a single giant project. This way it's much more feasible and can be doable for a GSoC.
Note that what I originally envisioned as the big undertaking "Ogre 2.0" in my slides, would now be Ogre 3.0; versions 2.0 and 2.1 address the major concerns that is now crippling our potential while 2.3 onwards focuses more on adding new features. This GSoC project does not take into consideration 2.3, 2.4, 2.5; and only a part of 2.1 might be made if the 2.0 plan takes less than what's on schedule (unlikely).

Proposal Timeline
Bonding period (27 May – 17 June):
[*]Actively interact with my mentor and Ogre3D community to discuss final details of my intended implementation. Some details can elude me, for example regarding Android & iOS devices which are very important to Ogre's future.[/list]

Official coding time starts (17 Jun – 2 Aug 2013):
First work to do is to implement the main code changes: Memory & Hierarchy management as well as transform math.
  • Stage 1 (17 Jun – 23 Jun): Integrate ArrayMath into Ogre core. Implement unique ID system to replace unique name system. Create flexibility levels.
  • Stage 2 (24 Jun – 30 Jun): Refactor new Node & SceneNode class. Remove unneeded virtuals, use a Transform class that holds all SoA (Structure of Arrays) pointers. Manage their memory allocation according to their parent-child relationship (handle attach and detachments). Implement basic SIMD UpdateAllTransforms function (single threaded).
  • Stage 3 (1 Jul – 14 Jul): Refactor Entity, SubEntity and it's base classes (MovableObject & Renderable). Keep each Entity & Subentity SoA memory (a cache of the world matrix + bounding sphere + aabb) contiguous organized by render queue ID. Implement basic SIMD FrustumCulling function (single threaded).
  • Stage 4 (15 Jul – 21 Jul): Copy the original Ogre::Node and rename it to "Ogre::OldNode". Ogre::Bone will derive from this, as animations and skeletons aren't yet ready. Modify AutoParams to take the World Matrix from the new memory model.
  • Stage 5 (22 Jul – 2 Aug): Refactor SceneManager's main _renderScene so that transform and animation is removed from the loop. Prepare everything to have a working dll that can run a basic demo.
Mid-term deadline (2 Aug):
At this point Ogre will be in compilable state. Many features will be broken and therefore disabled (Compositor, RibbonTrails, Billboards, InstanceManager, possibly ManualObject & SimpleRenderable) but the core system will be up and running, and be useful to test performance and find any hidden bottleneck. Most demos won't work (may not even compile) so a separate quick demo will be written.

After mid-term (2 Aug – 16 Sept 2013):
Past this point, the hard part has already been done, it's time to do the 10% (the details!)
  • Stage 6 (2 Aug – 8 Aug): Restore broken stuff. RibbonTrails, Billboards, InstanceManager, ManualObject & SimpleRenderable.
  • Stage 7 (9 Aug – 18 Aug): Implement a new null Compositor. Such as in the slides, it has to manage all RenderTargets, dispatch them appropiately with read-only thread safety, and manage the RenderQueues afterwards. It has also be able to request the SceneManager which RenderQueues are going to be used. A full blown compositor is scheduled for 2.1b and thus not part of this GSoC
  • Stage 8 (19 Aug – 25 Aug): Write the Mesh partitioner. For multiple practical reasons, RenderQueue lives in MovableObject while it is mostly a Renderable property. So if a Mesh wants to have multiple sub meshes with different RenderQueues, it won't be possible (this is already a problem in 1.x, where a patch workarounded a solution). The Mesh Partitioner is just a helper that will split the submeshes into one Mesh per RenderQueue so that the user can spawn all of them at the same time and still get the desired results.
  • Stage 9 (26 Aug – 1 Sept): Write a ThreadManager abstraction layer with a Windows implementation and thread FrustumCulling and UpdateAllTransforms.
  • Stage 10 (2 Aug – 16 Sept): Fix any left over, fix bugs. If there's enough time, convert Bones to a more cache friendly memory layout and implement a proper UpdateAllAnimations.
Any remaining time will be used for overall testing, bug fixing, and implementing whatever is on the wiki that was not included here.

Suggested ‘pencils down’ (16 Sept):
Ogre 2.0 will be ready for testing and can get prepared for release. Take note that Ogre 2.1b will be close in features to that of current Ogre 1.8 branch; therefore 2.0 must be treated more of a "sneak peek" of what's coming. I was inspired by Blender's approach of redesigning it's 2.49 interface by releasing the "use at your own risk" 2.5x branch, and finally releasing stable software in branch 2.6x

Why I’m the one for the project
I've already made big contributions in the past: I'm also the author of Ogre Meshy, one of the most popular mesh viewers for Ogre. I'm the one who wrote the 177-slides long document on how Ogre 2.x should be redesigned, I have real world experience working with Ogre, and a very deep knowledge of it's inner workings. I'm always up to date with the latest game industry trends, cpu & gpu architecture details; I'm experienced in scalable multithreaded design (both of my games Derby Attack! and Distant Souls prove it).
As for my student background, I'm studying Accountancy (yes, as in Certified Public Accountant) at Universidad Nacional de Mar del Plata, Argentina. And while this seems a weird and irrelevant career, actually in my Country it's a full-featured one (5 years) and I've had there Algebra, Calculus (Differential & Integral, Taylor Series), Statistics, Matrix Algebra, Conics; all relevant topics to CS related fields. Of course, I'm also self-taught (for instance I already knew Matrix Algebra when I was in Uni) and have a vast understanding of other important stuff such as Quaternion Algebra, Fractals, Complex Numbers etc.

So, all I'm trying to say, I'm fit for this undertaking, and I'm very fast writting code that works reliably, always as long as the plan/roadmap has already been done and designed, which is the case.

Update: Resources: View them Offline: Porting manual NEW!:
Last edited by dark_sylinc on Wed Oct 23, 2013 12:09 am, edited 12 times in total.
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: [GSoC 2013] Ogre 2.0

Post by Wolfmanfx »

Great proposal!
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: [GSoC 2013] Ogre 2.0

Post by jacmoe »

If anyone can pull this off, it's you! :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
Pulas
Halfling
Posts: 61
Joined: Sat Oct 29, 2011 9:39 am

Re: [GSoC 2013] Ogre 2.0

Post by Pulas »

Great proposal, I think this is somthing we very need.
caseybasichis
Greenskin
Posts: 100
Joined: Wed Jan 25, 2012 7:50 pm
x 1

Re: [GSoC 2013] Ogre 2.0

Post by caseybasichis »

Drooling.
User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2703
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 51

Re: [GSoC 2013] Ogre 2.0

Post by syedhs »

I think the actual question is who will be the mentor.. :mrgreen:
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
Xavyiy
OGRE Expert User
OGRE Expert User
Posts: 847
Joined: Tue Apr 12, 2005 2:35 pm
Location: Albacete - Spain
x 87

Re: [GSoC 2013] Ogre 2.0

Post by Xavyiy »

Wow Matías, just wow.

Can't wait to see all this being done!
Owen
Google Summer of Code Student
Google Summer of Code Student
Posts: 91
Joined: Mon May 01, 2006 11:36 am
x 21

Re: [GSoC 2013] Ogre 2.0

Post by Owen »

I like the "OgreArrayMath" component you're proposing, mostly, but have one query:

Would it not make sense to define types such as "V4SF", "V2DF", etc, wrapping the SSE, Neon, Altivec, etc, types in order to avoid duplicating mostly the same code for each SIMD implementation?

Heck, I'm not even sure if things should be any more complex than e.g.

Code: Select all

#include <xmmintrin.h>
namespace Orge { namespace SIMD {
typedef __m128 V4SF;
inline V4SF Spread(float f) { return _mm_set1_ps(f); }
inline V4SF Add(V4SF l, V4SF r) { return _mm_add_ps(l, r); }
// etc
}}
(Though my own temptation - probably because I have a tendency to lean too far towards abstraction - would be to implement a templated Vector type in the form "Vector<float, 4>" , and an adapter implementing "Vector<double, 4>" in terms of "Vector<double, 2>", so as to avoid having to duplicate code for the double/float case)
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013] Ogre 2.0

Post by dark_sylinc »

Owen wrote:I like the "OgreArrayMath" component you're proposing, mostly, but have one query:

Would it not make sense to define types such as "V4SF", "V2DF", etc, wrapping the SSE, Neon, Altivec, etc, types in order to avoid duplicating mostly the same code for each SIMD implementation?
(...)
(Though my own temptation - probably because I have a tendency to lean too far towards abstraction - would be to implement a templated Vector type in the form "Vector<float, 4>" , and an adapter implementing "Vector<double, 4>" in terms of "Vector<double, 2>", so as to avoid having to duplicate code for the double/float case)
I'm not sure if I follow your query.
In OgreArrayMath, there are three relevant macros: OGRE_DOUBLE_PRECISION, OGRE_CPU & ARRAY_PACKED_REALS

OGRE_CPU is used to determine whether we should use SSE, Neon, Altivec, or plain C (which is cross platform). This is evaluated in each header. See OgreArrayVector3.h, it redirects to "SSE2/Single/OgreArrayVector3.h". On ARM, it would redirect to "Neon/Single/OgreArrayVector3.h" (not written yet)

OGRE_DOUBLE_PRECISION is used to determine whether use 64-bit or 32-bit floating point precision. When absent, ArrayReal gets typedef to __m128; when present ArrayReal is __m128d; the same way "Real" gets typedef to either float or double.
It's also used to determine whether we redirect the header to "SSE2/Double/OgreArrayVector3.h" or "SSE2/Single/OgreArrayVector3.h"

ARRAY_PACKED_REALS is used to determine how many floats are packed together. In the case of SSE2 single-precision, it's 4. In SSE2 double-precision it's 2. Neon for example allows to operate on 2 single precision floats or 4. I guess this choice has to do with some arm having shorter cache line sizes.
Theoretically we could still use SSE2 intrinsics with a ARRAY_PACKED_REALS of 1, just because we're able to use intrinsics (i.e. force a maxss, minss & conditional moves which are badly supported in many compilers).

Modifying ARRAY_PACKED_REALS is mostly automatic if the SIMD architecture supports it. i.e. For SSE2 single precision set this to 4, for SSE2 double precision, set this to 2.

Sure, for each architecture (SSE, Neon, Altivec) we need to "duplicate code" and write two versions for each: One with OGRE_DOUBLE_PRECISION, one without.
However any alternative (using macros, templates, etc) has the same problem: Intrinsics are very platform specific.
Unfortunately, doing "Vector<double, 2>" won't automatically produce the code for you either. You'll still have to write the template specialization because <float, 4> uses _mm_add_ps, <float, 1> uses _mm_add_ss, <double, 2> uses _mm_add_pd, and <double, 4> uses _mm_add_sd. Same happens with all other archs (Neon, Altivec)
Fortunately, most intrinsics are the same, which means it's mostly copy paste, then Find & Replace. Sub-optimal, but there's no standard way of doing it.

So, it's the same problem, same solution. Just different syntax really. To maximize performance, most ArrayVector3's, ArrayQuaternion's & Co. functions are written directly in intrinsics (i.e. _mm_add_ps instead of "x + x"). These are sensitive, highly used, very low level (they're PODs!) structures where micro-optimization actually matters.

The idea is that you can use ArrayVector3 with operator overloading (i.e. myResult = myVector1 + myVec2 is readable) but it's dangerous when we do this at the __m128 data-type level (i.e. implement ArrayVector3::normalize() as "x /= sqrt( x * x + y * y + z * z )" instead of using intrinsics)
Furthermore there are some platform specific operations that are very hard or unintuitive to use without intrinsics and just operator overloading, such as reciprocal square root w/ newton raphson approximation, which is an invaluable op to calculate normalize(). Using operator overloading could result instead in one of the most expensive SSE2 instructions: divps

We're also targetting a very broad range of architectures and compilers; some of them are relatively recent. While some compilers (even from the same vendor & version!) do fine while optimizing the code, other compilers do a terrible job.

Now, if your query was "What if I want to use ArrayVector3_SF & ArrayVector3_DF at the same time?", then my answer is:
1. The official "ArrayVector3" should obey OGRE_DOUBLE_PRECISION. I don't want memory corruption problems because a pointer was casted to the wrong type (it was a pointer floats, ArrayVector3 was in double precision. Always feed a pointer of Reals, because that's what you should be using all the time except where impossible)

2. Modifying the code is very easy. We just rename each implementation to something like ArrayVector3_SF & ArrayVector3_DF, then typedef one of them as ArrayVector3 depending on double precision macro. Because this is easy to change, I prefer to avoid direct access until real world proves this is needed or very useful. Doing this has it's drawbacks, because we would need to be constantly verifying that all implementations (ArrayVector3_SF & ArrayVector3_DF) have a portable behavior. It's easier to guarantee a portable behavior when all macro parameters are aligned, than when regardless of the macros, we may have one completely unsupported type for X architecture hanging around (i.e. what happens if we use ArrayVector3_DF on an architecture that doesn't support 64-bit float?)

3. Power users that ignore cross platform issues and want to use both types can directly include the headers under a namespace. It's almost everything inline code, so it should work.

Notice that this applies to what is considered "low level" stuff (ArrayVector3, ArrayQuaternion, ArrayMatrix4) due to it's high utilization. Look instead at ArrayAabb which I consider at one level higher, some of it's functions (getMaximum, merge) use operator overloading from ArrayVector3; while other functions (transformAffine & contains) mix op. overloading and use intrinsics where the code is new.
Owen
Google Summer of Code Student
Google Summer of Code Student
Posts: 91
Joined: Mon May 01, 2006 11:36 am
x 21

Re: [GSoC 2013] Ogre 2.0

Post by Owen »

Perhaps my point got lost in some of the other commentary of my post.

My main point was: The code to implement a given algorithm on top of SSE, NEON or AltiVec is going to look very similar on the basis that they're all architectures with 128-bit vectors of 4 32-bit floats. Surely with a very transparent abstraction (like my first suggestion), you can reduce the code duplication when adding support for multiple architectures without any performance impact?

(Not to say that I don't expect differences in the code between architectures; but it should be confined to minutae)
TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 65

Re: [GSoC 2013] Ogre 2.0

Post by TheSHEEEP »

Very good idea. I like the proposal.
My site! - Have a look :)
Also on Twitter - extra fluffy
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: [GSoC 2013] Ogre 2.0

Post by spacegaier »

A big thumbs up! This is basically already approved from my point of view ;) .
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
Mind Calamity
Ogre Magi
Posts: 1255
Joined: Sat Dec 25, 2010 2:55 pm
Location: Macedonia
x 81

Re: [GSoC 2013] Ogre 2.0

Post by Mind Calamity »

Well good luck, as it seems the OGRE community accepts this. (Including me, I'm very excited about this project) Now all that's left is for Google to accept it. :)
BitBucket username changed to iboshkov (from MindCalamity)
Do you need help? What have you tried?
- xavier
---------------------
HkOgre - a Havok Integration for OGRE | Simple SSAO | My Blog | My YouTube | My DeviantArt
User avatar
boyamer
Orc
Posts: 459
Joined: Sat Jan 24, 2009 11:16 am
Location: Italy
x 6

Re: [GSoC 2013] Ogre 2.0

Post by boyamer »

Approved here too, i really like the new approach you've just explained.
User avatar
duststorm
Minaton
Posts: 921
Joined: Sat Jul 31, 2010 6:29 pm
Location: Belgium
x 80
Contact:

Re: [GSoC 2013] Ogre 2.0

Post by duststorm »

Wow, this is a truly well planned out proposal. It shows that this has been thought out for some time.
I think this is what Ogre needs now most, and I'm very excited to see that you want to spend a summer full-time on making it a reality.

I wish you a lot of success!
Developer @ MakeHuman.org
User avatar
ekt
Gremlin
Posts: 150
Joined: Thu Apr 01, 2004 5:55 pm
x 4
Contact:

Re: [GSoC 2013] Ogre 2.0

Post by ekt »

[s]This might be the single best thing for ogre's evolution happening in a while[/s]
That's the second biggest proposal head I've ever seen!
Last edited by ekt on Mon Apr 29, 2013 3:05 pm, edited 1 time in total.
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: [GSoC 2013] Ogre 2.0

Post by jacmoe »

Well.. let's see.
Everybody seems to have sold the skin of the bear not yet shot. Myself included. ;)

It's not realistic to believe that Ogre will be reborn by this GSoC project - one single (awesome) guy in 6 months time - but I sincerely hope that this project will be the (major) nudge that Ogre3D needs as a project to move forward and have a good chance of becoming Ogre 2.0.

Because without this project, it would have been even less realistic. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.
User avatar
ekt
Gremlin
Posts: 150
Joined: Thu Apr 01, 2004 5:55 pm
x 4
Contact:

Re: [GSoC 2013] Ogre 2.0

Post by ekt »

jacmoe you are right. i've redacted my post
User avatar
Mako_energy
Greenskin
Posts: 125
Joined: Mon Feb 22, 2010 7:48 pm
x 9

Re: [GSoC 2013] Ogre 2.0

Post by Mako_energy »

dark_sylinc,

I have what may be a silly question regarding your planned work with this project. You have gone into great detail regarding the algorithms and internal refactors you have planned, but haven't said as much regarding any changes to the API of the SceneManager class. As a consequence of the algorithms being changed internally, what do you expect to change in the SceneManager API?

Another question that is a bit more direct to my interests, as a consequence of changing the internals/API of the SceneManager, would it be possible to permit MoveableObjects to change ownership from one SceneManager to another?
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5292
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1278
Contact:

Re: [GSoC 2013] Ogre 2.0

Post by dark_sylinc »

Externally, a lot will look pretty much the same (give or take minor details); but there will be some outstanding changes:
  • Render Queue ID is very important. The new values start from 0 (inclusive) up to a preallocated value, which means the user needs to tells us what is his expected "maximum" ID. This will be usually done automatically by looking at compositor scripts, but the new compo mgr won't be until 2.1. Behaviours of Render queues will be quite different in 2.1
  • No names: You can name MovableObjects & Nodes, but they no longer need to be unique and createEntity won't accept a name. If you want named objects, create it first, then call setName(). After analyzing the code, we have a surprisingly high number of duplicated functionality in 1.9 because of two overloads: one accepting a name, another without it.
  • LIFO Order: Create your long-lasting content first. Everything that will last for short periods of time should be created last. This could seriously impact performance of insertion/removals of Entities & SceneNodes. i.e. Create your landscape first, then the city, then it's citizens, then the character, then the enemies & foes, then loot & items.
    Processing the whole scene is expected to be orders of magnitudes faster than it is now, so the possibility that flipping the visibility bool could be faster than removing & reinserting certain objects will be higher than in 1.x
  • Several hint parameters: Before running, user will tell us how many (maximum) entities, nodes they expect to allocate, and eventually how many worker threads they want us to use. While Ogre will be able to handle the case where the maximum is surpassed, it can cost a severe performance impact (expect that frame to stall if the scene is heavy enough).
    Additionally, there are "hard limit" values in case the user wants Ogre to raise exceptions when those limits are surpassed (very useful for console & mobile)
    There are other params to affect the memory behavior during runtime (for example after how many deletions we run a cleanup, think of it as a sort of garbage collector). There's no point in going into detail now because this stuff is constantly evolving, not set in stone.
There's one that needs it's own space:
  • Working Updated positions: As you all know from the slides, _getDerivedPosition will assert if it's not up to date. This affects how you layout your tasks. Example:
    You're running a physics simulation, then copy it's position & rotation to Ogre nodes, and then you call _getDerivedPosition because of whatever you need to do, it's obviously going to assert. If it's just a few nodes, you can replace those calls with the new _getDerivedPositionUpdated, it will just work. However those are slow on simd builds and if you need to do it on a big number of nodes, you need to change the behavior of your program.
    I'll be able to tell the details after 2.0 is ready; but basically you will have to change the behavior of your program so that after copying all positions & rotations to Ogre nodes, you call SceneManager::updateAllTransform; then you can work using _getDerivedPosition as you please. When rendering, a special calling sequence needs to be performed so that the transforms aren't updated again.

    There are more complex cases, for example what happens if I use _getDerivedPosition to alter the position & rotation of another Node (i.e. auto tracking nodes), because that node is now dirty and I should either call _getDerivedPositionUpdated to force updating that single object, call updateAllTransform again. And if the dependency is deeper: "node0->setPosition(...) -> node1->setDirection( node0->_getDerivedPosition ) -> node2->setDirection( node1->_getDerivedPosition )" the multiple calls to updateAllTransform can hurt.
    There's something I have in mind to solve that situation, which implies tagging the first nodes as part of a group, the second nodes as part of another group, and the third as another group; then each call to updateAllTransform iterates through all the nodes that aren't up to date.
Another question that is a bit more direct to my interests, as a consequence of changing the internals/API of the SceneManager, would it be possible to permit MoveableObjects to change ownership from one SceneManager to another?
Good question, I haven't thought much about it, but MovableObjects have to allow migrating from one MemoryManager to another, and each SceneManager has it's own, so it ought to be possible (LIFO order hint still applies).
How fast that is depends on whether you respect LIFO order and other memory parameters. There are many things that come into play here (including materials, shadow stencil vertex buffers, etc) that I haven't considered yet, so don't take this answer as definitive.

I don't know the reason you need multiple managers, but if it's just visibility (i.e. having two parallel worlds); in 2.0 you might prefer using visibility flags; and have one viewport only see the first 16 bits, and the other viewport the other 16 bits.
This is possible in 1.x as well, but I'm not sure it scales too well.

If you want to see how MemoryManagers work, take a look at ArrayMath repo. I think I haven't pushed my last revision where I spotted quite a few bugs, so take take it with a grain of salt. But basically it preallocates a big chunk of memory, and requests work in LIFO order. When removing something at a random place (except the last one), it saves the slot in a stack. When requesting a new node back, the slot is removed from the stack and reused; therefore all creation & insertions take O(1) complexity.
If the stack grows too big, a cleanup is performed, which may take up to O(N) complexity depending on whether those slots where at the beginning or at the end. It is during cleanups when your respect for LIFO really gets noticed. (you can disable cleanups by setting -1, which is useful in games like my very own Derby Attack where literally hundeds or even thousand of objects in any random order are frequently created and destroyed over and over again).
User avatar
Mako_energy
Greenskin
Posts: 125
Joined: Mon Feb 22, 2010 7:48 pm
x 9

Re: [GSoC 2013] Ogre 2.0

Post by Mako_energy »

I don't know the reason you need multiple managers, but if it's just visibility (i.e. having two parallel worlds); in 2.0 you might prefer using visibility flags; and have one viewport only see the first 16 bits, and the other viewport the other 16 bits.
This is possible in 1.x as well, but I'm not sure it scales too well.
Yeah, that is pretty much exactly the use case I had in mind. It's good to know it's possible that way with the current system. Although implementing parallel worlds like that seems to be more limiting than having moveable objects change ownership. For example if I wanted to have different SceneManager types (Default and Octree for example) managing the scenes for the two worlds. I should also clarify that I don't have a game in mind for this functionality, rather I am writing an engine/framework and I want to keep the options open anywhere and everywhere possible. If I can avoid it I'd rather not make assumptions for the game makers.
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: [GSoC 2013 - accepted] Ogre 2.0

Post by spacegaier »

Congratulations! This proposal has been selected as one of our this year's GSoC projects!

Best of luck and happy coding :)!


Mentor: Murat Sari <wolfmanfx>
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...
PhilipLB
Google Summer of Code Student
Google Summer of Code Student
Posts: 550
Joined: Thu Jun 04, 2009 5:07 pm
Location: Berlin
x 108

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by PhilipLB »

Yay, congratz. :)
Google Summer of Code 2012 Student
Topic: "Volume Rendering with LOD aimed at terrain"
Project links: Project thread, WIKI page, Code fork for the project
Mentor: Mattan Furst


Volume GFX, accepting donations.
ricardog
Gnoblar
Posts: 2
Joined: Sun May 26, 2013 9:50 am

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by ricardog »

Great ideas and congratulations! I have a few comments:
dark_sylinc wrote:Implement unique ID system to replace unique name system.
By that do you mean using integers instead of strings to identify and look for objects? That's gonna be a nice performance improvement indeed. While you're at it, I think some maps (such as the MovableObjectMap in SceneManager) could be changed to HashMap. That would also improve look up time a lot.
dark_sylinc wrote:Write a ThreadManager abstraction layer with a Windows implementation and thread FrustumCulling and UpdateAllTransforms.
Instead of implementing platform-specific code here, I think OpenMP might be a nice cross-platform solution. It doesn't require a separate package such as Boost or TBB and, unlike C++11 threads, it's available on older compilers.
TheSHEEEP
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 972
Joined: Mon Jun 02, 2008 6:52 pm
Location: Berlin
x 65

Re: [GSoC 2013 - accepted] Ogre 2.0

Post by TheSHEEEP »

Congrats :)

Not to build up any pressure, but... This is a really important project :D
My site! - Have a look :)
Also on Twitter - extra fluffy
Post Reply