I'm not sure what you are thinking about when you say "Resource", but to the Away3D loading system a resource is a file and it's dependencies, i.e. a logical source of data that can be parsed into assets. I'm not sure how such a resource could be more interesting than the contained assets, but please explain your use case to help me understand.
If you simply want to group all the assets in a file together, and separate them from another group of assets (from another file), the best way would probably to write some app-specific code to do that separation i.e. a class called "AssetGroup" which contains a list of names of those assets (or references to the actual asset objects) that were found in a particular load operation. As you have already mentioned, you can separate events by loading operation using the AssetLoaderToken returned by all load() and parseData() methods. I imagine that when you need to do such a thing, it's usually due to some more fundamental app-level logic anyway (e.g. the "asset groups" are really game characters) and in that case you probably already have a class for that grouping (e.g. MyGameCharacter) in which it makes sense to put your character assets. Cheers /R On May 16, 8:32 pm, Ross Smith <[email protected]> wrote: > @Richard, that makes sense. The nested nature of the assets eluded me when > I first wrote this question. > > The jist of my question revolves around the difference between retrieving > and instancing an asset vs. a resource. AssetLoader dispatches a > RESOURCE_COMPLETE event when a stack of dependent assets pertaining to a > single, initial load request has finished. I don't see a facility in here > (other than the namespace) to index that top-level resource for later > retrieval and duplication. For my client application, it's more useful to > have handles to those top-level requests than to their more granular > dependencies, which is what threw me with the "name" property at the start. > > If I could retrieve that top-level resource request and the tree of > dependent assets it loaded, I could easily clone it and drop it into my > scene. Alternately if I can retrieve all the assets in a given namespace I > could write the code to do that myself (which I've been trying to do, to > some success). And if it's my job to write that to the specific logic of my > application, that's a fine answer and I'll take it. Either way, thanks for > the patience :) > > > > > > > > > > On Mon, May 16, 2011 at 2:16 PM, richardolsson <[email protected]> wrote: > > @Ross: > > > It is unfortunately absolutely impossible to create a general-purpose > > way to define a name before loading a resource. Most file formats can > > contain more than one asset (at the very latest, a resource usually > > consists of at least a single mesh, one material and one bitmap.) > > Which of these assets would get the name? As you can imagine, there is > > no way for us to dictate such a thing, so you need to take care of > > that yourself, because you are the only one who knows what you're > > loading. > > > The easiest way, like Choons is suggesting, is to listen for > > ASSET_COMPLETE and pick a name that you like in that event. > > > Cheers > > /R > > > On May 16, 7:11 pm, Ross Smith <[email protected]> wrote: > > > Hello, > > > > I've been surfing through the AssetLibrary, AssetLoader, > > AssetLoaderToken, > > > etc files and looking for where the name of a loaded asset is set. I'm > > > trying to help myself before I take a question to the list, and this one > > has > > > me stumped. I can't find a way to associate a name to an asset at the > > time > > > that I pass a URLRequest into AssetLibrary.load(). Ideally I'd like to > > name > > > the asset so I can inspect its load state. > > > > At the moment I'm writing my own asset management class to interface with > > > AssetLibrary to obtain this functionality via an associative array of > > > AssetLoaderTokens. I'd rather do it the library's way than my own, if > > the > > > library does or will support this :) > > > > Thanks again for all the work done on Broomstick! > > > > -- > > > Ross Smith > > > [email protected] > > -- > Ross Smith > [email protected]
