I worked at Omation too. While I didn't write O-Net or metascene, I sat in the same office as those who did and was part of discussions.
As Steven said, metascene wasn't that similar to USD, but there were also two versions. Helge's version was the first version, but it was replaced by Adam and Mike when he left, and their version was much more developed. It was mostly designed to work around XSI's limitations with access to scene contents through the .scntoc as all the file formats were black boxes. The main problem we were bumping into was that 32 bit computers couldn't hold all the data we needed to load and render. We needed a system to offload contents selectively when it got to be too much. We also had significant problems with data corruption and needed a means to work with data reliably by having some form of control of it so it could be inspected and repaired if needed. Barnyard had a very deep revolving door of talent coming and going, and with that, a lot of inside knowledge of how things were done often disappeared without record because it was an ad-hoc production. and very little was documented. In my particular case, after I fixed the animation pipeline I assumed shader writing responsibilities, but my predecessor did not leave source code behind for many shaders, or documentation of which ones were deployed in production for situations when multiple versions of the code existed. So for me, metascene was a way to track down which scene files had gone through the pipeline using these rogue undocumented shaders that needed to be addressed when the shots got kicked back for re-rendering. Without a shader .dll, the artist cannot open the scene file. Without the source code to the shaders, I couldn't produce a shader .dll. That meant the entire shot would have to be rebuilt from scratch making management very unhappy. I spent many long nights reverse engineering these shots to figure out how to rewrite the shader code to match the results of shots that had already gone through the pipeline with the rogue shaders - and across two different platforms. Ugh. When artists created work at their workstation, they'd iterate all day long until they had something worthy of submission for approval. At that point they'd publish to O-Net (the system), and plugins on the back end would intercept the scene data and re-encode it into a list of files in a proprietary file format. Each hierarchy in the scene would become it's own file, pretty much like a model, but described in XML instead (or other format). the relations of these files would be recorded in a SQL database and other places so when they go onto the render farm they could be rendered and tracked. Once the system was fully fleshed out, front ends were made to automate tasks so scenes could be re-rendered if necessary, or fabricated entirely from the command line and submitted for rendering (mostly for rudimentary tasks like mattes). I cannot remember for sure, but I think later in the production all scenes were loaded from O-Net and not the scene file created from the previous save operation. This meant the scene was assembled from the re-encoded and tracked data, not the scene file. This helped limit corruptions and other issues. O-Net / Metascene was more a scene manipulation and analytics tool. But as stated above, Softimage's file formats were black boxes, so there were limits to what could be done. Not all assets could be successfully re-encoded and produce the same results. A lot of guess work was involved. USD is a specification of how to handle data and resolve disputes when collisions arise. It's not an analytical tool, but analytic tools can be written to work with USD files. Matt Date: Thu, 22 Aug 2019 08:41:32 -0700 From: Steven Caron <[email protected]> Subject: Re: Thoughts on USD in comparison to Softimage 'Referenced Models' To: [email protected] It would be purely speculative to comment about Animal Logic's pipeline. So I won't. I can see what your saying about people using Softimage probably appreciate something like USD more than users of other packages but the desire to work this way has been around for a while. We have had slice of this with Softimage a lot longer than most, we also had better render passes then everyone else for probably a decade. Maybe links are being made but just not as deep as you think. People have wanted something like USD for many years, I think you see people embracing it because they needed it so bad. I did work at Omation, I honestly am a little fuzzy about the details but I used (and tested) Helge, Adam, and Mike's work on 'metascene'. But it wasn't that similar to USD and it kinda solved some issues which were unique to Softimage at the time. Which then Helge went to work at Avid and helped address with the 6.0 referencing rewrite. ------ Softimage Mailing List. To unsubscribe, send a mail to [email protected] with "unsubscribe" in the subject, and reply to confirm.
