I want so learn details about the AssetLibrary
especially:
-What happens if i load the same .awd file over and over again via the AssetLibary? Does it effect memory usage or performance in a negative way?

JaykopX - 23 February 2015 11:19 AM

-What happens if i load the same .awd file over and over again via the AssetLibary? Does it effect memory usage or performance in a negative way?

Afaik, it will accumulate in the air memory.
Each time you load the awd file, it creates a new instance for each object in it. Keep your assetlibrary clean.

OK, i just went through the Assetlibrary with an interator and yes, it duplicates every asset from the .awd file. Now i want to load several .awd files. In general they have different geometries, but share the same materials. How can i tell the assetlibary to not load or maybe discard assets if a name conflict occurs(e.g. to avoid having the same Texture loaded).
I’ve looked into the ConflictStrategy property of the AssetLibrary, but i cannot see any of the 3 solutions fit my problem. Any suggestions? ty

i would load it outside of the library, iterate through it, and save its contents to the library unless of a naming conflict. otherwise just set your meshes in the other awd file to be using a color material or something and assign the textures manually. :/

hmmm, ok. That is really unfortunate, since an AssetLibrary should be able to manage this(i think implemented as a forth ConflictStrategy.DISCARD could work, but dont know about the internal stuff.). If i have to do it all manually, then there is little point using the Library at all.

Could your explain your solution more detailed?
Do you mean loading via “Loader3D(false, null)”, so it does not take the AssetLibrary into account and then listen to the AssetComplete event of Loader3D?

Well, now i wrote this code to fullfill my goal. What it does: it loads all resources one by one and if a naming conflict occurs it disposes the asset. If all resources were loaded, it will call a previous passed function. It works as expected, but i don’t know if i did everything right memorywise. Somebody can detect a memoryleak or some other “bad code”?

yeah that’s what i meant. you can track memory usage (as just a number) with the awaystats thing. furthermore, you can make a simple little interface to list available assets and their sizes as they complete, and like click a button to advance to the next bit by saving or discarding the asset. keep a running total of the amount of data you expect to have added by just incrementing a number with the size of assets that you intend to keep in memory. you can compare this number against the total size of assets loaded and the memory footprint in awaystats. ideally, when you start your app, before beginning the loading process you can make note of the current memory size of the empty app, then after you’ve loaded and cleaned up everything with the conflicts, you should probably expect the memory size to be: 1.) noticeably less than the total size of all the assets loaded plus the initial size (assuming of course there were duplicate assets discarded as conflicts), and 2.) slightly larger than the sum of the initial size and the total size of unique assets you’re meant to keep (to account for objects created to manage those assets.)

As for the point of the library, you may be correct that for your purposes there is little point in using it. I don’t know because I don’t know the scope of what you’re doing with these assets. You have to keep in mind what the intended function of the library is: it is a library. It’s the difference between ordering a book on amazon and pulling one off a shelf. The first identifies and brings you something you want but don’t already have. The second holds the things you already have so that when you want them you can simply reach over and grab them rather than re-ordering them and waiting for delivery. The loading classes are like amazon in this metaphor. That is all they do. You can certainly use the library to do the same thing, but that is because the library is just using those same classes in the background. If you don’t need the functionality of the library, like to manage your assets across different scenes and namespaces or something, then don’t use it. That’s like going to your public library and having them order a book they don’t already have at your expense. Why on earth would you go to the library for that when you can just order it yourself from home?

However if you are actually going to be using the library as a library, that doesn’t necessarily mean you should load from there. It’s all about efficiency. Loading through the library makes the assumption that your assets are already preprocessed to be optimized for the intersection of the loading pipeline and asset management. You have to do the work up front so that your app never has to do it in the field. This is desirable bcs loading is an extremely expensive operation, especially for flash which really only does one thing at a time. If your app has to load the same assets multiple times every single time it is deployed, it makes a lot more sense to modify your assets so that they each need only be loaded once. If for whatever reason you’re not going to do this beforehand, then the only practical solution is to take matters into your hands by loading and storing the stuff yourself.

If part of your issue with doing things this way is that it isn’t very modular or reusable to have to directly hard-code specific asset management into your app, then there is another thing you can try that will let you reuse this same code anywhere, anytime. You can easily set up an xml file to store simple associations between your assets. For example, you can identify which geometries and textures a mesh should use by simply referencing their names. That way you only need to load all your unique, named assets once without worrying about their relationships with one another, then just reference your xml to create meshes by combining those assets however you like.

JaykopX - 28 February 2015 09:18 AM

Well, now i wrote this code to fullfill my goal. What it does: it loads all resources one by one and if a naming conflict occurs it disposes the asset. If all resources were loaded, it will call a previous passed function. It works as expected, but i don’t know if i did everything right memorywise. Somebody can detect a memoryleak or some other “bad code”?

Well, I didn’t test the posted code, but I think it will probably lead to a major memory leak and unexpected assets misbehaviour.

In Away, a simple asset.dispose() doesn’t mean it will be disposed properly. Disposing a mesh does not dispose automatically all assets related to it, meaning you have to dispose its geometries, materials, textures and methods all by yourself.

Away assets are all interconnected, and by loading an AWD, the parser recreates all the relationship between their assets, linking meshes to geometries, to materials, textures and so on.

As you probaby figured out, all assets in assetlibrary, as the scene objects themselves, are linked by instances, just replacing an asset with one with the same name would not recreate all relations the original asset had. Most probably, you will end with the original asset still present in the memory/gpu, and a new one that is not linked properly.

The correct approach in this case would be, before “replacing” a mesh asset, you have to manually reassign all its related assets to the new mesh, and cascade the operation if necessary. Or the inverse approach, keep the original one, and reassign the new one.

In my opinion, without a deep knowledge of the Away’s asset structure, the most secure approach would be ignore the redundancies, dispose all the previous assets, and let the awd parser recreate the new loaded ones.

In any case, you can always use the debug profiler or Scout to detect possible memory leaks.

Thank you for the explainations. I dont really know how to profile my project to detect memoryleaks. I’m using Flash CC. What i tried instead, was creating and destroying objects over and over again. And i noticed a slight increase in ram memory usage(Created and Destroyed 10.000 Objects, increase 2~5MB). I dont think i will reach this amount of objects in my project, therefor i wont “fix” it now(i fix it when it gets messy xD). In comparision the “add everything to the library” approach from the beginning resulted in an increase of ~1MB PER object.