Karma as a "normal" renderer

   3826   13   0
User Avatar
Member
115 posts
Joined: Feb. 2014
Offline
Will Karma ever be available in Houdini without having to use Solaris? I get that Solaris is very clever but it's another very complex context to learn just to access a replacement for Mantra. I bash out little standalone graphics and Solaris would be pointless for me.
User Avatar
Member
575 posts
Joined: Nov. 2005
Offline
as far as I know karma is bound to usd. give it a try, You can dive very deep, but You also can stay in shallow waters and it still will benefit You greatly.
User Avatar
Member
115 posts
Joined: Feb. 2014
Offline
what would Solaris / USD give me? (Apart from just expanding my brain by making me learn stuff which is always good) that would be any use to a tiny one man band?
User Avatar
Member
918 posts
Joined: March 2014
Offline
Looking at the sneak peak video, I'm curious about this Karma ROP. Let's hope and see.

Attachments:
karma.jpg (103.8 KB)

User Avatar
Member
575 posts
Joined: Nov. 2005
Offline
where to start....

- a clean and elegant way to build Your render setups
- nodes for render setups, so You can easily test different settings
- usd advantages when writing usd. no more bottlenecks in ifd generation, prior to rendering
- much faster startup on rendering



just to name some
Edited by sanostol - Oct. 22, 2021 06:45:16
User Avatar
Member
94 posts
Joined: July 2019
Offline
I think h19 reveal video showed that Solaris is going to be whole UI subsystem to speed up set dressing: scatter and placing brushes, quick lighting setups and controls, straightforward constraint presets, assets management library, functional tree (sub)object manager, render agnostic scenes and shaders, non-destructive layout iterations with layers.
The software just not at the point yet, because at current state it is a technical release. For non tech enthusiast it's better to think that there is no Solaris at all until it suddenly come out on a white horse as finalized product, or more wisely start to discover the new context little by little.
I bet SideFX put enormous effort to bring a set dressing to next level without breaking existing pipelines.
Besides (just by looking what they did with pyro preview) I hope that in the future ogl viewport will evolve into something that gives results with quality very close to final render and it will be not necessary to press render button till last production stages.
User Avatar
Member
856 posts
Joined: Oct. 2008
Offline
I agree that Solaris is clever and useful and neat. I also agree that it adds a needless layer of complexity and one-more-thing-to-know when all you want is some dumb exrs with some objects. You don't always need a full pipe studio multiple department all can do context.
--
Jobless
User Avatar
Member
603 posts
Joined: July 2013
Offline
USD has several advantages over traditional OBJ context, and it has a few nagging disadvantages too (the non-destructive nature of USD and the ridiculous rules around what you can/cannot change on Instances).

The Solaris presenters at the View Conference did a really great job explaining USD/Solaris and its a great primer on anyone that wants to get up to speed on USD in Houdini.
Houdini Indie
Karma/Redshift 3D
User Avatar
Member
273 posts
Joined: Nov. 2013
Offline
At the very least solaris offers a sane way to deal with render pass management. Regardless of project complexity or team size, destructive workflows when generating passes causes tons of problems. So to start off just use it as a takes replacement that actually works, and go from there.
User Avatar
Member
273 posts
Joined: Nov. 2013
Offline
Daryl Dunlap
USD has several advantages over traditional OBJ context, and it has a few nagging disadvantages too (the non-destructive nature of USD and the ridiculous rules around what you can/cannot change on Instances).

Solaris had certainly prioritised non-destructive workflows because that’s primarily what node networks are good at. But USD isn’t inherently non-destructive. Similar to photoshop you can choose to work destructively in one layer or add new layers, keeping previous layers intact.

It’s hard to comment on the instancing because I haven’t seen the videos yet. But it’s certainly true that instance prototypes are more difficult (but not impossible) to edit due to their implicit nature. It’s actually not that hard to create an explicit prototype that can be edited normally, so hopefully the tooling will get better for that over time.
User Avatar
Member
238 posts
Joined: Nov. 2013
Offline
Soothsayer
I agree that Solaris is clever and useful and neat. I also agree that it adds a needless layer of complexity and one-more-thing-to-know when all you want is some dumb exrs with some objects. You don't always need a full pipe studio multiple department all can do context.


In my very limited experience with Lops I've had less context switching and diving inside nodes while working with it.
The time to first pixel is cut significantly. Which results even in faster iterations.
And what I also did not know is how great it is to have a visual dependency graph of a the whole scene at first glance.

I am kinda an one man shop and thought that I could not benefit from usd, but after forcing myself to use it its quite the opposite.
http://www.sekowfx.com [www.sekowfx.com]
User Avatar
Member
603 posts
Joined: July 2013
Offline
antc
prioritised non-destructive workflows because that’s primarily what node networks are good at.

I think Blender would disagree with that statement.

antc
But USD isn’t inherently non-destructive. Similar to photoshop you can choose to work destructively in one layer or add new layers, keeping previous layers intact.

It’s hard to comment on the instancing because I haven’t seen the videos yet. But it’s certainly true that instance prototypes are more difficult (but not impossible) to edit due to their implicit nature. It’s actually not that hard to create an explicit prototype that can be edited normally, so hopefully the tooling will get better for that over time.

Its the collision of authoring vs layout that's shocking the Houdini Community in my opinion.

Being handcuffed about what you can/cannot do to Instances in USD is just very jarring - and kinda against the Houdini philosophy of low-level access when authoring.

Especially when you consider, how is the laymen supposed to even discover the rule preventing them from making a change?, because Houdini just renders, it doesnt tell you why your attempt failed.
Edited by TwinSnakes007 - Oct. 25, 2021 08:07:19
Houdini Indie
Karma/Redshift 3D
User Avatar
Member
273 posts
Joined: Nov. 2013
Offline
Daryl Dunlap
Its the collision of authoring vs layout that's shocking the Houdini Community in my opinion.
Yeah in the long run it's cool when a context can be used for multiple workflows, but in the short term results in even more stuff learn. If it were me I would pick something simpler than layout to start with. Kind of like with sops you probably want to start with some modeling operations and get the hang of the basics rather than try learn crowds or kinefx right out the gate.

Daryl Dunlap
Being handcuffed about what you can/cannot do to Instances in USD is just very jarring - and kinda against the Houdini philosophy of low-level access when authoring.

Especially when you consider, how is the laymen supposed to even discover the rule preventing them from making a change?, because Houdini just renders, it doesnt tell you why your attempt failed.

I'd at least expect to see some warnings from the lop node that tried to apply the edit/over to an instance proxy prim, which is basically the problem. But I agree it would be great if instances were easier to deal with. The 'U' in USD makes instancing quite tricky.
User Avatar
Member
27 posts
Joined: May 2014
Offline
Maybe in 5 years
  • Quick Links