Abstract
Material switching, and specially texture switching, is one of the most expensive operations in terms of performance in graphics applications. Today is usual to find an increasing number of textures in applications, specially because of their added versatility thanks to the pixel shaders (normal maps, specularity maps...).
As a solution to the large number of texture switches appear the texture atlas concept, packing in a single texture a number of subtextures. This lets minimizing the number of switches, being only one where there were many before. nVidia already offers tools for building texture atlases, though their functionality is limited as it's not oriented to a particular application.
As a direct application to OGRE, it's intended to develop a number of functionalities to allow the OGRE engine support texture atlas features directly. This will allow OGRE users to benefit from the use of texture atlases through a custom solution, letting, for example, merging materials or adapt meshes directly.
Detailed Description
The main goal of this project is to give every OGRE user the chance to benefit from the use of texture atlases. To do this, both an API and a tool that makes use of this API offline will be delivered. To simplfy its usage and let batched workflows, an scripting facility will be added as well.
Thanks to the use of texture atlases, OGRE users will be able to enhance their applications' performance, thanks to the decrease of texture switching in the graphics card, solving many of the inherent problems, providing, at least, the features that offer the
nVidia tools.
In this case, OGRE will receive some extra advantages as this project is targetted to this particular engine. As an API is provided, will be possible to access all the features in run time.
Additionally, this project wouldn't be limited to the atlas construction itself, but adapting existing meshes so that they can make use of them directly, or even merging materials in certain cases. This makes it the perfect partner of OGRE's static geometries.
In this case, other existing tools are many steps behind when OGRE is the chosen graphics engine.
Will be possible to use different texture packing algorithms in a flexible and extensible way that opens a point to add new algorithms in an easy way, plus specialised mipmap generation, as well as specialised texture compression (ie, use of 3Dc for normal maps only atlases). Also will be studied the possibility of reaching a compromise solution between mesh tesellation and texture wrapping.
As a side goal, this is a great chance to help the open-source community, contributing a whole project, and an opportunity to learn how a real-life development process is.
[Development methodology]
The chosen development methodologies are Scrum and Test-driven development. The development cycle will be divided in 14 days sprints as suggested by Scrum. At the end of each sprint a report will be released with the analysis of the ending sprint, so that the next can solve the found cons, as well as empowering the pros.
Regarding TDD, unit tests will be done when possible, to ensure the design by contract. Before finally closing a task, regression tests will be run to ensure the developed code isn't harmful for the existing codebase.
Tasks and defects tracking will be used to know the development and stability status at every moment.
Source Configuration Management is also important to keep the project codebase as well, using an open-source tool for this task (such as Subversion or CVS).
Following OGRE's directives, this project will be intensively documented, both its source and other important elements such as technology, project planning, reports and tools user manuals.
OGRE's coding style is also a key part of the development.
Will be fully multiplatform (at least Linux and Windows), and the tools used will be open-source or at least free.
Before implementing a feature, a previous UML design using patterns will be done to study the best suited approach for it.
[Project schedule]
- Sprint 1:
Project planning
Research on fields such as algorithms, approaches...
Prepare the workspace
Do the first designs for the next sprint
Sprint 2:
Develop the base framework to start implementing
Performance tests for the packing algorithms: Mainly determining how much wasted space they produce
Texture packing algorithms: A functional simple algorithm first. More will be developed later.
Texture packing implementation
Meshes updating
Sprint 3:
Borders to reduce linear filtering bleeding
Mipmap generation
Combine materials with same features that are sharing an atlas
First, basic version of the standalone tool
* At this point, first pack of code will be submitted to Google.
Sprint 4:
Scripts support
Texture compression support
Sprint 5:
Second version of the standalone tool
Add more texture packing algorithms
Extra features identified during development
Sprint 6:
Pre-release bug fixing
Final tests
Closing documentation
* At this point, the final version is submitted to Google
Concurrently, these tasks will be performed during the whole development cycle:
Technical documentation
Design
Testing
Code integration
Scrum Daily meetings via IM
Various (updating the forums and student-mentor communication)
Research and prototyping
Reports when closing a sprint and during evaluation periods
[About the student]
I've got my Bachelor's degree on Computer Science last year, and am currently studying for the Master's degree on Computer Science as well.
With good knowledge on project management and SCM, I've been lucky enough to learn from one of the founders of Codice software (Plastic SCM developers). I'm towards the use of agile methodologies for software development because of the great flexibility they have against changes over time (Scrum & XP are my personal favourites). I know UML quite fine and am a follower of "the three amigos" and "the gang of four".
Expert in automata and formal languages, I did my graduation project
Thoth (a Java application for the finite automaton and formal grammar simulation), currently used as a teaching assistance tool that got a 9 over 10 points on the graduation evaluation. I've always been interested in the compilers and syntactic analysers fields that will undobtely be very helpful for this project's script implementation.
Unfortunately in my university I haven't had the chance to learn about this subject, and thus this is an unique chance to develop my first heavy project on graphics design. I have always been interested on game development and wish to work on that industry in the future. That's why I think being a developer of a Google project for OGRE can open many doors to me in the future. Have got a good C++ level, but have known about OGRE a bit late. Some months ago I received a small course on OGRE from a MVP (Jesús Alonso Abad), and thanks to that I could come into the OGRE world and along these last months I haven't stopped to learn a lot by asking for advice from him and reading from the forums and wiki.
I'm sure I'm capable to handle this an if it's finally chosen, I swear I'll spend as much time as required until it's perfect.