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