Re: FBXImport Materials
Hi Christian I have filed your request for FBX layering under SOFT-8222. When you mention spline / curve support, do you mean surface or curve ? Regards Ivan
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: OT: Ergonomic chairs
Thanks for the suggestions, I actually already have an Aeron, bought it from a hedge fund guy who was downsizing a couple years back, the only good thing to come out of the financial crisis for me.. It just doesn't have all of the adjustments I need. I checked out several, and while the Herman Miller Embody is really cool, I'm not dropping that kind of money on a chair. I actually thought this felt the best and is closer to a reasonable price range. Maybe I can find one cheaper than list somewhere. http://store.steelcase.com/brochures/amia/ Eric On Sat, Jan 26, 2013 at 11:37 PM, Andy Moorer andymoo...@gmail.com wrote: I like those too, if you haven't tried one they're in fact very comfortable despite being freaky looking. :D Everywhere I end up seems to go cheap on chairs lately. It's a pity, because it really makes a difference - if little discomforts aren't distracting people they seem to do much better work. On Jan 26, 2013, at 6:42 AM, olivier jeannel olivier.jean...@noos.fr wrote: I sit on that at my home desk : (Jpg of kneel-type chair) -- Freelance 3D and VFX animator http://vimeopro.com/user7979713/3d-work
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: softimage and it's binary format
Some oil for the fire: The terms 'non-trivial' and 'cost benefit to the customer' come to mind. * ducks out * On 28 January 2013 14:55, Ciaran Moloney moloney.cia...@gmail.com wrote: This has been a commonly requested feature over the years On Mon, Jan 28, 2013 at 2:29 PM, Stefan Andersson sander...@gmail.comwrote: Hello Everyone, Something that is bothering me, and has been bothering me for a long while, is the constant use of binary files in Softimage. 1.) emdl Would it be so wrong to have this as a ascii format? So that you can parse through the model and change data which might be needed? 2.) preset files SERIOUSLY... if I save out a single shader I should be able to edit the contents in the file. 3.) scn files Would be most helpful if this also could have THE OPTION of being ascii. 4.) dsprojectinfo I would love if this could be a ascii file so that it can be edited or created without Softimage Is there a way around this somehow? I've been lurking around to see if there was someone that had posted some ninja skills regarding this. anyhow, insights and thoughts are welcomed best regards stefan andersson -- *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
Re: softimage and it's binary format
Just to clarify, those are some of the terms I heard from the AD end whenever someone brought this issue up. Like Ciaran said, this request has been brought up frequently. Anyone involved with trouble-shooting knows the benefits of having ASCII files, just need to convince the devs. On 28 January 2013 15:33, Ponthieux, Joey j.ponthi...@nasa.gov wrote: On 1/28/2013 9:29 AM, Stefan Andersson wrote: Hello Everyone, Something that is bothering me, and has been bothering me for a long while, is the constant use of binary files in Softimage. 3.) scn files Would be most helpful if this also could have THE OPTION of being ascii. -- *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 Second that! Why? I've been writing out Maya .ma files for almost 12 years. That would have been 14 years except in 98 and 99 I did not have the foresight to understand that Maya's binary .mb files might need to be edited. On rare occasions we ran into scene files that would get corrupted or otherwise take a mind of their own. ASCII .ma files could be edited and the scene resurrected, an activity that occurred more frequently as the files got really large. Other reasons? Old scene files(decade old), and which were not corrupted, but had old texture file links that were no longer valid could be edited to relink the textures to their new location. Old .ma file, new file server, Perl script, no problem. The loss of hard disk space and extra time to load .ma files became trade-offs that were well worth the investment. As an added advantage interrogating the .ma scene structure yielded vast amounts of interesting information about Maya internals and structure. It was after all nothing but a huge Mel file. An example of a significant benefit? I once wrote a material file converter for Wavefront TAV .mtl files to Maya. Something Alias Wavefront never created...go figure. I used a .ma file to decipher what the materials should look like in Maya and converted the .mtl files straight to .ma. Without the ASCII scene information from the .ma file it would have been practically impossible to accomplish. With this habit somewhat ingrained, I have often wondered what a Softimage scene file would look like in ASCII. I would welcome this capability in Softimage. Going back even farther, I had my own database management tools written in Perl for Softimage 3D back in the day. So having ascii access to dsprojectinfo would also be useful. As would the other files. Granted I can understand the performance issues related to having some of these files as ascii, but each should be optional. Joey Ponthieux LaRC Information Technology Enhanced Services (LITES) Mymic Technical Services NASA Langley Research Center Opinions stated here-in are strictly those of the author and do not represent the opinions of NASA or any other party.
Re: softimage and it's binary format
I guess implementing an ASCII file format writer/reader is hard to do as an afterthought and difficult to justify for what is probably less than 1% of the user base that would actually require and benefit from it. There has once been a push towards a 3dsMax ASCII file format by Borislav Bobo Petrov years ago, but it was just too time consuming to maintain and develop up to a level where it could actually be used reliably and professionally, and for simple things you could just use the FBX ascii file format. http://www.scriptspot.com/bobo/darkmoon/bff/ For something like that I imagine you'd first need 100% script access to every minute detail of the scene. That is: Not only being able to read certain information, but also to create and connect objects in a non-linear fashion, however there are still places in Softimage where this is not possible (e.g. you cannot create an op and then connect it to some objects later, or change connections of an operator once they have been established, at least for the bigger part). That means that scene creation through scripting (assuming an ASCII file format for XSI would essentially be some sort of script, similar to a Maya ASCII file) would need to be linear, you'd have to be careful what you create at which point in time/the file, and that again makes it harder compared to just writing all the nodes out to the file and then start making connections to/from their parameters. Just some thoughts, somebody correct me if I'm wrong. Stefan Hello Everyone, Something that is bothering me, and has been bothering me for a long while, is the constant use of binary files in Softimage. 1.) emdl Would it be so wrong to have this as a ascii format? So that you can parse through the model and change data which might be needed? 2.) preset files SERIOUSLY... if I save out a single shader I should be able to edit the contents in the file. 3.) scn files Would be most helpful if this also could have THE OPTION of being ascii. 4.) dsprojectinfo I would love if this could be a ascii file so that it can be edited or created without Softimage Is there a way around this somehow? I've been lurking around to see if there was someone that had posted some ninja skills regarding this. anyhow, insights and thoughts are welcomed best regards stefan andersson -- --- Stefan Kubicek Co-founder --- keyvis digital imagery Wehrgasse 9 - Grüner Hof 1050 Vienna Austria Phone:+43/699/12614231 --- www.keyvis.at ste...@keyvis.at --- -- This email and its attachments are --confidential and for the recipient only--
Re: softimage and it's binary format
Thanks Stefan , will do :) The team is aware of this popular request (and many others). I will log it down. Best Regards Ivan On Tue, Jan 29, 2013 at 12:08 AM, Stefan Andersson sander...@gmail.comwrote: You might want to check the backlog for the last 8-10 years of beta list discussions :) If you remember to log it, please write back which REQ number. best regards stefan andersson
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: softimage and it's binary format
back in the day... hrcConvert ;) On Mon, Jan 28, 2013 at 11:24 AM, ivan t ivansoftim...@gmail.com wrote: Thanks Stefan , will do :) The team is aware of this popular request (and many others). I will log it down. Best Regards Ivan On Tue, Jan 29, 2013 at 12:08 AM, Stefan Andersson sander...@gmail.comwrote: You might want to check the backlog for the last 8-10 years of beta list discussions :) If you remember to log it, please write back which REQ number. best regards stefan andersson
Re: Getting the spdl ICE attributes in c++
i thought this might be it but i tried it in scripting and didn't get anything related to iceattributes... http://download.autodesk.com/global/docs/softimage2013/en_us/sdkguide/si_cpp/classXSI_1_1ShaderDef.html#a558539353bd99263d936703078f01369 no other ideas from me On Mon, Jan 28, 2013 at 11:46 AM, Stefano Jannuzzo stefano.jannu...@gmail.com wrote: Hi folks. There are a few shaders that declare the list of ICE attributes they require to work, by listing their names in the output parameter section of their spdl. For instance, if you edit particle_Density, you can read ICEattribute = Color,Id,PointVelocity,Orientation,Size,PointPosition,Age,AgeLimit,StrandPosition,StrandVelocity,StrandSize,StrandOrientation,StrandColor; I need to retrieve this list in a cpp command (2011 and above), with no success yet. Any idea? Stefano
Re: Getting the spdl ICE attributes in c++
It tells Softimage that the shader wants data from ICE graph. Or
something like that.
On 28/01/2013 3:15 PM, Steven Caron wrote:
aah yes! i didn't have it instanced in the scene yet. this is
interesting too, ICEAttributes property on a shader node?
from siutils import si
si = si()# win32com.client.Dispatch('XSI.Application')
from siutils import log# LogMessage
from siutils import disp# win32com.client.Dispatch
from siutils import C# win32com.client.constants
for shaderdef in si.ShaderDefinitions:
if shaderdef.Name == Softimage.BA_particle_density3.1.0:
for shader in shaderdef.ShaderInstances:
for attr in shader.ICEAttributes:
log(attr.Name)
On Mon, Jan 28, 2013 at 12:07 PM, Stephen Blair
stephenrbl...@gmail.com mailto:stephenrbl...@gmail.com wrote:
I found I could get the ICEattribute for Particle Density if the
shader exists in the scene (in 2013sp1). But that's not true for
the other shaders that have ICEattribute.
In 2013 SP1, in Python:
sdef = Application.GetShaderDef(
Softimage.BA_particle_density3.1.0 )
for i in range( len(sdef.Attributes.Names) ):
print %s=%s % ( sdef.Attributes.Names[i],
sdef.Attributes.Values[i] )
If you run that snippet in a blank scene, you get:
// INFO : Softimage.BA_particle_density3.1.0
// INFO : Softimage.BA_particle_density3.1.0 has 2 attribute
name(s) and 2 value(s):
// INFO : - shaderlocation == 3
// INFO : - thumbnail == particle.bmp
If you run this script first:
CreatePrim(Grid, MeshSurface, null, null);
ICEFlow_CreateParticles(null, null, null);
ApplyShader(ICEParticleVolumeShader, ,
ICEParticleVolumeShader, , siLetLocalMaterialsOverlap);
then you get this:
# shaderlocation=3
# thumbnail=particle.bmp
# {C535FA4D-E44A-45EB-AEE0-9F9AAEA91745}=None
#
{20ECB4F8-A4A1-44FE-956A-0F6E98D541A8}=Color,Id,PointVelocity,Orientation,Size,PointPosition,Age,AgeLimit,StrandPosition,StrandVelocity,StrandSize,StrandOrientation,StrandColor
On 28/01/2013 3:01 PM, Steven Caron wrote:
i thought this might be it but i tried it in scripting and didn't
get anything related to iceattributes...
http://download.autodesk.com/global/docs/softimage2013/en_us/sdkguide/si_cpp/classXSI_1_1ShaderDef.html#a558539353bd99263d936703078f01369
no other ideas from me
On Mon, Jan 28, 2013 at 11:46 AM, Stefano Jannuzzo
stefano.jannu...@gmail.com mailto:stefano.jannu...@gmail.com
wrote:
Hi folks.
There are a few shaders that declare the list of ICE
attributes they require to work, by listing their names in
the output parameter section of their spdl.
For instance, if you edit particle_Density, you can read
ICEattribute =
Color,Id,PointVelocity,Orientation,Size,PointPosition,Age,AgeLimit,StrandPosition,StrandVelocity,StrandSize,StrandOrientation,StrandColor;
I need to retrieve this list in a cpp command (2011 and
above), with no success yet. Any idea?
Stefano
Re: OT: Ergonomic chairs
We got a few Knoll ones for testing at work and it was a mixed bag of opinion. Some like the bendy back but a lot of people really don't. Yes, it's comfortable, but I'm not sure it is conductive to a good posture. It doesn't hold your back straight (in an ergonomic ideal position); it bends to your back's will. On Fri, Jan 25, 2013 at 8:24 AM, Marc-Andre Carbonneau marc-andre.carbonn...@ubisoft.com wrote: We have crappy chairs here at Ubi but I heard good things about this Knoll ones: http://www.sithowyouwant.com/generation Similar in price than the Aeron but cheaper than the Embody. GASP! ** ** ** ** *From:* softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] *On Behalf Of *Steve Pratt *Sent:* 24 janvier 2013 23:45 *To:* XSi Mail List *Subject:* Re: OT: Ergonomic chairs ** ** I've been a chair gnome for 30 years. Bought an Aeron, 12 years ago and, apart from the dust, still looks new, and is still the best all rounder. It sits at home now as I'm an employee and management penny pinched and got cheap Aeron knock offs. They're lousy. ** ** On 25 January 2013 14:02, Eric Lampi ericla...@gmail.com wrote: Hey all, Does anyone have recommendations for good, adjustable, ergonomic chair? We all spend a lot of time sitting, so I figure this is probably a good place to ask. A Herman-Miller Aeron Chair is a no-brainer, so if anyone has an alternate suggestion, I'd appreciate it! Eric -- Freelance 3D and VFX animator http://vimeopro.com/user7979713/3d-work ** ** -- *Twenty years from now you will be more disappointed with the things that you didn't do than by the ones you did do. So throw off the bowlines. Sail away from the safe harbour. Catch the trade winds in your sails. Explore. Dream. Discover.* - Mark Twain
Re: Getting the spdl ICE attributes in c++
i wonder what possibilities for tighter integration of other renderers/shaders this provides 3rd parties? On Mon, Jan 28, 2013 at 12:22 PM, Stephen Blair stephenrbl...@gmail.comwrote: It tells Softimage that the shader wants data from ICE graph. Or something like that.
Re: Middle mouse pan in ice tree
People got annoyed when moving back and forth between Nuke and Soft. On Mon, Jan 28, 2013 at 8:55 PM, David Barosin dbaro...@gmail.com wrote: Anyone know if there is a way to turn off the middle mouse for panning in the ICE Tree. I *really* miss the old behavior that had middle mouse handle branch selection boxes. It was totally consistent with everything else in XSI's selection mode. Not sure why that was even changed.
Re: Middle mouse pan in ice tree
Yeah I guess the happy solution would be a preference check box. Thanks for everyone chiming in. It does seem to break from the established flow of selecting objects and components in the 3d view. This new mode slows things down if you have large trees that need to be shuffled around (especially with a mix of branches and temporarily unconnected nodes). On Mon, Jan 28, 2013 at 4:13 PM, Grahame Fuller grahame.ful...@autodesk.com wrote: There's no preference that I know of, but you can still middle-click (i.e. no drag) to branch-select a node. It also works with Shift (add to selection), Ctrl (toggle Selection), and Ctrl+Shift (deselect). gray From: softimage-boun...@listproc.autodesk.com [mailto: softimage-boun...@listproc.autodesk.com] On Behalf Of Leonard Koch Sent: Monday, January 28, 2013 04:06 PM To: softimage@listproc.autodesk.com Subject: Re: Middle mouse pan in ice tree Yeah, that would be really lovely. That change annoys me about 15 times every day. Whenever my mind is elsewhere I fall back into the old and accustomed-to behaviour. On Mon, Jan 28, 2013 at 9:55 PM, David Barosin dbaro...@gmail.commailto: dbaro...@gmail.com wrote: Anyone know if there is a way to turn off the middle mouse for panning in the ICE Tree. I really miss the old behavior that had middle mouse handle branch selection boxes. It was totally consistent with everything else in XSI's selection mode. Not sure why that was even changed.
Re: softimage and it's binary format
There is really no technical reason why Softimage could not save the equivalent of the current binary scene as ASCII, and it may not even be slower. It's hard to explain why this project has never been scheduled in the last 15 years without pointing fingers. priority should go on exposing more from Softimage than actually asking for an ascii file format. .. and these projects often die often because argument like this, which IMHO is a false dichotomy around core development vs the very nebulous more SDK access. It ignores the fact that core development is done in a fraction of the time and benefit everyone plus the long term viability of the product, and don't necessarily exclude SDK support. On Mon, Jan 28, 2013 at 5:18 PM, jo benayoun jobenay...@gmail.com wrote: I think, it has been made clear over the past why there is no ascii file formats ala Maya ma. Maya has the huge advantage to be build from the ground to the top using a command engine and so makes easier to have such file formats. I think it was one of the softimage dev who clearly explain that the emdl or scn files are dumps (serialized datas) from internal datastructures. The downside of this is because Autodesk wont expose softimage internals, this makes the format closed and if your file gets corruptes, well thats all on you, but as a good point, we get faster load times. We already have the tools to write custom exporter, though they are limited... priority should go on exposing more from Softimage than actually asking for an ascii file format.
Re: softimage and it's binary format
at 'maya developers'? On Mon, Jan 28, 2013 at 9:30 PM, Gene Crucean emailgeneonthel...@gmail.comwrote: Excellent... let's point some fingers! :D
