[SoC 2009 - Accepted] Unified Samples Framework & Browser

Threads related to Google Summer of Code
Post Reply
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 - Submitted] Unified Samples Framework

Post by tuan kuranes »

Very nice UI skin and presentation !
minor remarks:
- Perhaps add some more emphasis on the selected sample picture, from here it's not that apparent the one it is.
(could be b&w pictures for non selected ones for instance.)
- Perhaps description and controls use each its own listbox, or perhaps a "sample specific" control info, as each sample would surely inherit the WASD and all other controls unless specified otherwise

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [SoC 2009 - Submitted] Unified Samples Framework

Post by jacmoe »

omniter wrote:What do you think?

Image
Awesome! :D
I can't wait. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: [SoC 2009 - Submitted] Unified Samples Framework

Post by Wolfmanfx »

I would prefer a image matrix than a horizontal list like the sample browser from gamebryo (PM if you want a screenshot i think thats not breaking the nda)

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 »

All good ideas, guys. It's still pretty early to decide on the precise layout, as it will depend on many things including which features we decide to put into the framework. When the time comes, I will post up a bunch of potential concepts and we could vote on them. :)

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

Re: [SoC 2009 - Submitted] Unified Samples Framework

Post by sinbad »

I like it. I actually like the horizontal scrolling idea, it reminds me of Cover Flow. I'm not sure precisely what Wolfmanfx means by a 'matrix' (I haven't seen the Gamebryo samples) but I think the main thing is to make sure it can handle an unbounded number of samples - which the scrolling idea obviously does.

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
x 3
Contact:

Re: [SoC 2009 - Submitted] Unified Samples Framework

Post by Praetor »

I think he means instead of a single horizontal scroll, the images would be laid out in a rectangle with multiple rows. I kind of like the layout. But as you said, it is early to decide on a final layout. The point is that it looks like a more professional, polished sample UI. I really like the overall feel of it.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [SoC 2009 - Submitted] Unified Samples Framework

Post by jacmoe »

A single row is both neat and compact. I like it. :)
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2702
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 47

Re: [SoC 2009 - Submitted] Unified Samples Framework

Post by syedhs »

I like multiple row, because it is easier and faster to pick a sample and execute it. What if the sample is at the end of the list - do you want to scroll till the end? ;) It can quickly become cumbersome.
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me

User avatar
jacmoe
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 20570
Joined: Thu Jan 22, 2004 10:13 am
Location: Denmark
x 179
Contact:

Re: [SoC 2009 - Submitted] Unified Samples Framework

Post by jacmoe »

syedhs wrote:It can quickly become cumbersome.
Only if it's not filtered.
/* Less noise. More signal. */
Ogitor Scenebuilder - powered by Ogre, presented by Qt, fueled by Passion.
OgreAddons - the Ogre code suppository.

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 »

Of course there's always the option of making everything and letting the user pick for himself. We could provide a few small iconic buttons at the top for changing the view.

And this might seem a bit like overkill, but I was thinking... if we are gonna implement saving/loading of basic sample state anyway, maybe we could add tabs to this browser? (much like a web browser) The user will be able to create a new tab containing a new sample or the same sample with different settings. The resources for both samples will be loaded at the same time, but only one sample will be active and visible at any given time. The scene will be saved and reconstructed each time the user switches tabs (pretty fast, same code used for changing display settings). Each sample only takes up a small amount of memory anyway, and this could come in very useful for comparing samples or comparing the same sample under different conditions. Taken beyond the browser, this could be used for pre-loading neighbouring areas in a game or demo. Any ideas on this?
Last edited by omniter on Mon Apr 20, 2009 10:38 pm, edited 4 times in total.

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

Re: [SoC 2009 - Accepted] Unified Samples Framework

Post by omniter »

I just woke up and saw the good news. My project was accepted for GSoC! Thanks everybody. Please continue to provide me with your valuable input. I'm really looking forward to this! :D Cheers!

P.S. - Here's the relevant part of my application in case you're interested.
Demos and SDK samples are one of the best ways to attract new users to the OGRE community and help them get started. The current samples framework, while solid, is outdated and lacks extensibility and versatility. I would like to develop a unified samples framework to replace the existing ExampleApplication framework, in addition to a sample browser. Among other features, the framework will support switching between multiple samples in one session, and dynamically detecting/loading samples. Having a unified, extensible and pluggable samples framework and a browser would not only make samples look more professional and spiffy; it would also allow us to create and modify samples and demos more quickly and efficiently.

Having talked to members of the community over the years, I got the general impression that the current framework is regarded as nothing but a "jumpstart" to play around with OGRE. This is probably due to the fact that ExampleApplication is very single-purpose. While there is nothing wrong with this, I think it would be nice if people could use the framework as more than just a "jumpstart" or a reference. By dividing the framework into separate, extensible layers, it allows each individual part to be more easily integrated into a user's own application.

Here are the proposed framework's three main components and a brief description of what they do:

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.

The SamplePlugin class is a very small class that allows storing one or more Sample instances inside a plugin. This will allow Samples to be detected and loaded into the application on-the-fly, which is also quite convenient.

The SampleContext is a large class, and will require most of the work. It is responsible for providing a 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.

One such application is a sample browser. The browser would start up in a main menu, which displays all available samples loaded from a configuration file. Samples will have a title, description and a thumbnail texture. From the menu, the user can select and view any sample. Similarly, from all samples, the user will have access to the main menu via an overlay. In the event that a sample fails to load, the browser will display the details and fall back to the menu. In addition to showing a sample list, the menu also provides a RenderSystem configuration screen and other options like reloading resources and pausing/resetting the sample. The menu can also be refreshed at any time to show new samples that may have been dynamically added.

Schedule
  • Week 1: Create SampleEngine class. Implement initial setup, dynamic configuration and resource loading, etc. with temporary placeholders for Sample-calling code, and a temporary test application.
  • Week 2: Create Sample class. Add Sample-calling code to SampleEngine.
  • Week 3: Create SamplePlugin. Add OIS support to Sample.
  • Week 4: 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: Start making browser using previous week's testing code. Implement loading sample info from config file.
  • Week 6: Create basic menu GUI. Implement error reporting, fallback to main menu, and menu access from within sample.
  • Week 7: Create additional menu options. (RenderSystem configuration, resource reloading, etc.)
  • Week 8: Create sample utilities. (Basic widget panel, camera presets, stats display, etc.)
  • Week 9: Add common in-game GUI and controls for browser. Begin converting some SDK samples.
  • Week 10: Implement SceneNode labeling in browser. Add command-line arguments to browser. Continue converting SDK samples and testing the framework and browser with them.
  • Week 11 & 12: Polish GUI, finish converting samples, do more testing, optimize, maybe add more features.
Last edited by omniter on Fri Apr 24, 2009 8:42 pm, edited 1 time in total.

User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2702
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 47

Re: [SoC 2009 - Submitted] Unified Samples Framework

Post by syedhs »

jacmoe wrote:
syedhs wrote:It can quickly become cumbersome.
Only if it's not filtered.
Well there is an easier way - make it multiple row. :) Multiple row with filter is simply awesome!

Btw, congrats on being accepted into summer project!
A willow deeply scarred, somebody's broken heart
And a washed-out dream
They follow the pattern of the wind, ya' see
Cause they got no place to be
That's why I'm starting with me

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: [SoC 2009 - Accepted] Unified Samples Framework

Post by Assaf Raman »

Congrats!
Have fun doing the project.
Watch out for my OGRE related tweets here.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

Re: [SoC 2009 - Submitted] Unified Samples Framework

Post by sinbad »

omniter wrote:And this might seem a bit like overkill, but I was thinking... if we are gonna implement saving/loading of basic sample state anyway, maybe we could add tabs to this browser? (much like a web browser) The user will be able to create a new tab containing a new sample or the same sample with different settings. The resources for both samples will be loaded at the same time, but only one sample will be active and visible at any given time. The scene will be saved and reconstructed each time the user switches tabs (pretty fast, same code used for changing display settings). Each sample only takes up a small amount of memory anyway, and this could come in very useful for comparing samples or comparing the same sample under different conditions. Taken beyond the browser, this could be used for pre-loading neighbouring areas in a game or demo. Any ideas on this?
This is an interesting idea, but I think it's a little bit overkill to begin with. If you have some time left at the end, by all means think about it, but I think this would overcomplicate things for now.

Congrats on your successful application, here's where the work begins ;)

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework

Post by sinbad »

I'm just getting your work environment set up.

Wiki page: http://www.ogre3d.org/wiki/index.php/SoC2009_Samples (please expand and keep updated with your progress, snapshot of current design & thoughts etc)
SVN branch: https://svn.ogre3d.org/svnroot/ogre/bra ... 09-samples

If you don't have a Sourceforge account already, please create one, and then let me know what it is on email (sinbad AT ogre3d DOT org). All development that you do should be in the branch shown above, which was taken from the trunk today. Your development will be in this separate branch so that you don't have to worry about breaking anything, and can experiment & commit to your heart's content so everyone can see your work in progress - at the end of the summer your code will be merged in to the main development trunk provided all is well.

Also important, I need a signed contributor license agreement from you now - complete, sign, scan & email it to me, or if you don't have a scanner you can fax or post it to me - again, email me if you need to do that.

Now is the time to get to know your mentor (Praetor) better too, so drop him an email (details on your updated SOC application) & exchange contact details for IM etc.

Please also read our coding standards document, and make sure you're familiar with how to use Subversion. If you have any questions, ask your mentor, any one of us on the GSoC bench (we're all providing backup support here), or here in our friendly community. :)

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

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by omniter »

This is all so new to me, but very cool. :D I will send the agreement within a couple of days. I've already talked to Praetor, and he's briefed me on some things and set up the communications. I've taken a look at the coding standards, and I'm pleased to say that most of it covers conventions I actually use. I'm currently busy packing, finding furniture and getting ready to move into a new apartment, so I won't be very active for the next week or so, but after that I can jump right to it. :D

P.S. - If it's okay, I thought I'd change the title for this project on the wiki pages to "Unified Samples Framework & Browser". My reasoning was that a sample browser (as opposed to just a framework) would probably be more likely to get members of our community interested and helping out.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by sinbad »

All sounds good.
omniter wrote:P.S. - If it's okay, I thought I'd change the title for this project on the wiki pages to "Unified Samples Framework & Browser". My reasoning was that a sample browser (as opposed to just a framework) would probably be more likely to get members of our community interested and helping out.
Sure thing - it's your page, word it the way you think is best - that name sounds fine to me.

User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by Kencho »

Congratulations for the acceptance :) The project sounds great, and definitely want to see the final result. Enjoy the project development!
Image

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

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by omniter »

I've made a minor change to the schedule. Implementation of dynamic graphics settings configuration was moved from week 1 (having too much work) to week 4 (having too little work). See the updated version in the wiki.

A couple of design decisions/changes:

SampleEngine is now called SampleContext. It would be less confusing since OGRE itself is an engine, and more precise since its purpose is to provide a common, safe "context" for Samples.

The SamplePlugin class is no longer part of the framework (it will still be made for the browser). There are a couple of reasons for this. First of all, it contains no unique functionality. That is, it does absolutely nothing that a Sample doesn't do except for being where it is (in a plugin). Secondly, it should be completely up to the user to provide the SampleContext with Samples, and the SampleContext should be agnostic of the Samples' origins. So, the browser will be responsible for locating plugins containing Samples, extracting them, and giving them to the SampleContext.

The third design decision concerns cross-sample resource management. Originally, SampleContext only had to handle one scenario: switching from Sample A to Sample B, where A or B could be possibly null. But in order to leave room for the possibility of having multiple samples loaded in memory and being able to switch back and forth quickly between them (i.e. browser tabbing, adjacent areas in a game), it becomes inevitable to have more complicated loading scenarios...

Let's say we have Samples A and B loaded, and we want to unload Sample B and load Sample C instead. We can't just do it in order, because B and C could potentially share resources, in which case there will be redundant reloading of resources. We also shouldn't do it in reverse order (even if unloading B doesn't affect C), because after the first step the resources for both Samples will be loaded, but we never need to see them at the same time, so this is unnecessary stress on memory. The only solution is to unload B first with the knowledge that C will be loaded immediately after, and not unloading its required resources. This was easy enough before, because we only needed to consider a maximum of two Samples: the current, and the next. Now, there can be any number of Samples, and we need to be able to load/unload any one of them with maximum efficiency, without needing an overly large/complicated interface.

The problem here is that we can no longer just tell SampleContext "what to do", because that would involve making a complicated set of instructions that seems far removed from the simple job we need done. Instead, what we could do is just tell SampleContext the end result we need, and hide away all the complexity. If you've ever used Ubuntu, chances are you've used the Synaptics package manager. If you have, you can probably guess what I'm about to propose...

The SampleContext will have a member class SampleContext::LoadJob. With a LoadJob, you can "mark" a Sample for loading or unloading, or "unmark" it. Basically, you're telling it which Samples you want loaded/unloaded without providing an order. Here's a code example for the aforementioned scenario using LoadJob:

Code: Select all

SampleContext::LoadJob job;
job.markForLoading(sampleC);
job.markForUnloading(sampleB);
sampleContext->doLoadJob(job);
sampleContext->setActiveSample(sampleC);
Note that lines 2 and 3 can be switched and the effect would be the same. While this is certainly more complicated than the original "quick switch", this same level of complexity applies to all possible scenarios, so overall, it makes the job easier. Plus, we get the feature we originally wanted. Besides, we could still make a "quick switch" wrapper method.

I know we agreed that tabbing is a little overkill for now, but I thought I should plan ahead for possible changes while I'm still laying out the foundations. A little extra work now is better than refactoring the whole darn thing later. :D

Please let me know what you think about these changes, guys. Thanks!

User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
x 3
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by Praetor »

Sounds like a good plan. I have used the package manager and what you propose generally makes sense. The most important things here are easy browsing and running of samples AND easy to add new samples. Easy, of course, being a relative and loaded word.
Game Development, Engine Development, Porting
http://www.darkwindmedia.com

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by sinbad »

I am wondering what you will actually do with the information that LoadJob gives you, in order to minimise reloading. It suggests that you will require the samples to identify what resources they need and do some kind of set operation on them?

This is as opposed to performing all sample 'destruction' first, which doesn't necessarily mean forcibly unloading resources, it means removing the objects that used those resources (materials, entities etc). If you then wanted to unload unused resources, ResourceManager::unloadUnreferencedResources or ResourceGroupManager::unloadUnreferencedResourcesInGroup would do it. Whether you do this before or after loading the next sample(s) depends on whether you want to maximise memory efficiency or load time of course - although bear in mind the load time for second loads is almost always much shorter thanks to disk caches.

So I wondered what your intentions were - I couldn't see how you would improve on the unloadUnreferenced.. approach unless you did some kind of separate matching process, which then puts more onus on the sample to expose what resources it uses so you can pre-match them. To be honest, I'm not sure it's worth the effort in either the framework (for the matching) or the samples (which then need to pre-announce all their resources, which is less convenient). If it introduces too much complexity I'm not sure it 'pays' for itself, given that my experience with reloading on most samples is not that bad, and in the cases where loading does take a long time it's often because the data is specific to the sample anyway (e.g. a large BSP level).

I might be missing something here so point it out if so :)

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

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by omniter »

sinbad wrote:I am wondering what you will actually do with the information that LoadJob gives you, in order to minimise reloading. It suggests that you will require the samples to identify what resources they need and do some kind of set operation on them?

This is as opposed to performing all sample 'destruction' first, which doesn't necessarily mean forcibly unloading resources, it means removing the objects that used those resources (materials, entities etc). If you then wanted to unload unused resources, ResourceManager::unloadUnreferencedResources or ResourceGroupManager::unloadUnreferencedResourcesInGroup would do it. Whether you do this before or after loading the next sample(s) depends on whether you want to maximise memory efficiency or load time of course - although bear in mind the load time for second loads is almost always much shorter thanks to disk caches.

So I wondered what your intentions were - I couldn't see how you would improve on the unloadUnreferenced.. approach unless you did some kind of separate matching process, which then puts more onus on the sample to expose what resources it uses so you can pre-match them. To be honest, I'm not sure it's worth the effort in either the framework (for the matching) or the samples (which then need to pre-announce all their resources, which is less convenient). If it introduces too much complexity I'm not sure it 'pays' for itself, given that my experience with reloading on most samples is not that bad, and in the cases where loading does take a long time it's often because the data is specific to the sample anyway (e.g. a large BSP level).

I might be missing something here so point it out if so :)
Sorry, maybe I wasn't clear. :) What I meant wasn't about removing resources that aren't currently being used. What I meant was removing resources that won't be used after the load job is complete, and loading resources that will be needed after the load job is complete. This is all already working under the assumption that whatever you unload is not currently being used.

In short, we're trying to find the fastest and most memory-efficient way to do any loading/unloading operation. Here's how:
  • From the list of all samples marked for unloading, make a collective list of all their used resource groups. Call this list A.
  • From the list of all samples marked for loading, do the same, and call this list B.
  • From the list of all samples already loaded but unmarked, do the same, and call this list C.
  • Unload everything in A that's not in B or C (or B - A - C).
  • Load everything in B that's not already loaded.
Consider the following scenario (using hypothetical resource groups):
We have two samples loaded; CelShading and Shadows. I want to switch the CelShading sample to the Dot3Bump sample instead. List A would contain all resource groups used by CelShading. List B would contain all resource groups used by Dot3Bump. List C would be all resource groups used by Shadows. Now we apply the algorithm: First step would remove everything needed by CelShading that's not needed by Shadows or Dot3Bump - i.e. the group containing the cel-shading script and ramp textures. Second step would load everything needed by Dot3Bump that's not already loaded - i.e. the group containing normal maps. The first step wouldn't unload the group containing the ogrehead mesh, because even though it is not needed by the remaining samples, it will be needed by Dot3Bump. This prevents extra reload time. And because we unload before loading, we never have more than 2 samples in memory at once.

In short, during a load/unload operation, the memory usage will never exceed that of either the current set of samples or the next set of samples, and we also do not have to reload any resource groups that are common between the two sets. This yields the maximum possible memory efficiency and speed. In the sample browser, this effect probably won't be very great when switching to a new sample because samples are pretty light in terms of memory usage, but if you extend the framework to be like a game level system (which it definitely can be), then this is absolutely necessary. This algorithm was going to be used whether or not we have the ability to have multiple loaded samples. The only change is that now it's done with a new class instead of through one "quick switch" method.

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

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by omniter »

Oh and yes, this is separate from the destruction of sample objects (like entities and scene nodes). That will be done first, and what's usually done after is the removal of unreferenced resources, but just because they're not referenced anymore doesn't mean they won't be soon. If you're switching immediately from one sample to another, and the second sample needs some of the same resources, wouldn't it make more sense not to unload those resources at all (even if it's faster on the second load)? And the samples simply specify which resource groups they need, not which specific resources, as tuan kuranes mentioned...
tuan kuranes wrote:
omniter 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 than current situation.

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

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by omniter »

Original way:

Image

New way:

Image

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 65
Contact:

Re: [SoC 2009 - Accepted] Unified Samples Framework & Browser

Post by sinbad »

Thanks for the drawings :)

But yeah, this confirms my thoughts - it means you're going to be asking samples to *pre-declare* all the resources they need. This is a new, additional requirement on the samples, which was my point. Yes, you will save unloading and reloading the resources which A and B have in common, but you also make A and B pre-declare a lot of information they didn't have to before. I'm suggesting you need to consider whether imposing that overhead on the development of every sample is worth the overhead saving you make of reloading shared resources, given that these are not production applications but rather examples. The way I see it, you have 3 choices:

1) Terminate Sample A, unload unreferenced resources, load sample B (efficient in memory, but possible reloading)
2) Terminate Sample A, load Sample B, unload unreferenced resources (not so efficient in memory, but no reloading)
3) Your pre-declaration of all resources (efficient in memory, no reloading, but requires every sample to predeclare resources)

1 and 2 are cheap in development time of samples, but have a trade off of either causing unnecessary reloads (1) or using extra memory (temporarily - 2). Option 3 is efficient but requires every sample to be more complicated because it has to identify every resource it needs up-front.

All 3 options have costs is all I'm saying. My personal experience is that with non-production sample code, you can afford to trade a little efficiency for keeping the samples simpler and easier to develop. The KISS principle applies :)

Post Reply