working with parsing in some 3ds files using the AssetLibrary and am noticing something that doesn’t make sense to me. In the ASSET_COMPLETE event if I’m watching assetType I see the relative path to my texture jpg and its type is reported as ‘bitmap’. However, in the RESOURCE_COMPLETE event, if I do trace(AssetLibrary.getAsset(”../blahblah.jpg”) it returns its type as [object BitmapDataAsset]. It certainly isn’t possible to simply say var testBmp:Bitmap = AssetLibrary.getAsset(”../blahblah.jpg”). So isn’t this confusing?

BitmapDataAsset is not a Bitmap, which is why you can’t do getAsset() and expect to receive a Bitmap. Whether this is confusing or part of learning API I’ll leave for you to decide.

However, it should be noted that BitmapDataAsset will be removed any day now, as part of a refactor that is right now brewing in the “texturerefactor” branch on GitHub, and which basically means that all material sources (e.g. bitmaps, videos et c) will be separated as “textures”. This means that BitmapDataAsset is being replaced by BitmapTexture as the type of asset that is returned by all the parsers. And (in a more logical way than with BitmapDataAsset) the texture base class is also the type that is expected by materials for normal maps et c.

This means that you will be able to do:

myMaterial.texture = AssetLibrary.getAsset(‘tex.jpg’) as BitmapTexture;

This has a number of other (and arguably more important) side effects, for example that memory managing (e.g. reusing) textures will now be up to you.

thanks for the reply, Richard. I would ask in that case that the asset type it returns not be ‘bitmap’ then. It’s definitely confusing to see a name like myTex.jpg and a type reported as ‘bitmap’ and yet have every approach used normally in Flash to manipulate such objects fail.

I wouldn’t really think it’s a problem, because the assetType property is not returning a class name, but an abstract enumeration of different types of asset. That said, this is a non-issue because assetType for textures after the refactor (as you can see in the “texturerefactor” branch) are in fact AssetType.TEXTURE, which is the string “texture”.

It should be noted that BitmapDataAsset was never meant to be treated as a native Flash object (exactly like Mesh, Geometry, MaterialBase et c are also “custom” classes.) So it is a misunderstanding that you should be able to do anything like AssetLibrary.getAsset(‘myBitmap’) and receive a flash.display.Bitmap or flash.display.BitmapData. The above returned a BitmapDataAsset, which in turn as a bitmapData property which is the bitmap data.

I see how you would argue that this is not ideal, because it never was, but with the texture refactor we will have a much superior system, and I hope you’ll agree with that.