Thanks Matt for elaborating, your memory is so much better than mine. But those were the 'issues unique to softimage' I was referring too.
The composition of layers, the resolving of those complex compositions, the openess of the specification, and it's API makes highly inspectable and customizable, which was what I was alluding to earlier, Johnathan. This makes the biggest difference between what softimage provided with reference models vs USD. *written with my thumbs On Fri, Aug 30, 2019, 4:48 PM Matt Lind <[email protected]> wrote: > 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 > > >
------ Softimage Mailing List. To unsubscribe, send a mail to [email protected] with "unsubscribe" in the subject, and reply to confirm.
