Hey Pedro,
As you might have already figured out collada is supported via the Mesh components mesh ref attribute. So instead of using Ogres .mesh as the ref, you can also use .dae files. It will read the .dae mesh and if the .dae references to textures it will load them. The texture refs can be relative to the .dae file itself or be URLs to point into other web resources. This is how I understood it from looking at the code anyways (I didnt code this myself). So the dae itself can be hosted on the web and used as http ref, if it has relative texture refs like "images/my.png" it will look for them with the location of the .dae as the base. If textures are found, in memory materials are generated with the texture and set to the mesh. You can also override with your own material by setting the Mesh components materials as usual.
Tundra AssetAPI got a new "asset bundle" concept. This means that we now have a notion of assets that actually serve other assets. When I made this I thought "bundle" might be good name for it. Anyways, the new plugin ArchivePlugin implements one such bundle type that knows how to handle .zip files and provide sub assets from inside of it. This is all done via the new IAssetBundle interface and we can add other types of bundles in a similar fashion with other plugins in the future.
I guess I went into little too much detail there, here is how you use them: Any asset reference in Tundra can now point to inside a zip file, and I do mean any, its totally transparent to the code that is using/requesting the assets. So for example you have a Mesh component that has:
wall.mesh as the mesh ref
wall1.material and
wall2.material as the material refs
And lets say wall1.material has a texture ref of wall1.png and wall2.material wall2.dds
You can now zip all these files into for example myassets.zip (you decide the name, it can be anything). Then you change in your .txml or change them live in Tundra and save to a new .txml the refs to be like this:
myassets.zip#wall.mesh
myassets.zip#wall1.material
myassets.zip#wall2.material
You are done. You don't have to modify the texture references inside the materials, but the textures need to be inside the zip file next to the materials. You can also do sub folders inside your zip files, for example meshes/wall.mesh and materials/wall1.material and make the asset refs to myassets.zip#meshes/wall.mesh etc.
Now when Tundra goes to look for these assets, its going to fetch the zip file and then get the assets from there. And of course this zip can be put to the web in which case your refs would be in the form of
http://www.mysite.com/assets/myassets.zip#wall.mesh. The benefit of zipping up your assets is maxed when you use http assets. A major point of this feature was to dramatically reduce HTTP requests to the web, this will save a lot of time if you have hundreds or thousands of (small or big) web asset refs in your scene. Now you bundle everything into a single zip, we make one request to the web. Additionally the content is compressed which makes the download faster as well. One downside is that if you change, add or remove file(s) inside the zip file, our asset system will detect it has changed and refetch it from the web. This might mean a big download even if a small material file was modified/added/removed. So you might want to zip things up only after you know they wont be changed frequently. If the zip has not changed in the web source, we dont download anything but use the cached zip file and its contents.
I've seen dramatic improvements when porting scenes into zip files. I recommend it if you are using web refs and have big number of assets. For local development it wont matter too much as no downloads are made. Of course there as well it might make a difference in keeping your scenes working dir looking nice/clean and when you do put the scene to the web its already packaged.
Let me know if you have any more questions.
Best regards,
Jonne Nauha
Adminotech developer