Hi David, what is your recipe for getting alembic as 'pointcache only'?, we have always found it tries to replace existing geo regardless...
N From: [email protected] [mailto:[email protected]] On Behalf Of David Barosin Sent: Tuesday, 29 January 2013 2:41 AM To: xsi Subject: Re: building asset tools We're currently using alembic from soft to soft here. Using reference models with pre existing envelopes that attach on the fly to our rigs. Alembic is basically used for point caching. Alembic has also been used here for sharing data between Soft, Max, Maya and Houdini quite nicely (cameras, animated geo...) It has been the most robust experience I've had to date compared to FBX or any other data format. The speed can be a little slow if you're also using alembic to generated the topology per frame but for point cache only purposes it's very nice. What are you referring to regarding Maya Alembic? I haven't heard the good side of it. On Mon, Jan 28, 2013 at 10:58 AM, Stefan Andersson <[email protected]<mailto:[email protected]>> wrote: So Maya Alembic wins again... On Mon, Jan 28, 2013 at 3:31 PM, Guillaume Laforge <[email protected]<mailto:[email protected]>> wrote: You can't 'out the box', but you could store all the envelope weights and static pauses using some Alembic properties. The main problem would be that you would need to interpret those new properties in every DCCs alembic plugin too... So, in short the answer is no :). Guillaume On Mon, Jan 28, 2013 at 9:07 AM, Stefan Andersson <[email protected]<mailto:[email protected]>> wrote: 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> 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<tel:%2B46-73-6268850> | skype:sanders3d -- 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
