Whoa, the number would be significantly greater than 1%. More like 100%. While relatively few people would be writing code to modify the text format, everybody using it would benefit.
The single biggest issue I have right now in our pipeline is dealing with thousands of assets made over the past 8 years on this production that need to be used again in a current version of Softimage. This very production is projected to continue 10 more years. That means assets made in 2005 may need to be opened in the year 2023. There will have been too many architectural changes in Softimage 2023 to be able to open such files anymore. We've already hit this problem several times in the past few years getting stuff created in XSI 6.0 open in Softimage 2010 or later due to the deprecation of the particle system and changes in realtime shader architectures. If we have a text file format, we can at least do some work to make the old asset compatible with whatever version of Softimage is in use. Without a text file format, I either have to roll my own - which I tried - or deprecate the asset and tell my art directory the team has to replace it with a new one. Say that 15,000 times and somebody high up won't be too happy. I have written my own file format to do this work. While it's not too difficult to export data, it's damned near impossible to import the data and preserve the integrity mostly because Softimage doesn't expose the necessary hooks to rebuild the construction history. Operator port connections of often not exposed and the data needed to recreate the operator to behave exactly as during previous save operation is not possible either. Example: 'movecomponentOp'. I know it does a simple translation of affected points, but Softimage does not expose what that translation value(s) are. Although it's one of the simplest operators to roll out of the box, I cannot support it in a custom file format. It forces me to freeze everything on scene save and that makes some artists unhappy as much of what they work on is work in progress, or has operations in parts of the construction history other than the 'modeling' marker. Example: envelopes or 'shrinkwrap' operators. Rather import! ant to know the intention to be able to rebuild it properly. What Softimage desperately needs is a text file format that is fully accessible at the most granular level and supports edits by the end user. Not just trivial things like paths to texture bitmap paths, or filenames to write images produced by renders, but also modification of the construction history such as being able to deactivate an operator if it's known to induce crashes or is deprecated itself and needs to be replaced with something more modern. Examples: - replace the old deprecated Softimage particle system with ICE equivalent. - replace shaders which have experienced architectural changes (e.g. realtime shaders created in XSI 5.x with an equivalent created in Softimage 2013x) - deactivate operators known to induce crashes (due to corruption, perhaps). - Add/remove objects/models from scene. - Redirect operator targets (such as point constraints to affect different objects because original target no longer valid) - Adjust renderpass partition memberships and overrides (because it's soooooo sloooooowww inside of the Softimage UI) - delete crap that never belonged in the first place. One very important aspect of having a text file format is the ability to use code to read/write/validate data in the file and have it work in the Software. Not trivial to implement, but highly important as there really needs to be an option to modify vast quantities of assets without having to do it inside of a call to xsibatch.exe. XSIbatch is much too slow to operate on hundreds of thousands of assets as we have to do. If a batch crashes for any reason, we just don't have the granularity to know where to restart the batch or get enough information about the error. One very important aspect of having a text file format is the ability to get valuable information from processing in a timely and effective manner. There's more, but I think the point has been made. Text file format is critical to large scale production, but helps all productions. Matt -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Stefan Kubicek Sent: Monday, January 28, 2013 8:03 AM To: [email protected] Subject: 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 [email protected] --- -- This email and its attachments are --confidential and for the recipient only--
