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> 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> 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 <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>
>>>
>>>> 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

Reply via email to