Student: Zi Ye (omniter)
Mentor: Brian Johnstone (Praetor)
- To allow running multiple samples in one application instance.
- To allow dynamic detection/loading of samples as plugins.
- To only require compiling/recompiling of sample-specific code.
- To provide common setup and controls for samples.
- To be multi-purpose, extensible, and easy to integrate.
- To be more than just a "jumpstart".
First and foremost, the browser as a deliverable will demonstrate the power of the new framework. But behind the browser lies another important motivation...
Some think that good visuals and presentation, or what we sometimes call "eye-candy" are superficial because they present little insight into the actual quality of the engine. Others think that, while these things help our cause, they are simply extras that should not be given much priority. The truth is that demos and SDK samples give potential new users a first impression of OGRE. Attention to detail, good design, consistency, feature-richness - these are OGRE's great qualities. Why should these qualities be reflected any less so in OGRE's samples, especially since OGRE is a graphics engine? Besides, it'd be a nifty thing to have.
The work for the framework can be best described in terms of its required components:
The Sample class is responsible for everything sample-specific, such as scene setup and event handling. Everything a Sample instance does is safely repeatable, thus allowing multiple Samples to be run in one session, and for Samples to be created and edited without compiling the entire framework. This also means that Samples can be placed inside plugins, allowing them to be detected and loaded into the application on-the-fly.
The SampleContext is a large class, and will require most of the work. It is responsible for providing a shared context in which samples can run. This includes setting up OGRE, creating a window, and loading appropriate resources and plugins. The SampleContext must handle multiple samples, and must make switching back and forth between them as fast and efficient as possible based on each sample's requirements. The SampleContext will also support dynamic RenderSystem configuration.
In addition to these three classes, there will be some utility classes to aid in the creation of common sample elements. These include common GUI elements and camera presets.
By combining and extending these classes, it is possible to create a wide range of OGRE applications with great flexibility in the loading and execution of samples.
In contrast to the framework, the work for the browser is best described in terms of its planned features:
- Menu displaying thumbnail and notes for all detected samples, accessible at all times.
- Display settings configuration screen.
- Refresh sample list.
- Reload textures and materials while viewing a sample.
- Pause, unpause and reset samples.
- Centralised sample error feedback without crashing (fallback to menu).
- An OGRE GUI theme.
NOTE: This feature list is not exhaustive, and could be a little inaccurate/outdated. For more information, visit the thread.
Below is a rough week-by-week development timeline, spanning the months of May to August of 2009, not including future extensions and maintenance. Please note that this timeline is only a guide, and is subject to change based on work pace and feature changes.
- Week 1 (Done): Create SampleContext class. Implement initial setup and resource loading, etc. with temporary placeholders for Sample-calling code, and a temporary test application.
- Week 2 (Done): Create Sample class. Add Sample-calling code to SampleContext.
- Week 3 (Done): Make Samples pluggable. Add OIS support to Sample.
- Week 4 (Done): Implement dynamic graphics configuration for SampleContext. Add custom data to Samples. Create test samples and test the main classes with different scenarios. (Multiple plugin samples, plugin/static sample mix, resource conflicts, different scene managers, different render systems, dynamically detecting plugins, performance/efficiency issues, accumulative residual effects, etc.)
- Week 5 (Done): Start making browser using previous week's testing code. Implement loading sample info from config file.
- Week 6 (Done): Start basic tray manager system. Implement error reporting.
- Week 7 (Done): Create additional widgets for tray system and start on browser interface.
- Week 8 (Done): Finish all required widgets and implement more browser features.
- Week 9 (Done): Finish all remaining browser features. Create sample camera controller.
- Week 10 (Done): Start converting SDK samples and testing the framework and browser with them.
- Week 11 & 12 (Done): Continue converting samples, do more testing, optimize, maybe add more features/utilities (like browser command-line arguments).
- Beyond (Started): Finish converting samples, create new documentation and tutorials and update the OGRE wiki pages.
Here's a video demonstration of framework usage as of week 5.
Here's a video demonstration of browser and the new tray manager as of week 7.
Here's a video demonstration of all tray widgets as of week 8.
Here's a video demonstration of browser features as of week 9(a).
Here's a video demonstration of browser config and orbit cam as of week 9(b).
Here's a video demonstration of samples and some new features as of week 10.
Some pictures on the right as well. ===>
Yes. Discussion Thread See? Come again, I might get more.