Cheers,
- Tyler
Heileiftbay312TwinSnakes007
Next RS release will have some long requested features, a few of them are huge.
One thing RS currently doesn’t have is support for Clone.
Hey @TwinSnakes007 ,
I'm having some trouble looking up this "Clone" that you mentioned. What is that referring to exactly?
Some info here https://www.sidefx.com/docs/houdini20.0/ref/panes/clonecontrol.html [www.sidefx.com]
TwinSnakes007
Next RS release will have some long requested features, a few of them are huge.
One thing RS currently doesn’t have is support for Clone.
antctbay312
When it comes to user experience, the workflow quirks come from the combination of Solaris / LOPS and USD rather than just USD itself. In that way, I agree - assuming that USD always translates the scenes perfectly from obj --> USD... which, I don't think is always the case.
Just for correctness sake - USD never translates anything from obj --> USD, Houdini does.
tamtetbay312as I said I'm not using Karma ROP so not sure if its doing the correct thing
If an artist is trying to get that sub-stepped motion blur, they'll need to... 1. Generate sub-frame data in sops if it's not there, 2. Cache out sub-frame USD 3. Adjust render settings accordingly so that it's picking up the data. By comparison, with RS, it would be... 1. Generate sub-frame data in sops if it's not there and then 2. Adjust render settings accordingly so that it's picking up the data. So, in that way, working with USD isn't really equivalent to the conversion that RS does at render time
but regarding MB I was talking about Karma ROP and that "hidden" USD translation layer
enabling MB turns on internal Cache LOP path automatically and infers the caching steps from the stage settings
so theoretically should be doing what RS or Mantra do, as you said at "rendertime" but technically at scene translation time
in other words, in ideal scenario artist should not notice that Karma ROP is using usd under the hood, if all scene translators were doing the ideal and optimized thing
the fact that USD and LOPs allow you to do much more stuff should be irrelevant if the translator from Object to USD is solid and handles all kinds of cases
In my mind USD workflow in LOPs is completely different topic than just using .usd as a temporary scene description like .rs or .ifd, .ass, .rib with automatic translation layer from Obj
Which doesn't change the fact that it's currently not ideal so all this feeds into your points of it currently not feeling the same, but my point is that I don't believe it's due to USD itself
EDIT: Just imagine hypothetically that Houdini doesn't have LOPs and Karma ROP needs to translate the obj scene into it's scene description file let's call it .kma (which by coincidence would be identical to .usd )
So Obj to .kma translators would need to be as optimized as obj to .ifd or to .rs at least that's my point of view
that's essentially what needs to happen with Obj to USD Stage (.usd)
the fact that we have LOPs to have additional control over this translation is just a bonus
tamtetbay312you may want to word these things differently
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.
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 thingtbay312aren't references or instanceable references equivalent of rs proxies?
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.
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, ...
Heileifhabernir
nice comparison but their is a subjects that i dont understand like features "non usd" or "rs proxy" or "material x" ..... thats not related to the comparison because xpu will never have rs proxies and its always will be for usd (i think)and also karma XPU was built with material x support from the ground-up soo no need to mention it.
and you compare "hybrid rendering" soo how can you compare karma XPU that was built from the ground-up for multi-devices to redshift ? its a two different worlds
but isn't the comparison too early? because XPU is relative new
I think it's important to mention the MaterialX in the comparison. Especially for people who are planning on interchanging shaders, or have a MaterialX library they still want to use without converting all the shaders.
habernir
nice comparison but their is a subjects that i dont understand like features "non usd" or "rs proxy" or "material x" ..... thats not related to the comparison because xpu will never have rs proxies and its always will be for usd (i think)and also karma XPU was built with material x support from the ground-up soo no need to mention it.
and you compare "hybrid rendering" soo how can you compare karma XPU that was built from the ground-up for multi-devices to redshift ? its a two different worlds
but isn't the comparison too early? because XPU is relative new
TwinSnakes007
Next RS release will have some long requested features, a few of them are huge.
One thing RS currently doesn’t have is support for Clone.
But like I said, wait until after the next RS release before you record/publish any video content, in comparison between the two.
Heileif
Nice list
Found something that is not 100% correct.
Redshift does not have LPE tags or cell shading at the moment.
Redshift can have a room shader using a OSL shader from the Redshift OSL Github page https://github.com/redshift3d/RedshiftOSLShaders [github.com]
At the moment Redshift does not have a native cell shading.
malexandertbay312malexander
There's also first-person navigation mode, which you can enter with Space+M. It takes over the hotkeys in the viewport, but allows you to use the mouse and the standard WASD keys to move around. This works well for large scenes that you need to get in close to, where rotating around a pivot tends to send you "inside" objects or zipping off on a large arc.
https://www.sidefx.com/docs/houdini/basics/view.html#fps [www.sidefx.com]
Hey, thanks for the reply malexander,
Unfortunately the first-person mode does not work well either. The speed at which it navigates is still based on the 16,000 meter object in the scene, so it zooms off quickly.
You can adjust the speed with the mouse wheel, or by holding Ctrl/Shift. It's hard to know exactly how fast someone wants to zip around the scene, so it only makes a best guess.
malexander
There's also first-person navigation mode, which you can enter with Space+M. It takes over the hotkeys in the viewport, but allows you to use the mouse and the standard WASD keys to move around. This works well for large scenes that you need to get in close to, where rotating around a pivot tends to send you "inside" objects or zipping off on a large arc.
https://www.sidefx.com/docs/houdini/basics/view.html#fps [www.sidefx.com]
BradThompson
Hold the space bar while hovering over the viewport. You'll see a new set of buttons just above the viewport. The left-most one will be "set pivot on tumble rotate". Try changing that to "keep pivot on tumble rotate".
Is that the behavior you are looking for?