tbay312
Thanks for commenting, and I'll elaborate on those topics. When it comes to a "non usd" workflow, what that means is that Redshift has the ability to process non-usd information that's compatible with pre-solaris workflows. By comparison, with Karma, everything must be turned into usd in order to render something. Even if you go with the Karma ROP, it's using a scene import all to turn it into USD and then render. That has some major implications on certain things. For example, that has an impact on motion blur because you'll need to cache USD sub-frame data in order to get curved motion blur. Yes, you do have the accel / v / w attribute for curved motion blur, but the quality doesn't hold up to sub-frame data if the motion blur is long enough. So, that would be a situation where it matters to have the option for a non-usd workflow if you didn't want to go through the extra step of caching out subframe usd. USD has many additional quirks that introduce extra steps to workflows, and extra steps = more opportunities for failure points in the workflow. It also has an impact on any studio that doesn't want to use Disney's public version of USD. With RS, you have the option to process non-usd info which may make it easier for other studios to build their own custom "USD-like" pipeline around it. With Karma, you may be able to do that, but it's much more closely integrated with Disney's version of USD, so it may be impossible / much more difficult.
you may want to word these things differently
since every renderer has to translate the Houdini scene to the format they can understand first, even if it's hidden from the user and only in memory, for Mantra it's ifd, for Karma usd for Redshift rs, etc
so talking about non-usd for Karma is like talking about non-rs for Redshift
what is the issue however is that the translation from /obj to LOPs is not as optimized as it is for ifd or rs since it has bottlenecks like:
- it dirties more of the stage than seemingly necessary
- doesn't have dedicated set of Karma properties on /obj level, which it easily could have and they would be 1-1 translated to stage
- probably more, but I haven't used it much
however MB shouldn't be an issue since there can be internal Cache LOP or Motion Blur LOP which is equivalent of Mantra caching the geo substeps before frame render or I assume Resdhift has to do that as well
so rather than calling it non-usd workflow or pushing for it, I see it more like oprimizing the translators and integrating the controls on Ojbect level that directly translate to the stage and then the "hidden" USD layer could feel like the hidden RS layer for Resdhift or at least that's my understanding of the whole thing
tbay312
When it comes to "rsProxies" that also matters for freelancers and piplelines that use multiple software packages in their pipeline. In spite of the name, "Universal Scene Description" it is one of the least universally implemented formats between software packages at the moment because each software package seems to understand and write it out differently. Having the option to simplify the render data as a proxy is quite useful because it eliminates many cross-platform complications.
aren't references or instanceable references equivalent of rs proxies?
but of course for Object level workflows it would be ideal if Packed Disk Primitive pointing to .usd can automatically translate to USD reference on the stage, but that again comes to the translators and nodes like SOP Import LOP
Overall I agree that XPU despite being "gold" is missing a lot of features, for me Material blending is the major one, even currently supported surface shader blending doesn't not blend AOVs as we are used to from Mantra, but overall MtlX is currently very limited for any serious material authoring even with the addition of current kma nodes
some modern features would also be nice like AOV propagation through light paths (reflections, refractions, custom LPE, ...), roughness to bump, ...