I should imagine it would require some sort of build toolset upon importing of the alemic file - which BTW can import the mesh too - it cannot hold the skeleton data AFAIK.
When I looked it, or at least the Exorcortex version, it looked really exciting in many ways, but we had no budget so I settled for a straight forward MDD + emdl setup - we are fully softimage here. If I was to do it again and had the budget it would be the way to go with a toolset for assembly in whatever package. my R0.02 S. Sandy Sutherland<mailto:sandy.sutherl...@triggerfish.co.za> | Technical Supervisor [http://triggerfish.co.za/en/wp-content/uploads/udf_foundry/images/logo.png] <http://triggerfish.co.za/en> [http://static.ak.fbcdn.net/rsrc.php/v2/ym/x/lFV-lsMcC_0.png] <http://www.facebook.com/triggerfishanimation> [https://si0.twimg.com/a/1349296073/images/resources/twitter-bird-white-on-blue.png] <http://www.twitter.com/triggerfishza> ________________________________ From: softimage-boun...@listproc.autodesk.com [softimage-boun...@listproc.autodesk.com] on behalf of Stefan Andersson [sander...@gmail.com] Sent: 28 January 2013 16:07 To: softimage@listproc.autodesk.com Subject: Re: building asset tools Does anyone here on the list knows if you can envelope an alembic file? regards stefan On Mon, Jan 28, 2013 at 2:22 PM, Guillaume Laforge <guillaume.laforge...@gmail.com<mailto:guillaume.laforge...@gmail.com>> wrote: > As far as technicalities go, I'd go for FBX for storing hierarchies of > objects. Hierarchies can be saved using Alembic too. It is a format to bake scenes after all :). FBX "advantages" are that you don't bake the meshes as they keeps their envelope and use the DCC specific code to do the skinning. It can be very useful if you do the skinning in a package and the rigging in an other one. But for every validated assets, I won't use such format as you can't be sure your animation will be the same at the end of the pipeline. The optimized point cache approach of Alembic is much better. Cheers, Guillaume Laforge On Mon, Jan 28, 2013 at 4:15 AM, Michal Doniec <doni...@gmail.com<mailto:doni...@gmail.com>> wrote: "I would say, the most important is to make the right difference between the asset and the file on disk. The asset is just a concept, often just an entry in whatever storage unit you choose with metadatas and bind to a file on disk." I can only second that. The most common design mistake I see in data/asset management systems is treating files on disk as the higest level assets. Having a higher abstraction level ("asset is just a concept") from the beginning is really beneficial in many cases, including the one pointed out by Jo and will for sure lead to much simpler code. If you decide to treat ordinary disk files as assets, I can guarantee you will end up with a layer of "super assets" or asset collections, packages (call it what you want) sooner or later. As far as technicalities go, I'd go for FBX for storing hierarchies of objects. The format has a future, is expandable, but be prepared to deal with some oddities and bugs from time to time. At my previous place, all pipeline was mostly fbx based for rigs and similar. Cache format, Alembic is imo the best choice. On 27 January 2013 20:39, jo benayoun <jobenay...@gmail.com<mailto:jobenay...@gmail.com>> wrote: hey Stefan I would say, the most important is to make the right difference between the asset and the file on disk. The asset is just a concept, often just an entry in whatever storage unit you choose with metadatas and bind to a file on disk. So to keep things simple, why not considering your asset as a zip archive on disk, in which you may use different file formats to store datas depending on the type of the asset and the application it's most often used in. Bundled with the archive, add it a json/xml/whatever file used to store the metadatas (creator, ctime, asset-type, ...) It becomes easy then when an asset is wanted to retrieve the adequat file (if exists) or run a converter (if needed). This allows you to keep application-specific file formats while not having trade-offs on their re-use in others by abstracting. Your asset manager don't know about the files but only about <assets>. Dont bother with file formats but make your asset manager enough solid to handle whatever is used underneath to store datas. --jon 2013/1/27 Stefan Andersson <sander...@gmail.com<mailto:sander...@gmail.com>> Hello everyone, I'm building a set of tools for a asset manager for Softimage. I've had it working in Maya for a while, but I'm now converting it and re-writing it to fit Softimage. I'm quite tempted to use Collada as it's a xml format and pretty easy to work with. But I would like to hear what everyone else is using? I need to be able to export it as collada or fbx for the model assets so that it can be imported into other applications. The Rig/Sim assets will be native emdl as they are only going to be used in softimage (though I have my issues there too...). A few things my exporter is doing are * exporting MatLib with all materials * exporting ColladaXML * exporting/converting images to exr (via OIIO) * parse MatLib and fix the filepaths for the textures (pointing at asset location) Big plus for using Collada * will work with most applications * can be used in Softimage as Reference * xml based Big plus for FBX * will work with most applications Big Minus for FBX * can NOT be used in Softimage as Reference * not a xml format (need to make your own parser) Big Minus for dotXSI * tends to crash other applications when importing dotXSI Big Minus for emdl * binary, impossible to edit So all of the above points towards Collada, but what do you guys think? Any takers? regards stefan -- Stefan Andersson | Digital Janitor blog<http://sanders3d.wordpress.com> | showreel<http://vimeo.com/sanders3d> | twitter<http://twitter.com/sanders3d> | LinkedIn<http://www.linkedin.com/in/sanders3d> | cell: +46-73-6268850<tel:%2B46-73-6268850> | skype:sanders3d -- ---------- Michal http://uk.linkedin.com/in/mdoniec -- Stefan Andersson | Digital Janitor blog<http://sanders3d.wordpress.com> | showreel<http://vimeo.com/sanders3d> | twitter<http://twitter.com/sanders3d> | LinkedIn<http://www.linkedin.com/in/sanders3d> | cell: +46-73-6268850 | skype:sanders3d
