Re: building asset tools
For importing there is an attach to existing geometry option. The workflow we have now is using a previous version 1.0.45 and scripting the export and import thru their python api. The behavior is a bit different in the latest version. There are now export options for transformations. Without it in front of me I think it's (flat hierachy, full hierarchy and baked global) If I recall correctly I just selected the geo to export with flat hierarchy selected in the export options. In the import scene I needed the same named object to receive the operator. With nothing selected I was able to import the data with the 'attach to existing' option checked. Overall it seems to be very sensitive with object names and what is selected. When I have the time I'll see if I can get our pipeline work with the latest version. On Tue, Jan 29, 2013 at 1:40 AM, Nick Angus n...@altvfx.com wrote: Hi David, what is your recipe for getting alembic as ‘pointcache only’?, we have always found it tries to replace existing geo regardless… ** ** N ** ** *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of *David Barosin *Sent:* Tuesday, 29 January 2013 2:41 AM *To:* xsi *Subject:* Re: building asset tools ** ** We're currently using alembic from soft to soft here. Using reference models with pre existing envelopes that attach on the fly to our rigs. Alembic is basically used for point caching. Alembic has also been used here for sharing data between Soft, Max, Maya and Houdini quite nicely (cameras, animated geo...) It has been the most robust experience I've had to date compared to FBX or any other data format. The speed can be a little slow if you're also using alembic to generated the topology per frame but for point cache only purposes it's very nice. What are you referring to regarding Maya Alembic? I haven't heard the good side of it. ** ** On Mon, Jan 28, 2013 at 10:58 AM, Stefan Andersson sander...@gmail.com wrote: So Maya Alembic wins again... On Mon, Jan 28, 2013 at 3:31 PM, Guillaume Laforge guillaume.laforge...@gmail.com 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 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
Re: building asset tools
*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 | showreelhttp://vimeo.com/sanders3d| twitter http://twitter.com/sanders3d | LinkedInhttp://www.linkedin.com/in/sanders3d| cell: +46-73-6268850 | skype:sanders3d -- -- Michal http://uk.linkedin.com/in/mdoniec
Re: building asset tools
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 | showreelhttp://vimeo.com/sanders3d| twitter http://twitter.com/sanders3d | LinkedInhttp://www.linkedin.com/in/sanders3d| cell: +46-73-6268850 | skype:sanders3d -- -- Michal http://uk.linkedin.com/in/mdoniec
Re: building asset tools
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 | showreelhttp://vimeo.com/sanders3d| twitter http://twitter.com/sanders3d | LinkedInhttp://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 | showreelhttp://vimeo.com/sanders3d| twitter http://twitter.com/sanders3d |
Re: building asset tools
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.comwrote: 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 |
Re: building asset tools
I suppose you could probably attach custom float and string data to the Alembic geometry description. But you'd then need to do some work to tell the DCC to rebuild an envelope from that. On Mon, Jan 28, 2013 at 2:07 PM, Stefan Andersson sander...@gmail.comwrote: 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 | showreelhttp://vimeo.com/sanders3d| twitter http://twitter.com/sanders3d |
Re: building asset tools
a static pause could be technically correct though ;) On Mon, Jan 28, 2013 at 8:32 AM, Guillaume Laforge guillaume.laforge...@gmail.com 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 guillaume.laforge...@gmail.com 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 sander...@gmail.comwrote: 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.comwrote: *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
Re: building asset tools
:) On Mon, Jan 28, 2013 at 9:36 AM, Eric Turman i.anima...@gmail.com wrote: a static pause could be technically correct though ;) On Mon, Jan 28, 2013 at 8:32 AM, Guillaume Laforge guillaume.laforge...@gmail.com 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 guillaume.laforge...@gmail.com 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 sander...@gmail.comwrote: 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.comwrote: *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
RE: building asset tools
I should imagine it would require some sort of build toolset upon importing of the alemic file - which BTW can import the mesh too - it cannot hold the skeleton data AFAIK. When I looked it, or at least the Exorcortex version, it looked really exciting in many ways, but we had no budget so I settled for a straight forward MDD + emdl setup - we are fully softimage here. If I was to do it again and had the budget it would be the way to go with a toolset for assembly in whatever package. my R0.02 S. Sandy Sutherlandmailto:sandy.sutherl...@triggerfish.co.za | Technical Supervisor [http://triggerfish.co.za/en/wp-content/uploads/udf_foundry/images/logo.png] http://triggerfish.co.za/en [http://static.ak.fbcdn.net/rsrc.php/v2/ym/x/lFV-lsMcC_0.png] http://www.facebook.com/triggerfishanimation [https://si0.twimg.com/a/1349296073/images/resources/twitter-bird-white-on-blue.png] http://www.twitter.com/triggerfishza From: softimage-boun...@listproc.autodesk.com [softimage-boun...@listproc.autodesk.com] on behalf of Stefan Andersson [sander...@gmail.com] Sent: 28 January 2013 16:07 To: softimage@listproc.autodesk.com Subject: Re: building asset tools 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.commailto: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.commailto: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 disk. 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.commailto: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.commailto: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
Re: building asset tools
We're currently using alembic from soft to soft here. Using reference models with pre existing envelopes that attach on the fly to our rigs. Alembic is basically used for point caching. Alembic has also been used here for sharing data between Soft, Max, Maya and Houdini quite nicely (cameras, animated geo...) It has been the most robust experience I've had to date compared to FBX or any other data format. The speed can be a little slow if you're also using alembic to generated the topology per frame but for point cache only purposes it's very nice. What are you referring to regarding Maya Alembic? I haven't heard the good side of it. On Mon, Jan 28, 2013 at 10:58 AM, Stefan Andersson sander...@gmail.comwrote: So Maya Alembic wins again... On Mon, Jan 28, 2013 at 3:31 PM, Guillaume Laforge guillaume.laforge...@gmail.com 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 sander...@gmail.comwrote: 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.comwrote: *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
Re: building asset tools
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 | showreelhttp://vimeo.com/sanders3d| twitter http://twitter.com/sanders3d | LinkedInhttp://www.linkedin.com/in/sanders3d| cell: +46-73-6268850 | skype:sanders3d
