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 <sander...@gmail.com>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 <
> 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
>
>
>
