> On 31 Aug 2019, at 09:51, Jonathan Moore <jonathan.moo...@gmail.com> wrote: > > 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).
If there is one thing I have learned is that change is very hard to implement, even in extreme cases where there are very few arguments against seems to me human nature is such that we fear change rather than embrace the opportunities so I totally understand. Try to read this particular book that illustrates the transformation of a company with the right guy, with the right authority and power starts promoting change. Very educational. "The Phoenix Project” by Gene Kim https://u9432639.ct.sendgrid.net/wf/click?upn=lIXdN6W56FnEjHCwrBXqOq0HQNpV0huvAGw1zu6Xp8eVQuk2cNZiNFjx2k-2FfTNchg8g1WVJfcto95uwpDUO3LZkteEi6njQVm8xI39L6c-2FwUWtBrnSsd8VJqIyHMj3xD89U-2Fk5Qlb1PFEGxsgise9ETz0DRgLymDrie3mfFp2ZuB7FlLjx0dxzUWRFvFkTBZ98eV0vb7WFCWXbVDfT7ggsMWEeolR7ZNp8ZLAvFHsg4KOU1Li5XzpiPQYIMsIpc2nWIzOKSNHvH-2FmITgRLZdcoMJvGAaSMH58R8I8jF2VMFB3o-2Bj4AI3WzOWNPYqFTlCRZCyr8jrXDI-2Fkjm2PZINtKIp2cb0tiwdpokcgixhDO6B-2FmFbNZ-2FN96Z6CDjqGp66r7XOqPC9Gn17HeuawISjMT-2FhdveCrBSM5DZSQmdI1hpXfOD49iNmRaKtkjJOWPk6OtYrMZD7x198ybCIV-2FVZrA-3D-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuT2Dxf9tCgc37D-2By9MQhn3TuvZvmND3qIg08mk9-2FDK09pTvckiJJ7HMiijvd00VP4hs-2BElPlU54fQRKsI-2FFJ9sG-2F2RCgtqZCCafrXF-2B-2BBwd5enrBGuVhsUVRTVk5v-2FYctdyXDo9bjrruhXcUsp571rDVCF60Iq1sdsO98XyP3XG8mwM27E84U9bGYumotf3-2FtI-3D <https://u9432639.ct.sendgrid.net/wf/click?upn=lIXdN6W56FnEjHCwrBXqOq0HQNpV0huvAGw1zu6Xp8eVQuk2cNZiNFjx2k-2FfTNchg8g1WVJfcto95uwpDUO3LZkteEi6njQVm8xI39L6c-2FwUWtBrnSsd8VJqIyHMj3xD89U-2Fk5Qlb1PFEGxsgise9ETz0DRgLymDrie3mfFp2ZuB7FlLjx0dxzUWRFvFkTBZ98eV0vb7WFCWXbVDfT7ggsMWEeolR7ZNp8ZLAvFHsg4KOU1Li5XzpiPQYIMsIpc2nWIzOKSNHvH-2FmITgRLZdcoMJvGAaSMH58R8I8jF2VMFB3o-2Bj4AI3WzOWNPYqFTlCRZCyr8jrXDI-2Fkjm2PZINtKIp2cb0tiwdpokcgixhDO6B-2FmFbNZ-2FN96Z6CDjqGp66r7XOqPC9Gn17HeuawISjMT-2FhdveCrBSM5DZSQmdI1hpXfOD49iNmRaKtkjJOWPk6OtYrMZD7x198ybCIV-2FVZrA-3D-3D_a6oQc7tnfcb0GKvoO27fPkrQ0ATQyF1SDBXJOg7-2FbuT2Dxf9tCgc37D-2By9MQhn3TuvZvmND3qIg08mk9-2FDK09lSm0WHMifbj3O99J1YpZVoIMqmusCwFk1CCSHyCcEsC4Hhq4VhsSxe5t7dQZAQ68QoKGgdogdqKLfi3O4VhiVoHKl-2Fsi6z8Hx4BNpKK6ZzvuctwCPKICTbeC6i0r2yozIqTE4TdLBsn5o8EifMM56Q-3D > My only suggestion is, make sure you have 100% authority otherwise you will not make it, people get scared easily and USD is a major change. jb > 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 > <mailto: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 > <mailto: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 > <mailto: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.
------ Softimage Mailing List. To unsubscribe, send a mail to softimage-requ...@listproc.autodesk.com with "unsubscribe" in the subject, and reply to confirm.
