Very good points Matt, and I didn't meant to say I wouldn't welcome it either,
not just because of the merits of an ASCII file format itself but also in
anticipation of it's positive side effects it's implementation would
presumingly require like more operator transparency (i.e. non-linear editing of
operator dependencies).
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 impo!
rt!
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--
--
-------------------------------------------
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--
