Here is my proposal for GSoC:
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.
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).
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.
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.
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: 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.
- Ogre 2.0: O(1) insertion, removal and contiguous memory iteration
- Ogre 2.0 is up to 3x faster
- Good bye AxisAlignedBox, Hello Aabb
- Overview on how Memory Managers work in Ogre 2.0
- Shadow mapping nightmare
- Shadow mapping... Oops
- Changing how lights are bound in forward passes
- Ogre 2.0 Porting Manual DRAFT (Last updated 2013-10-11) - Mirror 2. For those interest in the source, here's in ODT format