Thanks Matt/Jordi, very useful insights. In hindsight, I rushed the title of this post. All along I was looking for feedback regarding the frameworks used to manipulate Soft graphs and assets rather than the asset formats themselves. I'm still of a mind that TD's and technical artists responsible for creating pipeline tools for working with dotXSI/Models formats (be they from gaming or entertainment backgrounds) have a significant leg-up with regard to USD. And much of that advantage comes from the problems and pitfalls of working with said formats as well as the advantages.
I'm currently working with a large advertising network, attempting to get them up to speed with the importance of USD. And this has been a far bigger challenge than I'd at first anticipated. The most common response I've had from technical heads would approximate to 'it's just XML'. Obviously, the production capabilities of internal ad agency production departments lacks the sophistication of specialist production shops but digital/interactive production has historically been an in house capability of ad agencies (that's my background) and VR/AR/real-time has meant that the lines are becoming blurred between moving image production shops and digital/interactive production shops (many of which are now owned by the big advertising networks). I'm definitely something of an interloper on this list, so apologies for the occasional naivety my questions. :) On Fri, 30 Aug 2019 at 23:49, Matt Lind <speye...@hotmail.com> wrote: > Models are not really comparable to USD. Models are more similar to > Houdini's concept of Digital Asset than a scene. > > The purpose of a model was to be a container for an asset so it could be > more easily included in large scenes and independently manipulated with > regards to versioning and level of detail control. The main message of > ‘Sumatra’ and DS was that artists were to be removed from the burden of low > level manipulation, such as setting key frames, and able to focus more on > higher levels of control such as choreography via animation mixing. > > XSI Models are derived from the “hierarchy” (.hrc) from predecessor > Softimage|3D. One could argue the Model is a superset of the .hrc as the > main difference is the addition of the animation mixer (independent > timeline). The .hrc had level of detail control and other mechanisms, but > they were rarely used due to lack of tools to do it in a practical manner > by the end user. The Softimage|3D implementation required a lot of digging > through menus and strong self-discipline in organization of files. For some > operations, one had to jump out to the command line and use DbTools – a > proprietary environment for running shell scripts developed by Softimage. > > Softimage|3D had an ASCII text scene file format which related multiple > files, this was closer to the concept of USD. The main file was the Scene > Description (.dsc) which contained all the high level information of what > elements were in the scene and how they were related. This included > relations such as parent/child, master/slave relation of constraints, light > and model associations, groupings, custom effects and their parameter > settings, asset LOD, and the list goes on. It even includes position of > nodes as represented in the schematic view, The Scene Description was > accompanied by the Scene Setup file (.sts) which contained description of > the user's environment such as how the viewports were arranged, current > settings, render parameters, etc. All the other files pointed by the Scene > Description and Scene Setup were binary files and contained the actual > content (cameras, lights, models (hierarchies), materials, animation, …). > This meant a scene was a conglomerate of many files – handy for versioning > and substitutions, but took forever to load/save when the database started > to fill up. A single scene could consist of thousands of files, and each > file would have to be checked individually for version collision, and sync > with the other assets in the database. If scene save operation was > interrupted (e.g. crash), you had many orphaned files floating around in > your database creating all sorts of havoc. Since the default number of > versions kept was 4, and all hard drives of the day were disc drives with > small caches and slow spin rates and 10 Mbps ethernet (if lucky), it took > forever to get work done. That was a strong motivation behind XSI using a > single file for it's scene file format, and the .scntoc to mimic (to a much > lesser degree) the Scene Description. Ironically, Alias|Wavefront did the > exact opposite as Power Animator used a single file scene format, but > migrated to the Softimage|3D style with Maya. > > USD is more robust in that it's a rule based language to do the work of > assembly and has some amount of intelligence to handle collisions and other > problems. XSI models had limited ability to do that in the delta, but it > was self contained. XSI Scenes had some back door exceptions to the rule to > accommodate models in certain situations, but otherwise were passive and > not available to the user to manipulate. The Softimage|3D scene description > language was more primitive than USD in that it was more like a passive > list of commands to execute than a language with decision making > intelligence. Although error checking existed, it was largely assumed the > contents of the file were ordered and compliant. If a model was listed > twice, for example, the parser would not catch it and made every effort to > import the model and establish all the relations. It would be left to the > other operations downstream to catch the problem and report it. > > USD isn't rocket science, but it serves a very important role that's been > long needed. > > Matt > > Date: Tue, 27 Aug 2019 10:13:05 +0100 From: Jordi Bares < > jordiba...@gmail.com> Subject: Re: Thoughts on USD in comparison to > Softimage ‘Referenced Models’ To: "Official Softimage Users Mailing List. > > I guess the concepts are rooted in our reality and therefore it is only > natural the approaches are not that dissimilar, but it is fun to realise > Softimage Models were so advanced at the time as to be compared and all to > USD. > > IMHO USD is a major leap forward and models and references are a minor > attribute as the real meat is the whole versioning in combination with > layering which somehow makes me thing of XML document conversions for the > web and data mining but I digress.. > > USD is a framework and the scope is enormous, to the point that you don?t > need Alembic if you don?t want to, and chances are materialX becomes > irrelevant as well. I see the Houdini implementation presented at Siggraph > and it is in my little knowledge a true disruptor to the point that if it > will leverage scale to the masses, something we don?t have yet so I expect > companies to start exploring it and moving towards it real fast. > > Furthermore, Apple is amongst many big companies investing tons of money > into it as they have decided it to be their standard in the iOS and OSX > content system, for all VR expect to see a lot of USDZ (the compressed > version) and as such, I feel the industry money being pouring into USD will > become very obvious very soon. > > Then you add Hydra to the mix and the whole concept of a render engine > becomes quite more subtle as we will see the real differences between them > in how they implement algorithms? right now there are many other important > tasks the render engine does that via Hydra it won?t (think the deep > integration of Mental Ray with Softimage but in a generalised way?) > Meaning, we are going to see speed increases on the pure raytracing more > than texture management so I hope that allows these engines to focus on > what is important and for us artists to move to the engine because we need > those features. > > IMHO this is a whole new world bigger than reference model, this is proper > asset management and rendering pipeline all in one. > > My 2 cents jb > > ------ Softimage Mailing List. To unsubscribe, send a mail to > softimage-requ...@listproc.autodesk.com with “unsubscribe” in the > subject, and reply to confirm. >
------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
