:) On Mon, Jan 28, 2013 at 9:36 AM, Eric Turman <[email protected]> wrote:
> 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=- >
