A lot of companies are going XML lately. As Sony announced at the Alias User Event in Los Angeles (December 3rd, 2004), XML was used for storing a lot of different types of assets for the production of Spiderman and Spiderman 2. Omation spoke up at the Softimage XSI usergroup meeting in Los Angeles (March 10th, 2005), letting the community know how Omation’s pipeline is built on XML to store scene/model information. Just to name two.
XML (Extensible Markup Language) was originally developed for web documents. Designers can create their own tags to store custom data in an organized way to transfer information between applications using XML. Softimage started to support the standard for the ScnToc files, which store a summary of the scene elements in a XML file. With these files, production facilities e. g. are able to switch the reference models used in a scene without opening the scenefile, but by changing ASCII text instead, which is much faster, and even more importantly batchable throughout a whole sequence of scenes.
Furthermore Softimage’s XSI now supports XML as the standard for all layout/view related files. Layouts, views and the new relational views are all based of the ASCII standard. Also this feature enables large production to deal much more flexibly with their interface and generate new relational content on the fly.
dotXSI, Softimage’s own interactive media format, which supports export as ASCII or Binary compressed files, already stores a huge amount of scene-data, including geometry data, animation, camera information, lights etc….constraints, XSI specific operators (ala cluster shape combine), and Animation Mixer relevant data are not supported yet. Softimage took an amazing step by implementing the dotXSI standard, giving the users the ability to store model data in ASCII and enabling them to modify the information externaly of XSI. More than that: There are plugins for the major 3D packages to import/export dotXSI files, Softimage provides an external 3d viewer for dotXSI files, all major conversion programs support dotXSI by now!
Sounding like the ultimate solution for 3D data storage, dotXSI became more and more popular. From a non-linear pipeline point of view though, dotXSI, as well as the binary EMDL and SCN file solution are only partially applicable.
Working with static data such as EMDLs of dotXSI files, the only way to transport information from one model to another one is copying. Practically that means: Open a scene, import two models, copy the UVs from one model to the next, as an example. Considering the size of nowadays productions, the amount of rigs/models they are dealing with and the fact that schedules become tighter and even tighter, the process of copying is simply too slow and inefficient. dotXSI is a great feature of the non-linear package XSI, though the standard itself is totally linear.
That raises the question for alternatives… Here’s the idea (which is already in use here at Omation): Using XML for custom storage of scene/model information, which enables the users to reuse the data without importing the whole dataset.
XML description of a “texture-asset” including Geometry, Clusters, UVs, Rendertrees, Expressions. There could be custom tools which read the whole dataset and generate a model with geometry, applied UVs, materials etc. There can also be a custom tool which only reads the UV information, one which only reads cluster information and applies this information to an existing model in the scene, or even better, a XML description of a model, so you never have to open an EMDL file to actually apply these changes. Furthermore, all these processes would be batchable, so e.g. to get the current UVs on a bunch of models is not a problem, and can be executed by a CRON job on a server on a schedule-basis. The advantage over dotXSI/ScnToc is the non-linearity in a pipeline point of view. Models/Assets/Scenes can be broken up in discreet units for different departments/people to work on, and can be merged together on a per-unit level basis. So e.g. as soon as the texture part of the model is ready all related models get the most current UVs/materials.
This way of dealing with data changes the process of “copying” to a process of “applying” changes in an incremental way. And this is possible on a per model/per sequence/per show basis.