OGRE Wiki
Support and community documentation for Ogre3D
Ogre Forums
ogre3d.org
Log in
Username:
Password:
CapsLock is on.
Remember me (for 1 year)
Log in
Home
Tutorials
Tutorials Home
Basic Tutorials
Intermediate Tutorials
Mad Marx Tutorials
In Depth Tutorials
Older Tutorials
External Tutorials
Cookbook
Cookbook Home
CodeBank
Snippets
Experiences
Ogre Articles
Libraries
Libraries Home
Alternative Languages
Assembling A Toolset
Development Tools
OGRE Libraries
List of Libraries
Tools
Tools Home
DCC Tools
DCC Tutorials
DCC Articles
DCC Resources
Assembling a production pipeline
Development
Development Home
Roadmap
Building Ogre
Installing the Ogre SDK
Setting Up An Application
Ogre Wiki Tutorial Framework
Frequently Asked Questions
Google Summer Of Code
Help Requested
Ogre Core Articles
Community
Community Home
Projects Using Ogre
Recommended Reading
Contractors
Wiki
Immediate Wiki Tasklist
Wiki Ideas
Wiki Guidelines
Article Writing Guidelines
Wiki Styles
Wiki Page Tracker
Ogre Wiki Help
Ogre Wiki Help Overview
Help - Basic Syntax
Help - Images
Help - Pages and Structures
Help - Wiki Plugins
Toolbox
Freetags
Categories
List Pages
Structures
Trackers
Statistics
Rankings
List Galleries
Ogre Lexicon
Comments
History: SoC2009 Samples
View page
Source of version: 4
(current)
{img src="img/wiki_up/Week10.jpg" alt="thumb|Browser and a few converted samples as of week 10." width="300" imalign="right"} {img src="img/wiki_up/Mockup.jpg" alt="thumb|Initial mockup concept for the browser menu." width="200" imalign="right"} !Summer of Code 2009: Unified Samples Framework & Browser __Student:__ Zi Ye (omniter) __Mentor:__ Brian Johnstone (Praetor) __Location:__ branches/soc09-samples __Status:__ Beyond !!Any new developments? A video showing currently converted samples and a few new features [http://vimeo.com/6004973|here]. Details in [http://www.ogre3d.org/forums/viewtopic.php?f=13&t=48680|the thread]. !!Why a new framework? * 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". !!Why a sample browser? 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. !!How will the framework be made? 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. !!How will the browser be made? 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 [http://www.ogre3d.org/forums/viewtopic.php?f=13&t=48680|the thread]. !!When will the work be done? 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. !!What will the final product be like? [http://vimeo.com/5382976|Here's a video demonstration] of framework usage as of week 5. [http://vimeo.com/5519320|Here's a video demonstration] of browser and the new tray manager as of week 7. [http://vimeo.com/5652766|Here's a video demonstration] of all tray widgets as of week 8. [http://vimeo.com/5794695|Here's a video demonstration] of browser features as of week 9(a). [http://vimeo.com/5868430|Here's a video demonstration] of browser config and orbit cam as of week 9(b). [http://vimeo.com/6004973|Here's a video demonstration] of samples and some new features as of week 10. Some pictures on the right as well. ===> Stay tuned! !!Any links? Yes. [http://www.ogre3d.org/forums/viewtopic.php?f=13&t=48680|Discussion Thread] See? Come again, I might get more. ---- Alias: (alias(SoC2009_Samples))
Search by Tags
Search Wiki by Freetags
Latest Changes
Minimal Ogre Collision
Artifex Terra
OpenMB
Advanced Mogre Framework
MogreSocks
Critter AI
Mogre Add-ons
MOGRE
Mogre MyGUI wrapper
MOGRE Editable Terrain Manager
...more
Search
Find
Advanced
Search Help
Online Users
71 online users