[SoC 2009 - Accepted] Unified Samples Framework & Browser

Threads related to Google Summer of Code
Post Reply
User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

[SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by omniter »

UPDATE: Project Wiki is here.

Hi everyone!

I'm Zi. I've been an Ogre user for quite a few years now, but regrettably I have not been too active around the forums. I plan to apply for GSoC this year as a student, and just wanted to take this chance to introduce myself and present this project proposal. Nothing formal yet, just some ideas thrown around in the back of my head. It was initially pulled from the Help Requested page, and slightly expanded upon. Please give me all the feedback you can, guys!

Summary:

Demos and SDK samples are one of the best ways to attract new users to our community. And among all the open-source 3D engines out there, I personally think that Ogre has some of the better samples to show. This said, Ogre deserves a kickass sample framework to match. Having a unified framework and interface will not only make all samples look professional and spiffy; it would also allow the team to make and edit samples with more ease and speed, and serve as an excellent basis for users to get started with Ogre or to produce simple demos quickly.

Some key/obvious features:
  • Sample browser to allow dynamic switching between samples
  • An extensible (non-rigid) design that allows great flexibility in samples
  • Easy addition of new samples
Additional planned features:
  • New input/GUI setup allowing easy addition of key toggles, value sliders, stats, etc.
  • Common camera control scheme presets (orbit, FPS, turntable, custom, etc.)
  • A new, truly "Ogre" look for the GUI
  • (Suggestions, please!)
Optional features:
  • Dynamic device property modification (dimensions, fullscreen, vsync, etc.)
  • Allow pausing, unpausing, and resetting the simulation
Basic Plan:

My current plan is to make each sample into an Ogre plugin. The sample browser will be the only executable in the samples directory. Samples could be listed in the existing "Plugins.cfg" or a new "Samples.cfg". The startup code for an Ogre plugin is smaller than that of the current sample apps (Not to mention it's all functional, instead of a cloud of preprocessor directives) Adding a new sample would be as simple as creating a new plugin and adding it to "Samples.cfg". The browser will load all sample plugins at startup, and display their names, descriptions and thumbnails, which are all provided by the plugins (thumbnails can be stored in a subdirectory under the media folder). At any time when viewing a sample, the user should be able to summon this main menu and select another sample to view.

Examples and demos are likely to have some tweakable options/values. Because this is so common, I figured there should be some easy way to do this. Off the top of my head, it should look something vaguely like:

Code: Select all

sampleMgr->addNumericOption(densitySlider, &setParticleDensity, defaultDensity);
sampleMgr->addBooleanOption(source, &toggleFireworks, true);   // source could be a checkbox or key
Similarly, they usually employ some kind of common camera setup:

Code: Select all

sampleMgr->setCameraMode(CM_ORBIT, 0.5f);    // mode and speed
I understand that while convenience is important, one of the main reasons behind the examples is to... well, exemplify. The example framework would be pointless if it wrapped up and hid away all the work. It's therefore important to keep all utilities to a minimum, and to keep the framework consistent with Ogre's design philosophy.

Pause and Reset:

Sometimes, I'd like to be able to pause and reset the samples. This is useful for observing small details in examples with moving objects without having to take screenshots.

Visual Theme:

Ogre's been crying out for an icon, and I hope the sample browser can have one. Besides, with an icon, you could proudly put a Ogre Sample Browser shortcut under the Start Menu or something :D. Fonts and widgets should also follow a consistent styling. With its own consistent visual theme, the SDK would look that much more kickass.

Given the timeframe, I do not think these goals are unrealistic. I might be wrong though. Any suggestions/criticism is welcome.

Please give me a hand, guys! Thanks! :)
Last edited by omniter on Wed Apr 22, 2009 12:49 pm, edited 8 times in total.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Re: Unified Sample Framework

Post by tuan kuranes »

I do like the idea of "samples plugins" and "sample framework" so that contributors/addons could add their own. but you'll have to develop furter the framework idea.

- A 'resource/renderer/ogre plugin/ scene manager/requirements(opengl only, dx only, dll needed, etc.)' context per sample ? which would lead of a more complete samples.cfg description per section ?
- Can you clarify if you want to rewrite a GUI library or just make a consistent CEGUI skin ?
- Should/Could this be also used for an enhanced "test browsers" (actual "playpen" is growing badly) ?
User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: Unified Samples Framework

Post by omniter »

Thanks for the feedback, tuan kuranes.

To my understanding, Ogre already has its own "framework". This is not something new. However, with the existing framework, each example has to be run separately. By making a sample browser, and turning the samples into plugins, you remove this need. Thus, users don't have to close the window, select another sample, and go through the config dialog and initial startup time just to view another sample. Also, before, if there were any changes you wanted to make to all the samples, you had to change and rebuild each sample. Now, many of these changes can be made to the sample browser alone.

Obviously, the resources for all the samples would not be collectively loaded by the browser at startup. Currently resources are loaded on-demand for each sample. This does not need to change. All sample-specific resources are simply unloaded when a new sample is selected. Thus, there is no need to provide extra information in the resource config. As for requirements of the samples, I think it would make more sense to make a note of them in the sample description in the plugin itself.

Regarding the second point, I do not plan to create a new GUI library. That's somebody else's job, and would only slow this project down. I was thinking of either making an Ogre-themed CEGUI skin, or making a very simple overlay-based GUI system specifically for samples.

As for "test browsers" and PlayPen, I personally have had no experience with them. However, any application currently built on ExampleApplication can definitely be built on the new framework. The framework will be totally extensible, and new applications can be made from it easily. If you have any ideas on a "test browser", they could definitely be added to the list of goals.

If I have misunderstood the meaning of "Unified Samples Framework" from the Help Requested page, somebody please let me know! :(
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: Unified Samples Framework

Post by Assaf Raman »

omniter wrote:...I've been an Ogre user for quite a few years now, but regrettably I have not been too active around the forums...
Can you write more about what and how you used OGRE in the past?
I just what to get some more background on you.
Watch out for my OGRE related tweets here.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Re: Unified Samples Framework

Post by tuan kuranes »

If I have misunderstood the meaning of "Unified Samples Framework" from the Help Requested page, somebody please let me know!
Seems to me you understood perfectly the need and idea. Better & sexier UI, and at last but not least easier and faster to add samples.
Now we/you have to make sure it's nice and extensible enough.
Obviously, the resources for all the samples would not be collectively loaded by the browser at startup. Currently resources are loaded on-demand for each sample
Not sure of that. A better framework would parse only needed resource groups for each sample at load. Much faster loading that current situation.
As for requirements of the samples, I think it would make more sense to make a note of them in the sample description in the plugin itself.
Shouldn't it appears in the browser to that user know why that sample won't work on its cpu/gpu/platform ?

My point of view here is from the "sample contributor", and sample that are not just using ogre core.
Say I want to add OgreAL samples or the ssao demo to the browser.
I could have to add a new ogre plugin (ogral), may I work with a specific RenderSystem (say a DX10 sample only), exclude or include scenemanager with this sample, or need another set of medias, etc... how can the new framework you propose can either enforce or at least ease the process.
As for "test browsers" and PlayPen, I personally have had no experience with them
Check ogre "playpen" project source in svn. You'll see the idea of why it could use some "browse" functionallity instead of "comment/define" system.

Btw, you should/could make a round up/comparison of existing sample browser framework (directx, nvidia, ati, unreal, other 3D engines...) to find interesting bits...
User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: Unified Samples Framework

Post by omniter »

Hey Assaf,

I've been using Ogre for roughly 3-4 years now. Most recently, I've been using Mogre to develop a .NET game engine in Boo. In the past, I've used Ogre to make small games and demos, screensavers, 3D presentations, and a very small AI sim. I tied for second place in Futureplay 2006 with a game prototype I made in Ogre. I've been programming in C++ since 7th grade. I started graphics programming with OpenGL and Direct3D, then moved on to Ogre. I also use other languages, but I think I digress... I'm a decent artist, and I've had experience creating my own GUIs in the past, including with Ogre overlays. I don't have a portfolio or anything ready right now, but if you want I could compile some stuff I did and show it to you.
Last edited by omniter on Fri Mar 20, 2009 8:19 pm, edited 2 times in total.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: Unified Samples Framework

Post by Assaf Raman »

Thanks for the replay, your history teaches me a lot about you and what you can do.
omniter wrote:...I don't have a portfolio or anything ready right now, but if you want I could compile some stuff I did and show it to you.
This is not a requirement – but some samples\demos\code will increase you chance of being selected.
We prefer experienced users.
Watch out for my OGRE related tweets here.
User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: Unified Samples Framework

Post by omniter »

tuan kuranes wrote:
Obviously, the resources for all the samples would not be collectively loaded by the browser at startup. Currently resources are loaded on-demand for each sample
Not sure of that. A better framework would parse only needed resource groups for each sample at load. Much faster loading that current situation.
That is definitely a good idea. My game engine project does just that. I could expand the "Samples.cfg" to contain this information.
tuan kuranes wrote:
As for requirements of the samples, I think it would make more sense to make a note of them in the sample description in the plugin itself.
Shouldn't it appears in the browser to that user know why that sample won't work on its cpu/gpu/platform ?
They will appear in the browser. All sample plugins are loaded together by the browser at startup, and from then on, the browser will have access to all such information.
tuan kuranes wrote: My point of view here is from the "sample contributor", and sample that are not just using ogre core.
Say I want to add OgreAL samples or the ssao demo to the browser.
I could have to add a new ogre plugin (ogral), may I work with a specific RenderSystem (say a DX10 sample only), exclude or include scenemanager with this sample, or need another set of medias, etc... how can the new framework you propose can either enforce or at least ease the process.
That is a very good point. If I understand correctly, the plugins can simply load whatever other plugins they need before their samples start. As for RenderSystem or SceneManager requirements, the sample plugin can provide that information, the sample browser will display it, and the loader will take the appropriate actions to ensure the right RenderSystem and SceneManager are used (including recreating the Root object), and report errors if any are encountered.
tuan kuranes wrote:
As for "test browsers" and PlayPen, I personally have had no experience with them
Check ogre "playpen" project source in svn. You'll see the idea of why it could use some "browse" functionallity instead of "comment/define" system.
I just did, and yes, I think the framework can definitely be used to create a test browser. Instead of browsing samples, it just browses tests.
tuan kuranes wrote: Btw, you should/could make a round up/comparison of existing sample browser framework (directx, nvidia, ati, unreal, other 3D engines...) to find interesting bits...
Will do. :)
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: Unified Samples Framework

Post by sinbad »

I think you've got a good start here - you've picked up on the main idea of making the samples pluggable, which is good. Thinking about how 3rd parties might drop their own samples or tests into this framework easily, without necessarily having to rebuild the sample framework, is a good move.

Definitely focus on the framework and the functionality first, and the look and feel later - this can always be polished later.

I like your thinking on making it simple to add GUI options by abstracting the interface to it. I'm not sure how well that will work with the more complicated interfaces, without exposing a lot of the underlying detail (for example, handling callbacks and querying combinational state), so some flexibility might be needed here to allow the sample to define it's own GUI while still operating within the overall framework (which may have a 'parent' GUI overall for switching samples). I'm thinking of Steam here - where each game has its own GUI but you can pop up a Steam overlay anywhere which controls top-level things.

Anyway, keep it up :)
User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: [SoC 2009] Unified Samples Framework

Post by omniter »

Turns out, it's relatively simple to make the samples pluggable. However, pluggability is a very small part of the goal. In fact, in my previous posts, it seemed as though I'd made it mandatory for samples to be used by the browser. That's not a flexible/extensible system at all. So, I've thought a bit about how exactly to make the framework more extensible/flexible.

So far I've come up with these key classes:
  • Sample
  • PluginSample
  • SampleEngine (or SampleContext, SampleRunner, whatever)
The Sample class provides a basic structure for samples. It will be responsible for scene setup, event handling, etc. much like the current ExampleApplication class. Also like ExampleApplication, it is fully extensible, and intended to be subclassed. One key difference though is that Sample does not setup Ogre, load resources, or create a window. It will, however specify the plugins and resources it requires (Note that specifying required plugin names effectively covers RenderSystem and SceneManager requirements). Also, the Sample can provide a GPU capabilities test. It will also include some convenient GUI, camera and control methods, but you still have access to the low-level stuff, of course. With this class alone, we do not really have a framework, but the important thing is that we've left room for multiple samples to run in one session, because the Sample only performs safely repeatable actions.

The PluginSample is a very small class that basically extends Sample and Plugin to make a pluggable Sample. Now you not only have the ability to dynamically switch between built-in Samples, but to dynamically detect new Samples that can be immediately added and played.

The SampleEngine class will be responsible for setting up Ogre, loading resources, and creating a window, etc. to prepare a suitable "context" for Samples to run in. One very important feature of SampleEngine is that it handles switching between multiple Samples. It reads the requirements from each Sample, loads the appropriate plugins and resource groups, and sets the appropriate RenderSystem. Between Samples, it also aims to be efficient by only unloading the resource groups not required by the next Sample, thus minimizing reload. Similarly, it will do a device reset only when the next Sample needs a different RenderSystem. The SampleEngine can handle Samples as well as PluginSamples, which are loaded differently, but are otherwise treated exactly the same, because they both expose the Sample interface. To make a sample application, you only have to extend Sample or PluginSample, and not SampleEngine. Though this class is extensible, there's rarely any customization you need to do to the engine (which is why it's called an engine).

With these central classes, all that's missing to make a sample browser is a loading screen and a menu to display Sample requirements and info to the user. For example, the Sample class can provide a title, description, and a thumbnail texture location, and the browser can use this to display each Sample. Neat-O. Also, the browser can show the user each Sample's requirements, the reason it is unavailable, the reason it failed to load, how exactly the GPU does not pass the Sample's test, and other side notes. Instructions can even be provided before the Sample is loaded, so the user will know exactly what to do (like if the Sample is a game demo). If a Sample fails to load, the browser will display an error and fall back to the menu. It's easy to make a "menu scene" like in Half-Life 2 or Warcraft 3. It's even possible to make a main "navigation room" like in the NeoAxis demo. Just make a Sample. :)
sinbad wrote: I'm thinking of Steam here - where each game has its own GUI but you can pop up a Steam overlay anywhere which controls top-level things.
In fact, that's exactly what I was thinking from the beginning. If the pause/reset functionality is implemented, we could even pause the Sample and display the menu on a translucent layer, like in Ocarina of Time.

All of these classes will be extensible, and can be used to create... well, the possibilities are endless. You could even make a game level system out of this, with each Sample serving as either a level, or a certain "kind" of level/cutscene/whatever. Certainly, it can be used for more than samples and demos. :)

Tell me what you think!
Last edited by omniter on Wed Mar 25, 2009 3:36 pm, edited 1 time in total.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: [SoC 2009] Unified Samples Framework

Post by sinbad »

This all sounds good.

A few points:
  • You mention the sample identifying the rendersystem - this is good, because some sames might only support one rendersystem (we try to avoid this, but sometimes it's inevitable such as geometry shaders) - but of course a complexity here is that changing rendersystem requires more of a reinitialisation than simply changing resources. It would actually be really awesome to be able to hit a button and switch an active sample from one rendersystem to another, preferably keeping the camera position, but to do this will require pretty much a complete reinitialisation (except for Root); the window will need to be recreated and everything will need to be reloaded. To automate that would be very, very useful for testing though, and indeed will be required for switching between some samples.
  • You mentioned dynamically detecting samples. I like this idea - would you do it based on a 'refresh samples' button or something and scan a folder for plugins? That's pretty cool for drag & dropping user samples.
  • Another nice feature would be a simple 'reload resources' option; say if you'd updated a mesh or something on the disk and wanted to see the results immediately. We've had an item on our wishlist about detecting files being updated on disk and reloading them automatically to make the round trip on asset testing easier; that's a different subject, but a manual 'reload' option pretty much falls out of the first point I mentioned anyway, since switching rendersystem requires a sample reload. I see it as a 'lite' version of that, since the window and rendersystem etc would stay intact, but the scene would be reloaded and the camera put back in its current position. It's a big more broad-brush than the 'detect and reload' functionality, since everything in the scene would be reloaded rather than just the file(s) that updated, but still it would be nice to have.
User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: [SoC 2009] Unified Samples Framework

Post by omniter »

Thanks for the reply, sinbad!
sinbad wrote: You mention the sample identifying the rendersystem - this is good, because some sames might only support one rendersystem (we try to avoid this, but sometimes it's inevitable such as geometry shaders) - but of course a complexity here is that changing rendersystem requires more of a reinitialisation than simply changing resources. It would actually be really awesome to be able to hit a button and switch an active sample from one rendersystem to another, preferably keeping the camera position, but to do this will require pretty much a complete reinitialisation (except for Root); the window will need to be recreated and everything will need to be reloaded. To automate that would be very, very useful for testing though, and indeed will be required for switching between some samples.
I was thinking that the only time to switch RenderSystem would be in between samples in the menu. Then you wouldn't have to worry about saving and restoring the camera and what not. The reason I avoid that is because there might be a lot more to restore than just the camera; it might end up being a full serialization/deserialization system. If however this is implemented (I had considered implementing it), it would allow for dynamic graphics configuration! :D This means we can actually add an in-game equivalent of the ConfigDialog. Of course, I realize this is a lot of work, and is why I mentioned it as an optional feature in my original post.
sinbad wrote: You mentioned dynamically detecting samples. I like this idea - would you do it based on a 'refresh samples' button or something and scan a folder for plugins? That's pretty cool for drag & dropping user samples.
This is exactly what I was thinking. However, it would not be necessary to scan any folders. The original sample list was loaded from "Samples.cfg", so hitting the refresh samples button would simply cause the config to be reparsed.
sinbad wrote: Another nice feature would be a simple 'reload resources' option; say if you'd updated a mesh or something on the disk and wanted to see the results immediately. We've had an item on our wishlist about detecting files being updated on disk and reloading them automatically to make the round trip on asset testing easier; that's a different subject, but a manual 'reload' option pretty much falls out of the first point I mentioned anyway, since switching rendersystem requires a sample reload. I see it as a 'lite' version of that, since the window and rendersystem etc would stay intact, but the scene would be reloaded and the camera put back in its current position. It's a big more broad-brush than the 'detect and reload' functionality, since everything in the scene would be reloaded rather than just the file(s) that updated, but still it would be nice to have.
That sounds good. Here is my idea:
Create a method that reloads textures and materials (This is as "light" as it gets). The sample browser could provide an option to either manually reload textures and materials or to automatically do a reload once every few seconds or so. I use this in my game engine, and find it incredibly useful when editing materials and textures. The reason why it's so useful is because textures and materials are hard to "preview" in an editing program like Photoshop or Blender. Unless you have something like oFusion, it's hard to get the exact look you get in-game. This is why tweaking it in-game saves time. On the other hand, meshes look pretty much the same everywhere, and it's less likely people will make frequent small adjustments to them while in-game. Editing a mesh usually takes a while, and exporting, processing, and moving the file to the right location isn't very quick either. This is why I find it less useful to make a mesh-reloading method. However, if the sample saving/restoration is implemented, then this is already done. We simply have to save the sample, restart the sample, and restore it to the previous state. Voila, all resources refreshed. This is heavier than the texture/material reload, but still lighter than a full system reset. Lastly, the "dynamic ConfigDialog" would use the aforementioned method plus make changes to the RenderSystem.

Another idea I had was a "labeling" feature that adds a nametag overlay to objects in the scene. You could apply masks or filters so that only certain objects are labeled. Do you think this might be useful for debugging? I've posted some code for this and material reloading in the User Forums.

That leads me to this... would it be a good idea to give the samples some sort of "quickSave" and "quickLoad" methods? Though it would be unrealistic to implement a full scene serialization/deserialization system for this project given the timeframe, a Sample would only need to save off important SceneNode positions and maybe some custom data. These things fit perfectly into a ConfigFile format. Therefore, every sample could save off and restore a "last session" as a .cfg file. Something like this:

Code: Select all

[SceneNodes]
SceneNode = MainCamera 0.218777 0.24333 0
SceneNode = OgreHead 0 0 0
SceneNode = Fireworks1 1.253333 3.1223 0

[CustomData]
ParticleSpeed = 5
ParticleDensity = 1.52
What do you think? :)

P.S. I was also wondering if the Sample classes can be used to make unit testing easier. Not that I'd like to take on that task right now as well, but it would be cool if it was possible.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: [SoC 2009] Unified Samples Framework

Post by sinbad »

omniter wrote:Thanks for the reply, sinbad!
sinbad wrote: I was thinking that the only time to switch RenderSystem would be in between samples in the menu. Then you wouldn't have to worry about saving and restoring the camera and what not.
What I was trying to suggest was that to reload another sample can actually be seen as the same as reloading the same sample again - which would allow you to switch render systems to check that everything looks ok between them. I realise you wouldn't want to get into a full serialisation case, that would get complicated, so I'd suggest that everything would reset to as it was when the sample was newly loaded - it just might be nice to special-case the main camera, because that's really the main thing you might want to keep the same. If that's awkward, just being able to restart the same sample with a different rendersystem with all the state reinitialised is still valuable.
sinbad wrote: You mentioned dynamically detecting samples. I like this idea - would you do it based on a 'refresh samples' button or something and scan a folder for plugins? That's pretty cool for drag & dropping user samples.
This is exactly what I was thinking. However, it would not be necessary to scan any folders. The original sample list was loaded from "Samples.cfg", so hitting the refresh samples button would simply cause the config to be reparsed.
Ok, I actually think having the option to scan a folder or pattern-match, rather than having to edit a configuration file, would be nice to have. Maybe the Samples.cfg could just specify a location to look in and a pattern to look for. That way dropping in a new sample is even easier.
Create a method that reloads textures and materials (This is as "light" as it gets). The sample browser could provide an option to either manually reload textures and materials or to automatically do a reload once every few seconds or so. I use this in my game engine, and find it incredibly useful when editing materials and textures. The reason why it's so useful is because textures and materials are hard to "preview" in an editing program like Photoshop or Blender.
Yes, a manual reload option would be good, and yes perhaps categorise it. I'm not sure reloading every few seconds is a good idea (unless you use the timestamp to prevent unnecessary reloading, but this would require a bit more digging in the resource system), but certainly having a button saying 'reload X type of resource' would be useful.
Another idea I had was a "labeling" feature that adds a nametag overlay to objects in the scene. You could apply masks or filters so that only certain objects are labeled. Do you think this might be useful for debugging? I've posted some code for this and material reloading in the User Forums.
It's interesting, what would the tags be used for?
That leads me to this... would it be a good idea to give the samples some sort of "quickSave" and "quickLoad" methods? Though it would be unrealistic to implement a full scene serialization/deserialization system for this project given the timeframe, a Sample would only need to save off important SceneNode positions and maybe some custom data.
I wouldn't go down this route personally, it overlaps a bit too much with other scene formats (dotscene, and the upcoming paged world format), so I think it could get confusing. As mentioned above I don't think storing even the camera position is absolutely essential between sample restarts, and I wouldn't start coming up with another scene format just for the sample framework.
P.S. I was also wondering if the Sample classes can be used to make unit testing easier. Not that I'd like to take on that task right now as well, but it would be cool if it was possible.
[/quote]
We have PlayPen at the moment which is a sort of visual unit test - all the things that we need to test if they 'look right' rather than being able to use CppUnit on them end up in here. With a new samples framework, I would make all of these tests use the new structure so they could be more easily used on demand instead of editing PlayPen.cpp. I wouldn't want to create a separate DLL for each one though, so the samples framework would need to support having multiple samples injected from one loaded DLL - which shouldn't be difficult.
User avatar
xavier
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 9481
Joined: Fri Feb 18, 2005 2:03 am
Location: Dublin, CA, US
x 22

Re: [SoC 2009] Unified Samples Framework

Post by xavier »

FWIW, it sounds like what you are proposing is exactly how Havok does their demos (it's a single app with dozens of different demo classes). Perhaps you could have a shufti at their demo framework to get some more concrete ideas?
Do you need help? What have you tried?

Image

Angels can fly because they take themselves lightly.
User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: [SoC 2009] Unified Samples Framework

Post by omniter »

Thanks for all the input, guys. I really appreciate the support.

To sinbad:
So no sample saving - okay. As for comparing two RenderSystems on the same Sample - already a part of the plan! It would be part of the "dynamic config dialog", along with all the other settings (FSAA, fullscreen, etc). And I just realized that plugins can have different extensions now, so pattern matching and scanning would definitely be a good idea. About the labels... afaik, SceneNodes can't be visually represented unless they have objects attached. Sometimes, objects/materials don't show up for some reason, and it might be helpful to know exactly where each SceneNode is. I'm thinking like a 3D modeler here. As for multiple Samples in one plugin, well... I can't believe I didn't think of that. :oops:

To xavier:
I'll have a shufti right away. :)

Anyway, I think I have enough material to work with to make a preliminary application now, which should be heading your way sometime soon. Although, since there's going to be revisions anyway, I'd like a chance to get some input from the user community, see what they think and what they want. I'm just not sure which forum section to ask them. Any ideas on that?
User avatar
cdleonard
Goblin
Posts: 266
Joined: Thu May 31, 2007 9:45 am

Re: [SoC 2009] Unified Samples Framework

Post by cdleonard »

Some thoughts:

Semi-automatic reloading of resources would be a very nice feature to have inside OgreMain. It would be nice if stuff like this gets implemented inside OgreMain to support the sample framework instead of in a separate library. It can be something like "reload all files modified in the last second"; per-resource timestamps can be avoided.

If samples are in a different dll/so then it might be possible to reload the entire plugin without restarting the main app and reloading resources. This is cool but not really as useful as reloading textures.

It would be very useful to start with an arbitrary set of render system caps and multiple render windows. The current config dialog can't do that; and it should.

Serialization is indeed overkill and overlaps stuff like dotscene. Building demo scenes in code is very reasonable. Still; it would be nice to expose a couple of tunable parameters for a sample and have "the framework" auto-generate some sliders and buttons. Those parameters "could" be saved and loaded; but anything that enumerates scene nodes is definitely overkill.
User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: [SoC 2009] Unified Samples Framework

Post by omniter »

Thanks for the input, cdleonard.
cdleonard wrote: Semi-automatic reloading of resources would be a very nice feature to have inside OgreMain. It would be nice if stuff like this gets implemented inside OgreMain to support the sample framework instead of in a separate library. It can be something like "reload all files modified in the last second"; per-resource timestamps can be avoided.
So you're saying... for each resource, instead of comparing a saved timestamp against the current file timestamp, you would just compare the current file timestamp against the system time? While this would certainly remove the memory overhead, it does not necessarily make automatic full resource check any faster. It might be faster if we categorize the checks though. In any case, this feature would definitely be useful if you want to edit a scene in real-time. If the team approves this feature, we could definitely add it to the project, since it loosely fits in.
cdleonard wrote: If samples are in a different dll/so then it might be possible to reload the entire plugin without restarting the main app and reloading resources. This is cool but not really as useful as reloading textures.
In fact, it isn't necessary to even reload the plugin. Samples can be restarted, with or without reloading resources.
cdleonard wrote: It would be very useful to start with an arbitrary set of render system caps and multiple render windows. The current config dialog can't do that; and it should.
Somehow I don't see multiple render windows being very useful for a samples framework. The SampleEngine could probably be extended to support such functionality though. In any case, it is beyond the scope of this project. I'm not sure what you mean by an "arbitrary set of render system caps". Are you talking about running with a set of caps different from your card's?
cdleonard wrote: Serialization is indeed overkill and overlaps stuff like dotscene. Building demo scenes in code is very reasonable. Still; it would be nice to expose a couple of tunable parameters for a sample and have "the framework" auto-generate some sliders and buttons. Those parameters "could" be saved and loaded; but anything that enumerates scene nodes is definitely overkill.
Some common sample GUI elements are already a planned feature.
User avatar
cdleonard
Goblin
Posts: 266
Joined: Thu May 31, 2007 9:45 am

Re: [SoC 2009] Unified Samples Framework

Post by cdleonard »

omniter wrote:
cdleonard wrote: If samples are in a different dll/so then it might be possible to reload the entire plugin without restarting the main app and reloading resources. This is cool but not really as useful as reloading textures.
In fact, it isn't necessary to even reload the plugin. Samples can be restarted, with or without reloading resources.
I'm sorry; what I meant is that it might be possible to unload the plugin; recompile it; and load it again. All that without restarting the main exe.
omniter wrote:I'm not sure what you mean by an "arbitrary set of render system caps". Are you talking about running with a set of caps different from your card's?
Render system caps support serialization. You could offer an option to start with capabilities from a file.
User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: [SoC 2009] Unified Samples Framework

Post by omniter »

cdleonard wrote: I'm sorry; what I meant is that it might be possible to unload the plugin; recompile it; and load it again. All that without restarting the main exe.
What would be the point? Recompiling a plugin isn't something you can do quickly and frequently, so allowing dynamic sample plugin reloading wouldn't save any time.
cdleonard wrote: Render system caps support serialization. You could offer an option to start with capabilities from a file.
Then I understood you correctly. I'll be sure to mention this.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Re: [SoC 2009] Unified Samples Framework

Post by tuan kuranes »

About samples enhancements, some command line argument (argv, argc) support in the framework would be great too.
from command line we could choose :

- Rendersystem (d3d9, d3d10, gl, gl3.0, glES, auto, last)
- Which Sample(s) to run automatically
- Rendersystem caps (helps test a particular GPU simulation)
- ...
- and letting other arguments to be passed to plugins (they might have some needs too.)


That would help a lot in debug/release launch from visual studio or other tools as well and why not someday have some "render test" (using advanced image diff and or manual checkup of resulting images of all tests) being runnable automatically.
User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: [SoC 2009] Unified Samples Framework

Post by omniter »

tuan kuranes wrote: About samples enhancements, some command line argument (argv, argc) support in the framework would be great too.
Command-line arguments would have to be in the browser, and not in the Sample or SampleEngine. But I suppose the SampleEngine could accept some initial conditions, which could be passed to it through the command-line by the browser. This is definitely doable.

Keep the ideas coming. I don't know if they can all get squeezed into one summer, but adding them and extending the framework should be a breeze after the main components are complete and solid.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Re: [SoC 2009] Unified Samples Framework

Post by sinbad »

omniter wrote:About the labels... afaik, SceneNodes can't be visually represented unless they have objects attached. Sometimes, objects/materials don't show up for some reason, and it might be helpful to know exactly where each SceneNode is.
Oh, I see - yes, that could be useful for debugging.
Anyway, I think I have enough material to work with to make a preliminary application now, which should be heading your way sometime soon. Although, since there's going to be revisions anyway, I'd like a chance to get some input from the user community, see what they think and what they want. I'm just not sure which forum section to ask them. Any ideas on that?
This forum is already public to everyone, so this is the best place to ask.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Re: [SoC 2009] Unified Samples Framework

Post by tuan kuranes »

Keep the ideas coming.
You can add further applications hindsight too, like results/report/roundup of checking all other samples browser existing, and conclusion about it.(btw, bullet and ogrebullet has also 2 very crude but working sample browser, an "utility GUI", as well as useful debug info.)
User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: [SoC 2009 - Submitted] Unified Samples Framework

Post by omniter »

I just saw the comment on my GSoC application. Totally forgot that rafb purges pastes. I've attached the sample code in a zip file along with a readme. Sorry for the confusion!
Attachments
SampleCode.zip
(14.33 KiB) Downloaded 302 times
User avatar
omniter
OGRE Contributor
OGRE Contributor
Posts: 424
Joined: Thu Mar 19, 2009 8:08 am
Location: Canada
x 44

Re: [SoC 2009 - Submitted] Unified Samples Framework

Post by omniter »

Hey, everyone!

Exams are finally over! I thought I might make a little mockup screen just for the hell of it. It's not like I've included every little detail, but I just wanted to give myself an idea of what the product (just the browser) might roughly look like. I tried to make the colour scheme true to Ogre. What do you think?

Image
Last edited by omniter on Tue Jul 28, 2009 9:28 pm, edited 1 time in total.
Post Reply