Resource Manager

[Zonder]

I am opening this thead to discuss how the resource manger should be handled

I do have a framework in mind but I want peoples opinions before.

[Klaim]

I didn't yet have time to plunge in it fully, but I will soon.
My initial thinking is like this:

1. remove the current ResourceManager from OgreMain, only keep the data streams as input.
2. have a component that would be a simple implementation of ResourceManager (something a bit simpler than the current one)
3. make sure the OgreMain interfaces takes data streams asynchronously (if active), this part being linked to the threading discussion, but globally everybody agree that there should be some kind of queue (and a way to notify the user code).

All three would be done in parallel in a perfect world.
I hope to have time digging in resource management stuffs in the end of the month so I might be available to help on this at that time.
I think it's still too simpist pov (because I didn't have time to digg in Ogre code about resource management these days) so I'm interested in what you have to propose.

[CABAListic]

The one thing I don't see in your outline is how Ogre would do automated resource loading, i.e. when a resource references other resources (like a mesh referencing a material referencing a texture). You'd still need some sort of manager that keeps track of loaded resources and can forward a request for an unknown resource to the pluggable loading implementation.

Or would you want to get rid of that feature altogether and expect everyone to always pre-load all required resources manually?

[Klaim]

The one thing I don't see in your outline is how Ogre would do automated resource loading, i.e. when a resource references other resources (like a mesh referencing a material referencing a texture). You'd still need some sort of manager that keeps track of loaded resources and can forward a request for an unknown resource to the pluggable loading implementation.

Or would you want to get rid of that feature altogether and expect everyone to always pre-load all required resources manually?

See, how my suggestion isn't informed enough. This is typical of feature I totally forgot about.
This needs some thinking. First reaction would be to remove this feature yes, but now I think it's not good because of Ogre material system requiring this kind of feature.
edit> Or maybe this points that the interconnection between both system is to tight?

Maybe we should identify exactly what is problematic with the resource manager first.

1. the system to locate resources is not customization (I mean it have it's own logic)
2. it's organized in hierarchies of resources, which sometime makes hard to release a specific set of resources
3. it's made for Ogre resources only (even if you can extend it, but then you live by the rules of this resource system which have the previous flaws).

Any other?

[Mako_energy]

The one thing I don't see in your outline is how Ogre would do automated resource loading, i.e. when a resource references other resources (like a mesh referencing a material referencing a texture). You'd still need some sort of manager that keeps track of loaded resources and can forward a request for an unknown resource to the pluggable loading implementation.

Or would you want to get rid of that feature altogether and expect everyone to always pre-load all required resources manually?

Personally, I would expect people to pre-load resources, and use sane and very visible defaults in the complete absence of certain resources. To an extent Ogre already does these things. If you go to load a mesh, and it needs a skeleton that isn't available, leave the identity transform locked in place. Many models have a very visible identity transform that can be spotted by developers. In the case of humanoid characters in particular I've seen it several games that had the model upright with their arms out in a way that is never done by the animations themselves. Going further, if a material is missing then just place the "BaseWhiteNoLighting" material in it's place. This one Ogre already does I believe, and it's pretty uncommon that anything will be entirely white giving another visual que. If a texture is missing Ogre could do a checkered pattern like older games did(Do games still do this? Is this a lower level render system thing?). These are easy to spot so the developer can troubleshoot and ensure the resources are there when they need it.

Going one step further each manager for a given resource could keep track of what is requested. You could even have listeners for this in keeping with the design Ogre has right now. But when a file is loaded and mentions another file, the manager gets notified of the request. People could then make a listener that would call their own resource implementation (or even Ogre's implementation) that would load the file or add it to a queue. Having utilities that are designed to read from a memory buffer that will automatically handle the locking of render system buffers would go a long way in making this easier for people like me.

[Knotanalt]

But if you are preloading everything you don't need to do all this in the first place.

I'm not sure you want to make a distinction between resources in separate threads. There's not a ton of reason to ever do that. Meaning you should have everything in one place, be requesting them somehow, not jst create them as you feel like in separate threads.

Mostly I would actually want to preload stuff, but you need to have the option to have stuff exist but not use it til needed, lots of applications/games are going to have a lot of materials and often limited memory. You don't want all that garbage active at all times.

So you would have something like a resource manager now, but if necessary change it so when you request it you load it immediately but also have the option to load them asynchronously. This lets you do other stuff as they load more easily - you start everything loading then update a "loading" screen or if you have enough loaded to progress simply go on.

You could associate materials with scenes and then the game knows to load those resources with that scene, as well.

If you have experience with threading it's not too hard I guess, but then again you don't have any threaded stuff built directly into ogre either so to me that's the first thing I'd do. Put in some simple cross platform tools for than, then use that to make your resource loader. Unfortunately it takes cross platform activity to do this which makes it a decent sized work. Maybe boost could be distilled down to the very simplest form (really, should be like a couple pages of code) then just stuck directly into the engine.

[Zonder]

I would expect the threading to be transparent to the client if the resource manager needs to load somthing async it will just use an available thread.

[bstone]

I would expect the threading to be transparent to the client if the resource manager needs to load somthing async it will just use an available thread.

Nope, that would enforce an asynchronous protocol for all use cases including those that don't need threaded resources. Resource management as it is casts enough frustration onto the users who don't dig deep into it. And what you suggest would force poor users to always go through the hassle of the async notification protocol just to make sure a texture is actually loaded before it is used

If you want your resources loaded in the background then look no further than Ogre::ResourceBackgroundQueue. It has all that is needed and falls back gracefully to synchronous loading if you disable OGRE_THREAD_SUPPORT.

[Zonder]

I would expect the threading to be transparent to the client if the resource manager needs to load somthing async it will just use an available thread.

Nope, that would enforce an asynchronous protocol for all use cases including those that don't need threaded resources. Resource management as it is casts enough frustration onto the users who don't dig deep into it. And what you suggest would force poor users to always go through the hassle of the async notification protocol just to make sure a texture is actually loaded before it is used

If you want your resources loaded in the background then look no further than Ogre::ResourceBackgroundQueue. It has all that is needed and falls back gracefully to synchronous loading if you disable OGRE_THREAD_SUPPORT.

I never said it was only threaded just that when using async methods it should be transparent about how it is doing it.

I do think we should be ignoring the current implementation and be deciding what it needs to do and how, then see what we have already got.

[bstone]

Ah, I see. It's just that threading is not something that can be really transparent b/c of the inherent synchronization issues (not the low-level stuff like locks and shared resources - I mean the high-level API that is bound to reflect the asynchronous nature of anything threaded).

[Klaim]

Yes it's like the future C++ libraries that are asynchonous (for example PPL which is one library taken as example for the next standard), they will all return std::future<T> instead of T because you don't know how much time is necessary to get the T object. I'm not there yet, but if I remember correctly, Ogre does basically the same.

[Knotanalt]

You don't necessarily have to change anything for the synchronous stuff. Future is just one more unnecessary template/complication.

[Klaim]

1. template are not always complications
2. I wasn't suggesting using std::future, please read the full sentence.

[Knotanalt]

1. template are not always complications
2. I wasn't suggesting using std::future, please read the full sentence.

I didn't say that you did. I wasn't even really talking to you in specific because you aren't the one who claimed that. I know that my statement is true because I did lots of asynchronous code and my own open source library that features it.

But template is always a complication, that doesn't mean to never use them but I wouldn't use them in that manner.

[Owen]

As someone who has both used Ogre3D for various projects, and been unable to use it for a different project because of the resource system, my views on the existing resource system are as follows:

• It absolutely needs to support applications in which the contents of the resource system cannot be enumerated
• It absolutely needs support for alternative material description, program description and mesh formats
• It absolutely needs support for asynchronous resource loading without tying up one thread per resource being loaded

In particular, I have a project in which meshes and textures are loaded from the internet (mostly from a main "object repository", but additionally supporting loading objects from arbritrary URLs) in which the existing archive system is pretty much entirely counterproductive to my needs. Additionally, it needs to load models in multiple formats.

My proposal is as follows:

Step 1
Remove ResourceManager, ResourceGroupManager and ResourceGroup from OgreMain; they will later reappear (refactored) in the optional "OgreResourceSystem" component.

The majority of Resource's functionality will be removed; most noticeably, resources will no longer have a name. Resource's main job will be implementing the resource "state machine", which will have the following states:

• UNLOADED: None of the material is GPU resident
• LOADING: The loader responsible for the resource has been informed that the resource needs loading; the loader should be in the process of loading it (depending upon the loader itself, this could be a slow process; for example, it might involve a download over a network)
• RESIDENT: The resource is on the GPU

Note that OgreMain will no longer have any notion of "prepared"/"unprepared" resources.

All resources will have a loader associated with them, similar to existing objects with a ManualResourceLoader; the responsibility for actually loading resources from files is delegated to this object.

The resource will invoke the loader when it needs to transition from the UNLOADED to the LOADING state; the loader is responsible for preparing the actual hardware objects backing the resource and triggering the switch of the resource into the RESIDENT state. A resource may be unloaded (in which case it directly switches to the UNLOADED state) either directly (by invoking the unload() method), or because of an external event (for example, a device loss)

All Resource methods are required to be invoked on the Ogre main thread, and all ResourceLoader methods will be invoked on that thread. The threading model behind the resource loader is undefined by Ogre.

Resources will be created by invoking methods on their corresponding manager (i.e. a Mesh will be created by calling a method on MeshManager).

Step 2
The existing Mesh loader and script loaders will be separated from OgreMain into their own modules, and made available in such a way as to enable their use with the new resource loading system.

Step 3
The existing resource system will be implemented in terms of the new resource loader system and the newly separated Mesh/Material/Program/Compositor loaders.

All parts of Ogre which at present reference named resources will be converted to just use DataStreams.

Comments?

If the Ogre developers are interested, I'd like to make this a GSOC proposal when student applications open in a week

[Mako_energy]

If the Ogre developers are interested, I'd like to make this a GSOC proposal when student applications open in a week

This...makes me absolutely thrilled. I've had my fingers crossed for such a project this year. I do have a few questions regarding your plans however.

1. What would you do with the other classes that are a part of the Ogre resource system that you haven't mentioned, such as Archive? Would the Archive be the responsibility of the loaders instead, requiring a different loader per resource per archive type?
2. What would you do about the existing level of integration the resource system has with Ogre Main? For example would classes that are derived from Resource still be derived from that or a similar class?
3. What would be the plan or expectation on the game developer for resources that need to call on the loading of other resources when someone opts out of compiling Ogre with it's resource component?

[Klaim]

Thanks Owen, I agree it looks like a very good plan and as you have apparently far more experience than me using Ogre it's a good thing you wrote this.
I'm working a lot with OgreProcedural these days because I don't have yet a resource manager and it looks like it will not be this month I attack this problem. :/

Anyway, I have a few questions:

1. Resource objects would be provided via smart pointers like now, so destroying Resource objects (no more references to it) would invoke unloading if there is no ResourceManager module loaded. Am I correct?

2. About question 3 from Mako_energy, my understanding is that to integrate this system in my own game(-specific) engine I would need to implement a loader type (to use my implementation of concurrent behaviour) and my resource manager would just have to work with the Ogre::Resource instances. Am I correct?

3. I suppose default loaders would be provided in OgreMain, which would be synchronous if no threading is enabled, async if it is. For the async versions, it might need threading re-architecture to implement them correctly, doesn't it? So their implementation might have to be dalayed until threading interface is set? Or maybe not providing them at all?

4. Comment: My understanding of the GSOC time frame is that the basics of this work would be ready around end of August. It's not that far but it's not really near either. I wish I could work on this myself but I feel like I might not be able to find the time, at least not this month. I'll make a note to take a decision at the beginning of next month if I can spend some time on working on this or not (because my game dev schedule is a bit hardcore but in the same time I think I'll need this separation or the resource system which is really annoying me). I think I see how to do it.

5. Also, could you make a simple diagram of what you just described, just to be sure I'm not missing anything?

6. Not really important, but is there a reason why you propose RESIDENT instead of LOADED? I was wondering if it was to make it clear it's in another hardware component than the GPU (which would be almost wrong with APUs but whatever) Is it by experience you think that name is better or is it just taste? I don't really care but I like to know how people name values.

[Owen]

This...makes me absolutely thrilled. I've had my fingers crossed for such a project this year. I do have a few questions regarding your plans however.

1. What would you do with the other classes that are a part of the Ogre resource system that you haven't mentioned, such as Archive? Would the Archive be the responsibility of the loaders instead, requiring a different loader per resource per archive type?

Archive would be moved to the "OgreResourceSystem" library (which will essentially re-implement the current resource system on top of the new hooks provided in OgreMain

2. What would you do about the existing level of integration the resource system has with Ogre Main? For example would classes that are derived from Resource still be derived from that or a similar class?

Ogre::Resource would still exist, but with much reduced responsibilities (primarily avoiding duplication of code around the resource tracking state machine

3. What would be the plan or expectation on the game developer for resources that need to call on the loading of other resources when someone opts out of compiling Ogre with it's resource component?

Because OgreMain would no longer have any file format parsers, it would no longer be in any way involved in the loading of dependencies. The separated out Mesh/Material/Etc loaders would provide hooks that any resource system implemented on top of them would use in order to trigger the loading of dependencies.

Thanks Owen, I agree it looks like a very good plan and as you have apparently far more experience than me using Ogre it's a good thing you wrote this.
I'm working a lot with OgreProcedural these days because I don't have yet a resource manager and it looks like it will not be this month I attack this problem. :/

A lot of the above comes from writing a custom resource manager for a custom 3D engine (for the project which, as I said above, couldn't use Ogre because of the resource system). I have no doubt you have more experience with Ogre than me!

1. Resource objects would be provided via smart pointers like now, so destroying Resource objects (no more references to it) would invoke unloading if there is no ResourceManager module loaded. Am I correct?

That would be the case at least initially, yes. I'd like to add the ability for people to intercept resource destruction when the reference count reaches zero, however, to enable intelligent caches. That said, with std::shared_ptr and similar, that can be done with a custom destructor (if Ogre::SharedPtr doesn't support that, it can easily be implemented)

Alternatively, we might pick something more "tightly coupled" to the resource use case. Certainly by avoiding a "standard" shared pointer we can remove some threading overhead.

2. About question 3 from Mako_energy, my understanding is that to integrate this system in my own game(-specific) engine I would need to implement a loader type (to use my implementation of concurrent behaviour) and my resource manager would just have to work with the Ogre::Resource instances. Am I correct?

Yes.

3. I suppose default loaders would be provided in OgreMain, which would be synchronous if no threading is enabled, async if it is. For the async versions, it might need threading re-architecture to implement them correctly, doesn't it? So their implementation might have to be dalayed until threading interface is set? Or maybe not providing them at all?

My plan is to move the "default loaders" to separate libraries (so that they can be used independently of one another) and then provide the existing resource system as an optional library built upon these. At least initially this can be single threaded; multi threaded support can wait until we have a concrete threading interface if necessary

4. Comment: My understanding of the GSOC time frame is that the basics of this work would be ready around end of August. It's not that far but it's not really near either. I wish I could work on this myself but I feel like I might not be able to find the time, at least not this month. I'll make a note to take a decision at the beginning of next month if I can spend some time on working on this or not (because my game dev schedule is a bit hardcore but in the same time I think I'll need this separation or the resource system which is really annoying me). I think I see how to do it.

The GSOC timeline says that work starts on June 14th; depending upon my exam timetable I may be free to start before then. Once started, my intention is to get the new system working quickly and then work on incrementally restoring the existing functionality (resource manager, mesh/material loaders, etc)

5. Also, could you make a simple diagram of what you just described, just to be sure I'm not missing anything?

I'll look into making one when I get back to my desktop. Do you have any recommended software?

6. Not really important, but is there a reason why you propose RESIDENT instead of LOADED? I was wondering if it was to make it clear it's in another hardware component than the GPU (which would be almost wrong with APUs but whatever) Is it by experience you think that name is better or is it just taste? I don't really care but I like to know how people name values.

To distinguish that "The resource has been loaded onto the GPU" as opposed to "The resource has been loaded in memory". A resource manager might have an internal notion of a "loaded resource" (as my existing engine with its' network resource manager does). "Resident" is often used when referring to the state of an object being loaded on the GPU, so I chose that for this case.

[Klaim]

1. Resource objects would be provided via smart pointers like now, so destroying Resource objects (no more references to it) would invoke unloading if there is no ResourceManager module loaded. Am I correct?

That would be the case at least initially, yes. I'd like to add the ability for people to intercept resource destruction when the reference count reaches zero, however, to enable intelligent caches. That said, with std::shared_ptr and similar, that can be done with a custom destructor (if Ogre::SharedPtr doesn't support that, it can easily be implemented)

Alternatively, we might pick something more "tightly coupled" to the resource use case. Certainly by avoiding a "standard" shared pointer we can remove some threading overhead.

Indeed I don't think it's a good idea to add anything to shared_ptr (whatever the implementation), but adding event handling for each states into the Resource system seems necessary at least for handling concurrent loading correctly from the user side.

The GSOC timeline says that work starts on June 14th; depending upon my exam timetable I may be free to start before then. Once started, my intention is to get the new system working quickly and then work on incrementally restoring the existing functionality (resource manager, mesh/material loaders, etc)

Nice! As said I'll see next month if I can help at some point, maybe just by helping on reviewing the design, at least.

5. Also, could you make a simple diagram of what you just described, just to be sure I'm not missing anything?

I'll look into making one when I get back to my desktop. Do you have any recommended software?

I don't have a preference, I often just use google docs/drive drawing document. Ogre documentation have been made using BOUML which is often recommended if you want something simple.

[bstone]

Very interesting. Some ideas are pretty sensible but others raise my concerns...

It absolutely needs support for asynchronous resource loading without tying up one thread per resource being loaded

Anything to back that up?

The majority of Resource's functionality will be removed; most noticeably, resources will no longer have a name.

How would you reference resources then? Consider the following use case: an entity needs it material changed to a specific one. How would the code for getting a pointer to that material resource look after that change?

RESIDENT: The resource is on the GPU

What about resources that never go to the GPU?

Note that OgreMain will no longer have any notion of "prepared"/"unprepared" resources.

Have you thought about the reasons behind that notion? Why would you want to ignore them?

Resources will be created by invoking methods on their corresponding manager (i.e. a Mesh will be created by calling a method on MeshManager).

A line of a client code as an example please.

All parts of Ogre which at present reference named resources will be converted to just use DataStreams.

A sample of such a change in the API?

To distinguish that "The resource has been loaded onto the GPU" as opposed to "The resource has been loaded in memory". A resource manager might have an internal notion of a "loaded resource" (as my existing engine with its' network resource manager does). "Resident" is often used when referring to the state of an object being loaded on the GPU, so I chose that for this case.

That conflicts with UNLOADED, LOADING, and RESIDENT. So will there be LOADED or not? Because that's one of the things "unprepared" stands for and you said you won't have "prepared/unprepared". Not consistent.

[Owen]

Very interesting. Some ideas are pretty sensible but others raise my concerns...

It absolutely needs support for asynchronous resource loading without tying up one thread per resource being loaded

Anything to back that up?

My own network resource manager provides a simple example: it is unwarranted to waste a thread to just monitor the download progress of a resource; particularly when it is trivial to implement this without threading.

Obviously it is reasonable to use a thread for the process of parsing/loading the resource into memory, but in applications (such as that use case of mine) in which the object is loaded from the internet, and a single scene could feasibly trigger the load of ~30 or more resources, one thread per resource is either going to require a large thread pool or significant serialisation (which may cause suboptimal pipelining of requests)

The majority of Resource's functionality will be removed; most noticeably, resources will no longer have a name.

How would you reference resources then? Consider the following use case: an entity needs it material changed to a specific one. How would the code for getting a pointer to that material resource look after that change?

It would ask its resource manager for the resource by name. The intention, essentially, is to remove the resource manager from OgreMain; an application using the default resource manager would ask for the material from "Ogre::ResourceManager"; but equally plausibly it might ask for it from "Game::CustomResourceManager" (which could have a completely different API)

Addons such as CEGUI would be able to inject their resources without caring about whether or not their resource names would conflict with the application's resources

RESIDENT: The resource is on the GPU

What about resources that never go to the GPU?

The only cases I can see of this are Compositors and Materials. Perhaps to handle these cases, the term "Loaded" should be retained.

Note that OgreMain will no longer have any notion of "prepared"/"unprepared" resources.

Have you thought about the reasons behind that notion? Why would you want to ignore them?

That state is better handled by the resource manager, not by the 3D engine.

Resources will be created by invoking methods on their corresponding manager (i.e. a Mesh will be created by calling a method on MeshManager).

A line of a client code as an example please.

meshManager.createMesh(loader), as per with the existing resource manager with manual resources

Most client code will talk to its' resource manager to get handles to named resources

All parts of Ogre which at present reference named resources will be converted to just use DataStreams.

A sample of such a change in the API?

Mostly this involves removing convenience methods that are currently provided which are coupled to the resource manager, e.g. the ConfigFile overload which loads from a resource, and the setWorldGeometry overload which takes a resource name.

Likewise, the named resource overloads of createEntity would be removed; you would have to pass a MeshPtr

To distinguish that "The resource has been loaded onto the GPU" as opposed to "The resource has been loaded in memory". A resource manager might have an internal notion of a "loaded resource" (as my existing engine with its' network resource manager does). "Resident" is often used when referring to the state of an object being loaded on the GPU, so I chose that for this case.

That conflicts with UNLOADED, LOADING, and RESIDENT. So will there be LOADED or not? Because that's one of the things "unprepared" stands for and you said you won't have "prepared/unprepared". Not consistent.

The intermediate state - where an object is loaded, but not ready for use (for example, for meshes, textures and programs not resident on the GPU) is the concern of the resource manager, not the engine.

OgreMain may trigger a resource to be loaded (i.e. switch it into the LOADING state and notify the resource loader because it was placed in the scene) but otherwise only really cares whether a resource is loaded or not.

[bstone]

Thanks for the explanation. It's a bit more clear now.

a single scene could feasibly trigger the load of ~30 or more resources, one thread per resource is either going to require a large thread pool or significant serialisation (which may cause suboptimal pipelining of requests)

That's what I was asking about. Why do you think that Ogre allocates one thread per resource?

It would ask its resource manager for the resource by name. The intention, essentially, is to remove the resource manager from OgreMain; an application using the default resource manager would ask for the material from "Ogre::ResourceManager"; but equally plausibly it might ask for it from "Game::CustomResourceManager" (which could have a completely different API)

You can't ask for a material from a generic ResourceManager. You need a specific one to match the resource class types otherwise you'll have to litter your code with up-casts which is rather bad. Just bringing your attention to this.

The only cases I can see of this are Compositors and Materials. Perhaps to handle these cases, the term "Loaded" should be retained.

I would add any custom resources a user might want to have while leveraging the resource management provided by the resource system infrastructure.

That state is better handled by the resource manager, not by the 3D engine.
...
The intermediate state - where an object is loaded, but not ready for use (for example, for meshes, textures and programs not resident on the GPU) is the concern of the resource manager, not the engine.

OgreMain may trigger a resource to be loaded (i.e. switch it into the LOADING state and notify the resource loader because it was placed in the scene) but otherwise only really cares whether a resource is loaded or not.

I don't really agree on that one. Resource manager has no idea about whether I want to move a resource out from the GPU to unprepared state and then quickly move it back to prepared state (back to GPU) and when. This is ruled by performance requirements and specific application logic. I clearly wouldn't want a resource reloaded from the media in such cases. Devices being lost is clearly the domain of the 3D engine and not the resource system as well. The application might want to dictate which resources should be kept unprepared in order to restore them as fast as possible after the loss and without an extra file system access.

[syedhs]

There are actually quite a number of resources that never go to GPU - for an example, a json/cfg configuration files, png files for pagedgeometry and many others (those two examples are quick ones, I am sure there are many others).

[bstone]

Skeletons with animations never go to the GPU and meshes do not entirely go to the GPU by the way (the critical information like LOD lists and vertex-to-bone assignments never goes there).

[Owen]

Thanks for the explanation. It's a bit more clear now.

a single scene could feasibly trigger the load of ~30 or more resources, one thread per resource is either going to require a large thread pool or significant serialisation (which may cause suboptimal pipelining of requests)

That's what I was asking about. Why do you think that Ogre allocates one thread per resource?

I don't think it does. It passes them to the work queue which loads one resource (synchronously) per thread in the thread pool. This results in the work queue's threads being tied up loading resources from (potentially slow) sources, even when asynchronous I/O could be used to speed up the process greatly.

It would ask its resource manager for the resource by name. The intention, essentially, is to remove the resource manager from OgreMain; an application using the default resource manager would ask for the material from "Ogre::ResourceManager"; but equally plausibly it might ask for it from "Game::CustomResourceManager" (which could have a completely different API)

You can't ask for a material from a generic ResourceManager. You need a specific one to match the resource class types otherwise you'll have to litter your code with up-casts which is rather bad. Just bringing your attention to this.

Being as the ResourceManger is going to get a major overhaul, this API can change.

The only cases I can see of this are Compositors and Materials. Perhaps to handle these cases, the term "Loaded" should be retained.

I would add any custom resources a user might want to have while leveraging the resource management provided by the resource system infrastructure.

Granted, though I see less use for them once the resource manager is excised

That state is better handled by the resource manager, not by the 3D engine.
...
The intermediate state - where an object is loaded, but not ready for use (for example, for meshes, textures and programs not resident on the GPU) is the concern of the resource manager, not the engine.

OgreMain may trigger a resource to be loaded (i.e. switch it into the LOADING state and notify the resource loader because it was placed in the scene) but otherwise only really cares whether a resource is loaded or not.

I don't really agree on that one. Resource manager has no idea about whether I want to move a resource out from the GPU to unprepared state and then quickly move it back to prepared state (back to GPU) and when. This is ruled by performance requirements and specific application logic. I clearly wouldn't want a resource reloaded from the media in such cases. Devices being lost is clearly the domain of the 3D engine and not the resource system as well. The application might want to dictate which resources should be kept unprepared in order to restore them as fast as possible after the loss and without an extra file system access.

You seem to be missing here that my intention is to separate the Resource Manager from OgreMain in its entirety. Resource will become an Ogre-focused perspective on the resource; from the point of view of the rendering system, a resource is either loaded (i.e. in a state ready for use) or unloaded (Unusable; perhaps in RAM or on disk, but from a rendering perspective neither is usable). Note that in my first post I explicitly mentioned that in some cases Ogre would itself cause a resource to transition to the unloaded state (when a device is lost, for example)

The default resource manager (i.e. the one shipped with Ogre which provides the functionality built in to OgreMain today) will continue to have a "Prepared" notion of a resource, and will continue to provide the control over those states that it does today. Other applications may replace that completely with their own, or supplement it