Why I'm about to break your code - ResourceManager replacement

[Richard Olsson]

Hello Away3D community!

This is a heads up that in a moment, I will be pushing changes to the GitHub repository (SVN will follow in the next couple of days) that will likely break any code that you have that uses Broomstick (Away3D 4.0 alpha). This is because of some major incompatible changes that we're making to the way that assets are loaded and managed in Away3D 4.0. (In the unlikely event that your code doesn't load assets at all, it might be unaffected.)

We wanted to make these changes right now, while Away3D is still in alpha, and we believe strongly that this is the best loading framework that we have ever had in Away3D (and probably better than most if not all competing engines out there.)

The short version is that we have removed the ResourceManager (which you are probably currently using to load assets) and replaced it with three different classes that can be used for loading: The AssetLibrary (with asset management features), the AssetLoader (for simple loading of files including dependencies) and the Loader3D (for easily loading assets into a scene.)

For those interested in a slightly longer description of the new loading framework, I have attached a five page PDF outlining the design principles, features and basic usage of the new loading classes. We hope this will ease your transition while waiting for proper documentation.

Remember that Away3D 4 is still alpha, and things might still change, but we feel a lot more comfortable with the new solution, and I think that we will be able to keep it more or less stable through to the final release of Away3D 4.0.

The examples have been updated as well (all apart from the ones that use MD5, so those are still broken. Please bear with us while we fix them.) Example code for the AssetLibrary, AssetLoader and Loader3D will be coming shortly as well.

Thanks for your understanding, and if you have any questions, comments, feature requests or bug reports: Fire away! ;)

/Richard, Away3D

[Choons]

Thanks, Richard. Glad to see you guys are willing to bite the bullet
and rework areas to make Away3D better. And thanks for the
documentation as well. Last year I was trying to develop an app on the
YouTube API and they would push out changes without informing the
community. My code would break and I had no idea why. Looks like
developers can count on the Away3D team to keep us in the loop.

>  LoadingInAway4.pdf
> 147KViewDownload

[Michael Iv]

Well Richard , I want to believe the people here understood from the beginning what "Alpha" means . Otherwise you should watch your back walking on the streets ;)
Good work !

Sent from my iPhone

[Apprentice]

Thanks for letting us know :)
And for putting a document online which describes the changes in depth
(which I have yet to read carefully).

>  LoadingInAway4.pdf
> 147KWeergevenDownloaden

[themightyatom]

This is great news :)
So far I've had to nobble the ResourceManager quite a bit to get it to
work for me,
as assets only loaded once, and I could never seem to get the
reference to clone.
Maybe now I can use it out of the box ;)
Thanks very much for the docs, will save hours of code diving and
experiments...

Cheers

Pete

[richardolsson]

Cheers guys!

The document mainly outlines the changes between Away 3.x and this new
solution, so not so much the transition from ResourceManager (the
previous alpha solution that this one replaces) to AssetLibrary.

However, the ResourceManager really didn't do much before, so I don't
think that modifying your code for the AssetLibrary will require much
work once the general understanding is there (and that's what I'm
trying to provide through the document.) I know this from having
changed all the examples very quickly from ResourceManager to Loader3D
(which in essence is very similar to the AssetLibrary.)

Since it's not in the document, let me quickly outline the reason for
ditching the ResourceManager. With the ResourceManager we tried to do
some pretty magical things with returning proxy objects for
everything, and using the same method to load and retrieve an already
loaded resource. As we were implementing more complex file formats
(especially AWD and COLLADA) it became clear that this will not work
throughout, so we decided to ditch it in favor of a single approach
which would always work (first load, and retrieve from library only
once loaded.)

To clearly mark that we were moving away from the ResourceManager (and
the fact that we now have a library-like functionality) we decided to
rename the new manager class AssetLibrary, which is what you'll be
working with from now on.

Another important change is something that is indeed mentioned in the
document, but deserves another mention, because IT'S VERY IMPORTANT!
Away4 right now adds about 40kb to your SWF file, which is really
neat. However, with the ResourceManager, all the parsers were
forcefully included in the app adding almost 100kb. That's 200% extra
weight for parsers that you may or may not use! We decided to remove
the hard-coded parsers in favor of a plug-in approach, which is really
nice for file size (and to some extent file format detection
performance) but it does require you to do the following at an early
point in your app, e.g. if you want to use AWD and OBJ files:

AssetLibrary.enableParser(AWDParser);
AssetLibrary.enableParser(OBJParser);

If you don't care about file size, and just don't want to think about
what file formats you'll be using, you can use a short-hand to add all
the bundled parsers, which is essentially what happened automatically
in the ResourceManager:

AssetLibrary.enableParsers(Parsers.ALL_BUNDLED);

One of the above needs to happen before the first load in your app is
started.

You can use the enableParser() set of methods on AssetLibrary,
AssetLoader, Loader3D or SingleFileLoader (internal class) and they
will all end up in the same place, so if you add the above line of
code once in your app, you can then use automatic file detection in
any or all of the AssetLibrary, AssetLoader and Loader3D.


I was expecting more questions to be honest, so please don't be shy if
you are wondering anything. :)


Cheers
/R

On May 6, 8:59 am, Apprentice <s.r.r.stiefelha...@gmail.com> wrote:

[Alessandro Bianco]

the autodetection and plugin system it's really awesome. it really
could be the best loading and asset-management implementation i've
ever seen ^_^

as for the questions ...
the new async nature means that we will needto wait for the model to
completely load before adding it to the scene or use it, right?
we're goind to receive a general "complete" event from the
AssetLibrary for everything we load or we will get some kind of
reference from the AssetLibrary.load method, to add specific listeners
to it? in the former case, how can we distinguish between multiple
assets that could be loaded at the same time?

in the end i don't really understand the getAsset("meshName") method:
if we load a big model with a lot of meshes inside, we can retrieve a
singular mesh contained there, without the need of adding the whole
"world" to our scene?
we can also reference directly textures or other kind of assets?

Bianco Alessandro

2011/5/6 richardolsson <r...@richardolsson.se>:

[richardolsson]

@Alessandro:

First of all: Loading in Flash is by nature asynchronous, and the only
reason you could load a mesh and add that mesh instantly to the scene
with the ResourceManager was because what you were adding was not a
mesh -- it was a container. The parser was in charge of creating a
container and handing that back to you, and then add things to that
container as they were loading. This works ok (even though it forces
you to have a useless container) when the file that you're loading can
only contain scene objects (which is the case for many file formats.)
It doesn't work at all if the parser has no way of knowing what the
file it's about to receive will contain (which is the case for AWD and
COLLADA.)

So what we have done now is not make something synchronous
asynchronous, we have just stopped faking something asynchronous as
being synchronous, for the sake of flexibility, transparency and
stability. So now, iff you want to use misc assets that you load using
any of the loading methods you will need to wait for it to finish.

That being said however, if you just want to load things into a scene
to display it quickly, you can use the Loader3D class which has
returned from Away3D 3.x:

Loader3D.enableParsers(Parsers.ALL_BUNDLED);
var loader : Loader3D = new Loader3D();
loader.load(new URLRequest('mysimplescene.obj'));
myScene.addChild(loader);

This way you can add the loader directly to the scene without having
to wait for the load to complete. Note however that this will only
work with assets that make sense to add to a scene (i.e. models and
similar.)

The asset library is really meant for more complex apps, where you
load e.g. an entire game level from a single file, and one file
containing all the characters for example. You will then be able to,
like you're guessing, to retrieve a single "asset" (mesh, material,
texture, animation et c) using the getAsset() method and the name of
that asset.

All loader classes dispatch LoaderEvent.RESOURCE_COMPLETE when they
finish loading an entire resource (a file and all it's dependencies)
which you can listen for. That event contains a "url" property that
you can use to distinguish loads from each other. The AssetLibrary
also returns a token (currently an AssetLoader, but this is likely to
change) on which you can listen for load events if you want to
distinguish loads from each other in another way than using the URL:

var token : EventDispatcher;

token = AssetLibrary.load(new URLRequest('mymodel.awd'));
token.addEventListener(LoaderEvent.RESOURCE_COMPLETE, onComplete);

Alternatively, you can listen for the AssetEvent.ASSET_COMPLETE on any
loader class, and it will be dispatched for every single
"asset" (mesh, material, animation et c) in a resource (file) as they
are encountered by the parser. If the asset (which is in the event's
"asset" property) is of assetType AssetType.MESH for instance, you
know that you should likely add it to the scene. This is actually what
Loader3D does internally.

Make sure you have a look at the document in my original post in this
thread, as it may contain more useful information!


I hope this helps!

Cheers
/R

[Alessandro Bianco]

It sure helps a lot! Thanks for the explanation

I know that the previous synchronous way was achieved by using a
container and, even if it's quicker to use in some circumstances, I
like the new async mode a lot more.
That said, I'm glad we would still be able to use the dirty way with
Loader3D for simpler tasks.

Even the rest of the inner logics is very clear and it really makes
sense to me. Being able to listen to events from a specific loading
request and knowing which kind of assets are being completed are great
features.

Just another quick question:
In case multiple resources sharing a common asset name, what will happen?
For example, for some reason I load two car models, both with meshes
named "body", "wheel" etc. how do i decide which one to retrieve via
getAsset("name") ? I'll have to use the multiton nature of the
AssetLibrary or it has something to do with the AssetLoaderContext?

btw, great work, can't wait to test it :)

Bianco Alessandro

2011/5/6 richardolsson <r...@richardolsson.se>:

[John Brookes]

Confused with the AssetLibrary thang.
from the pdf
// To load
AssetLibrary.load(new URLRequest('path/to/my/file.awd'));
// Once load has finished
var mesh : Mesh = Mesh(AssetLibrary.getAsset('nameOfMyMesh'));

Also tried the example in this thread.

If I do the above I get an error
[Fault] exception, information=Error: Unsupported file type:../models/hp2/hp2
Fault, AssetLibrary.as:197

Really could do with a full example.

[John Brookes]

whoops
forgot the
Loader3D.enableParser(AWD1Parser);

working now :)

[richardolsson]

@Alessandro:
This is not properly documented yet, because it's not properly
implemented yet, but if two assets with the same name are parsed into
the library, the default behavior is that the second one will be
renamed. Exactly how is not decided yet, and will be configurable
using strategy classes, but it will by default be something like
"originalname_1".

All assets however still have an originalName property, which will be
the name that the asset had in the original file. You can use this in
your ASSET_COMPLETE handler to identify it and store a reference to it
in a variable if you want.

This however can all be circumvented using what we call "namespaces".
When you use the load() and parseData() methods, you'll see that the
fourth (I think) parameter is one called "namespace". You'll also see
the same parameter in getAsset(). By default no namespace (null) is
used, but if you know that you need to load two cars that each will
contain "body" meshes, you can specify different namespaces for the
two loads.

AssetLibrary.load(new URLRequest('car1.awd'), null, null, 'car1');
AssetLibrary.load(new URLRequest('car2.awd'), null, null, 'car2');

Then if you want to retrieve the body of the first car, you'll know
that it's in the "car1" namespace:

AssetLibrary.getAsset('body'); // Looks in default namespace, nothing
found
AssetLibrary.getAsset('body', 'car1'); // Finds body of first car
AssetLibrary.getAsset('body', 'car2'); // Finds body of other car


Hope this helps!

Cheers
/R

[Alessandro Bianco]

that's awesome :) couldn't be simpler and powerful

thanks for these insights Richard, can't wait to see it in the svn to
start playing with

[richardolsson]

@Alessandro:
I'm glad you like it! Are you aware that GitHub lets you very easily
download a ZIP file so you can get the source from their (and just
unzip into your src folder) even if you don't actually use Git.

See download button in top right on this page: https://github.com/away3d/away3d-core-broomstick

Cheers
/R

[Alessandro Bianco]

yep i know, thanks, but i like to keep my libraries connected to the
source, so i can keep track of changes and update easily

i could make an exception for this time, we'll see :) it depends if i
find the time to play before the svn is updated or not

btw, I guess that soon or later i'll have to give up and start using
git, the rest of the world demands it :)

[John Brookes]

Loading an awd1

private function onLoadComplete(e:LoaderEvent):void
{
    var m:ObjectContainer3D = AssetLibrary.getAsset("main") as ObjectContainer3D
    view.scene.addChild(m);
    trace(m.getChildAt(0).name) //traces SimpleTruck_TrailerPivot0

Which works fine
but if I try instead

    var m:ObjectContainer3D = AssetLibrary.getAsset("SimpleTruck_TrailerPivot0") as ObjectContainer3D
    view.scene.addChild(m);

It throws an error Error: Parameter child cannot be null.

[John Brookes]

Traced out asset name in asset library and I see it only does the main container.

[John Brookes]

Just to add to the fun.
Cannot get it to pick up the mtl file from an OBJ.
Tried various paths/locations.

[McFunkypants]

Wonderful work, Richard! Thanks so much for all your time and
effort. The old system was just terrible.

I have a request that will serve the needs of many people in the
future: a way to FORCE the model names on loaded objects. Useful when
you don't know what the names are or when using file formats with no
names in them like obj. Same as how you allow us to force the
namespace but a way to actually force the 1st model inside to have a
particular name as well. Tons of exporters mangle obj names or put
invalid characters in them etc. I'd love to just use whatever name I
pass your parse function as the getAsset() parameter. Or at the very
least, a way to programmatically query what model names are in there
so we don't have to know them ahead of time.

Also, many devs (everyone who sells flash games for licensing on game
portals or FGL for example) are forced to include all assets inside
the swf. No external files. So I would be eternally grateful, and
promise to sing of your bravery and valour for the rest of my days, if
you would be sure to test that [EMBEDDED] models (including textures
and mtl files too) work really well using the new loader routines.

I would never dream of making a game that downloads external textures
or model files or mtl files. Everything always has to be inside the
swf for my client work, since kongregate, newgrounds, shockwave,
miniclip, armorgames, etc all force you to only upload a standalone
SWF.

Games that are allowed to download external files will be in the vast
minority. Your target demographic will use [embed] more often then
urlrequest.

Keep up the wonderful work. YOU ROCK!

T H A N K Y O U ! =)

[richardolsson]

@John:
OBJ mtl files have some known issues, but they should work (albeit
internally incorrectly, it ignores the AssetLoaderContext) so please e-
mail me and we'll try to debug it together, e.g. by tracing the path
that it's trying to load and hopefully finding why it fails.

As for your container issue, the AWD1 parser may need some work to
conform to the new system (reporting every asset it finds instead of
just the top-level container.) I have been adapting all the parsers so
far, even those that I have no idea how they work, so there might be
issues like this at this point. Will talk to Fabrice about the AWD1
parser and getting it to report assets correctly.

@McFunkypants:
As for forcing the name, I'm not sure that's something that makes a
lot of sense as a general solution because many file formats contain
so many assets and we can't give the same name to all of them, so then
it would be up to the parser which one should get the "forced
name" (probably the first) and since that means the user (you) will
lose control of which asset gets renamed I can't really see it as a
general purpose feature.

However, if you listen for the ASSET_COMPLETE event, you can yourself
rename the first asset if you want, or try to conclude from the
assets' types which one it is that you want to rename. That makes more
sense to me because it gives you all the control.

As for embedding, see the document in my original post in this thread
(and the section called "Embedding files and dependencies"). You'll
see that the support for embedded data is just as powerful as it is
for external data. You can even embed a file with dependencies (e.g. a
AWD file that references textures) and then through the help of an
AssetLoaderContext instance map the dependency URLs in that file to
other embedded files! When it loads it will be just as if it was
loading all the files externally, but the mapping mechanism will tell
the system not to look for the files at some URL, but in memory
instead. I believe this to be a very powerful feature for developers
in your situation. Check it out! :)


Cheers
/R

[John Brookes]

Think I've solved the obj mtl issue

before I was doing AssetLibrary.load(new URLRequest(LEVEL_URL)) and it failed.

This is working, no missing mtl error.
eg
private var LEVEL_URL:String = '../src/indi001/object/IndiEstate6exp.obj';
levelfile =    AssetLibrary.load(new URLRequest(LEVEL_URL),new OBJParser("../src/indi001/object/"));


But then after doing that realised that I would have to add each part of the level. As there isn't (or I dont know) how to say just add the whole thang. Plus not knowing what the part names are makes it a nightmare. (obj1...30). Tried grouping the whole model and then adchild(obj0) but that didnt work.

Anyhoo
Im only using obj as it good for a quick test going from maya, so for now Ill change that bit to a basic loader3d.

carry on :)

[richardolsson]

@John:
The OBJ mtl support is not properly implemented in the OBJParser yet.
There is a automatic dependency loading system inside the AssetLoader
that parsers generally use to have dependencies loaded, but it is
bypassed for mtl files (OBJParser goes rogue and loads it itself ;))
and that will be changing. So don't rely on the constructor parameter
on OBJParser for the long run. I will be removing it shortly after I
have fixed the OBJParser to conform to the dependency system's
rules. :)

Once OBJParser adheres to the general dependency loading system, you
will be able to achieve the same thing using the
AssetLoaderContext.dependencyBasePath property, which is how it works
for other parsers.


Cheers
/R

[McFunkypants]

> "You can even embed a file with dependencies"

So freaking incredible. THANK YOU SO MUCH.
This was exactly what I was hoping for.
Sending you five buckets full of love and respect.
- McFunkypants

[richardolsson]

@McFunkyPants:
I'm happy to hear this! :) I wasn't actually thinking about game
developers when I came up with this feature. It just came to me. But I
can see how it makes a lot of sense for you. So please keep throwing
feature suggestions at us because you are the people that actually use
the engine (sure, I do too of course) and know what features would
make your life easier. We can't guarantee that we will solve every
problem (because you need to do some programming too ;)) but if it is
general-purpose enough and makes sense as an engine feature chances
are that we'll add it!

Cheers
/R

[richardolsson]

@John:

Just wanted to let you know that today I pushed the dependency-loading
improvement that I mentioned before. It's on GitHub now and should be
propagated to SVN before too long.

This means that you will no longer be able to specify a "resourcesUrl"
for OBJParser. Instead, you should rely on the regular
AssetLoaderContext.dependencyBaseUrl property to define where the
loader should look for MTL and texture files.

If you need greater granularity than that we have also recently added
a AssetLoaderContext.mapUrl() method to map one dependency URL to
another. You can also still map a URL to embedded data using the
AssetLoaderContext.mapUrlToData() if you prefer to embed your
dependencies.

Let us know if you have any thoughts about Away3D in general or the
loading framework in particular! :)


Cheers
/R

On May 6, 10:08 pm, John Brookes <jbp...@googlemail.com> wrote:

[Choons]

I've been struggling with the new AssetLibrary this evening-

Mesh = Mesh(AssetLibrary.getAsset('nameOfMyMesh'));

if I understand correctly, the name comes from within the file that is
loaded. Experimenting with the lostsoul.md5mesh from the examples, I'm
not clear on where a name would come from looking at the contents of
that file. It's not a format I am familiar with. How do I query the
Asset Library from code to get a list of the names of the assets in
the library?

[richardolsson]

@Choons:
The name can come from wherever (just set it through the name
property) but usually it will likely be coming from the parsers (and
ultimately the files that they parse). The problem is that some file
formats don't provide names for the contained asset(s). MD5 is one of
those. That's a shortcoming of the file format and not something that
we can reliably solve in Away3D without completely shifting control
away from you, and that's usually a bad idea since we are after all
creating a library for programmers. :)

So what you need to do if you want to use a file format in which there
are no names (or the names are not satisfactory) is to listen for the
ASSET_COMPLETE event, and rename the assets as they come in according
to some scheme of your choice. When you get a mesh
(event.asset.assetType == AssetType.MESH) you can for example rename
it "nameOfMyMesh" and then you'll be able to fetch it by that name
from the asset library.

Something similar will soon be done automatically by the parsers, i.e.
if there is no name for an asset the parser will give it a name
according to it's type (e.g. just "mesh" for meshes.) This way you
know that regardless of the file format, originally unnamed assets
will have a consistent scheme for fallback names.

I am at this very moment working on the mechanisms that will make sure
that there are no collisions between name/namespace pairs in an asset
library. This, along with the parser tweak mentioned above will likely
be pushed before the end of today (CET).


Cheers
/R

[Choons]

OK after further experimentation with the AnimBlendTest example, I
managed to get it to load the model from the lostsoul.md5mesh file
with

AssetLibrary.enableParser(MD5MeshParser);
AssetLibrary.addEventListener(AssetEvent.ASSET_COMPLETE,
onMeshComplete);
AssetLibrary.load(new URLRequest("..assets/lostsoul/
lostsoul.md5mesh"));

function onMeshComplete((event : AssetEvent) : void {
if (event.asset.assetType == AssetType.MESH) {
mesh = event.asset as Mesh;
}
}

however, tracing event.asset.name when onMeshComplete fires only
returns 'untitled' so clearly a name isn't getting picked up by the
loader from the input file. I was able to assign and trace back a name
by using event.asset.name = "lostsoul_mesh" but don't know yet whether
it has scope outside of onMeshComplete

[John Brookes]

@ richard
MAybe im doing this wrong

Loader3D.enableParser(OBJParser);

var context:AssetLoaderContext = new AssetLoaderContext(true, "../src/");
var objFile:EventDispatcher =  AssetLibrary.load(new URLRequest('../src/objTest.obj'),new OBJParser(), context);

objFile.addEventListener(AssetEvent.ASSET_COMPLETE, assetComplete); //never fires
objFile.addEventListener(LoaderEvent.DEPENDENCY_COMPLETE, dependancyComplete);
objFile.addEventListener(LoaderEvent.RESOURCE_COMPLETE, onComplete);

works apart from asset complete doesnt seem to fire.

BUT
Try loading an obj file that has mtl, but the mtl doesnt use textures (images)
It ends up trying to load the obj file.

TypeError: Error #1034: Type Coercion failed: cannot convert "# This file uses centimeters as units for non-parametric coordinates.

mtllib test2obj.mtl
v -2502.885766 0.000014 -600.490442
v -743.613427 0.000014 -600.490442


If you change AssetLoaderContext(false, "../src/"); (False)
No error but.
It doesn't load ( no events fire)

[John Brookes]

Ahh nice one choons
AssetLibrary.addEventListener(

AssetEvent.ASSET_COMPLETE,

asset event fires :)

But the imageless mtl issue is still there.

[Choons]

woops- guess you replied while I was typing ; ) Yeah now I see how it
works. Knowing how to query if there was a name and getting the return
of 'untitled' and then being able to set a name is what I needed to
clarify it. This approach is going to be perfect for handling COLLADA
assets

[richardolsson]

@John:
Are you getting sources from SVN or Git? When did you last update/
pull?

Can you send me the OBJ file and it's dependencies (MTL and textures)?


Cheers
/R

[richardolsson]

@Choons:
You won't have to do this in the future (unless you want to control
the generic names) because the parsers will always set generic names
like "mesh", "material" et c instead of "untitled". To prevent
collisions, the library will then rename them "mesh", "mesh.1", "mesh.
2" et c.

/R

[John Brookes]

From git,download from page, about an hour ago.
Just checked and theres no diff between

https://github.com/away3d/away3d-core-broomstick/blob/master/src/away3d/loaders/parsers/OBJParser.as

And the one im using to test

[Choons]

cool, Richard. I'm really beginning to wrap my head around Away3D's
design philosophy. Amazing work you guys have done

[richardolsson]

@John:
Thanks a lot for the OBJ/MTL files. I have investigated this issue and
found that it was not actually an OBJ related problem, but rather a
pretty nasty bug that could occur for any file format and cause the
dependency loading stack to get out of synch. I have fixed it and
pushed the fix to GitHub, so please download the latest version there
and try again. Let us know if the issue (against all odds) should
remain. :)


Cheers
/R

On May 14, 12:40 pm, John Brookes <jbp...@googlemail.com> wrote:
> From git,download from page, about an hour ago.
> Just checked and theres no diff between
>

> https://github.com/away3d/away3d-core-broomstick/blob/master/src/away...

>
> And the one im using to test
>

>  obj.rar
> 15KViewDownload

[John Brookes]

Yep working fine.

Another thing is still the issue with awd1.
It doesnt set any child meshes of the 'main' container as assets.
It just does the main container and the images but not the child meshes.

Simple awd1 example in rar
cant get pCube1 or any of the meshes.

[fredrik]

I think this is really nice news!

But there are some mysteries to me. Perhaps these things just are not
implemented yet, but I would still like to point out some of the
troubles I had when using the new model loading the assets.
a) I see there are no events beeing dispatched for the loading
progress. (It would of course be nice to have some possibility to
provide some feedback to the always impatient user.)
b) I also wonder how I should be able to access the loaded asset (an
image texture for example) in the AssetLoader. In the the old
ResourceEvent there was a resource object from which I could extract
the needed bitmapdata.

Thanks for a wonderful work with the framework!

/Fredrik

On 5 Maj, 20:01, Richard Olsson <r...@richardolsson.se> wrote:
> Hello Away3D community!
>
> This is a heads up that in a moment, I will be pushing changes to the GitHub repository (SVN will follow in the next couple of days) that will likely break any code that you have that uses Broomstick (Away3D 4.0 alpha). This is because of some major incompatible changes that we're making to the way that assets are loaded and managed in Away3D 4.0. (In the unlikely event that your code doesn't load assets at all, it might be unaffected.)
>
> We wanted to make these changes right now, while Away3D is still in alpha, and we believe strongly that this is the best loading framework that we have ever had in Away3D (and probably better than most if not all competing engines out there.)
>
> The short version is that we have removed the ResourceManager (which you are probably currently using to load assets) and replaced it with three different classes that can be used for loading: The AssetLibrary (with asset management features), the AssetLoader (for simple loading of files including dependencies) and the Loader3D (for easily loading assets into a scene.)
>
> For those interested in a slightly longer description of the new loading framework, I have attached a five page PDF outlining the design principles, features and basic usage of the new loading classes. We hope this will ease your transition while waiting for proper documentation.
>
> Remember that Away3D 4 is still alpha, and things might still change, but we feel a lot more comfortable with the new solution, and I think that we will be able to keep it more or less stable through to the final release of Away3D 4.0.
>
> The examples have been updated as well (all apart from the ones that use MD5, so those are still broken. Please bear with us while we fix them.) Example code for the AssetLibrary, AssetLoader and Loader3D will be coming shortly as well.
>
> Thanks for your understanding, and if you have any questions, comments, feature requests or bug reports: Fire away! ;)
>
> /Richard, Away3D
>
>  LoadingInAway4.pdf
> 147KVisaHämta

[richardolsson]

@Fredrik:
Thanks for your input! To answer your questions:

a) Loading progress is something that will be added at some point, but
it's a bigger issue than one might realize at first thought. I've
explained it in another thread (
http://groups.google.com/group/away3d-dev/browse_thread/thread/994b415c554b7c9e/ee8544570f7aaee2
) but would love to have more input on how the community would like to
see it work. The most reliable way I see is to provide a set of
properties called numFilesLoaded and currentFileProgress. It will then
be up to the programmer (you) to decide whether you want a loading par
that only cares about currentFileProgress (i.e. will jump back to zero
for every dependency) or if you want to calculate the total progress
from knowing the number of files:

p = (loader.numFilesLoaded + loader.curFileProgress) / numFiles;

b) If you are using the AssetLoader, you will need to listen for the
ASSET_COMPLETE event that will be fired every time the parser finds an
asset (e.g. a mesh, material, bitmap et c) in the loaded resource
(including dependencies.) If you are using the AssetLibrary, all
assets will be added to the library and you can wait for
RESOURCE_COMPLETE and then retrieve the assets using getAsset().

Not all parsers currently report all assets correctly (i.e. some only
report the top-level container but not the contained meshes, some
ignore to report texture bitmaps et c) so the implementation is not
completely reliable at this point. If you find any issues, please let
us know!


Cheers
/R