> > 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. >
Conceptually we're talking about the same thing, I think. I want to populate my scene with barrels, toys, balls, etc - created in Blender and exported as a set of OBJs. My theory is that I can reduce load time by loading each of these things once, though I'll need lots of copies of them running around in the application. I was taking the approach that the AssetLibrary could be used to batch pre-load all these OBJs and their dependent materials, and once preloading was finished, I could begin instancing and positioning these objects with code. After I started down that track I found no way to retrieve my "barrel.obj", etc from the AssetLibrary. How would you approach this - specifically, retrieving and duplicating loaded models? It seems like a routine thing to do, and I'm over-complicating it. > > 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] -- Ross Smith [email protected]
