WORD! I think everything has been said so far. And just to make it clear enough for everybody out there: We need a ASCII file format. Yes we do!
On Mon, Jan 28, 2013 at 8:02 PM, Matt Lind <[email protected]> wrote: > 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-- > > > -- --------------------------------------- Vladimir Jankijevic Technical Direction Elefant Studios AG Lessingstrasse 15 CH-8002 Zürich +41 44 500 48 20 www.elefantstudios.ch ---------------------------------------
