a static pause could be technically correct though ;)
On Mon, Jan 28, 2013 at 8:32 AM, Guillaume Laforge < [email protected]> wrote: > > static pauses > static poses... > > (long time since I did my last character pose I guess) > > > On Mon, Jan 28, 2013 at 9:31 AM, Guillaume Laforge < > [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]>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]> 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]>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 dis*k." >>>>> >>>>> 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]> 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]> >>>>>> >>>>>>> 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 | 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 >>> >>> >>> >> > -- -=T=-
