Karma roadmap

   16092   33   4
User Avatar
Member
184 posts
Joined: Dec. 2008
Offline
mandrake0
wildruf
What are the plans for houdini crowds?

When there are functions missing please make a RFE, the next big task are surly karma (lops) and character animation. It would be intressting if chop's get's a bigger update.

Btw. USD based NLE / compositing would be intressting

I was referring to the subject in the karma - mantra FAQ.

" Crowd Support Mantra = Yes Karma = Partial Support | USDSkel support, but not optimized
User Avatar
Member
28 posts
Joined: Sept. 2008
Offline
When will Karma be v1.0? Wondering if I can plan jobs later in the year around this software?
www.earthfixed.com
User Avatar
Member
146 posts
Joined: Jan. 2018
Offline
stronglikebool
When will Karma be v1.0? Wondering if I can plan jobs later in the year around this software?
I'm in the same situation, wanting to move to Solaris, but I would need same level of VEX/VOPs shading functionality to make the jump, or at least typical stuff implemented such as masks, trace, hopefully lens shaders… to start thinking on Karma as a daily alternative.
User Avatar
Member
1268 posts
Joined: March 2014
Offline
Any news from Sidefx on the promised new Random Walk SSS shader?
Werner Ziemerink
Head of 3D
www.luma.co.za
User Avatar
Member
146 posts
Joined: Jan. 2018
Offline
Some promising steps in Karma development on the daily changelogs:

A very basic version of the VEX trace() function has been implemented for karma. This is likely enough for rounded edges, but not enough for dirt masks or general function yet. There may even be problems with rounded edges since trace scoping isn't supported yet.
User Avatar
Member
54 posts
Joined: Sept. 2008
Offline
Werner Ziemerink
Any news from Sidefx on the promised new Random Walk SSS shader?
Did they promise RW SSS?
User Avatar
Member
146 posts
Joined: Jan. 2018
Offline
sjyie0303
Werner Ziemerink
Any news from Sidefx on the promised new Random Walk SSS shader?
Did they promise RW SSS?
I don't remember that, but from yesterday changelog:
18.0.387 Added random walk SSS option (for Karma) to principled shader and classic shader. Added base normal export (“export_baseN”) to principled shader and classic shader.
User Avatar
Member
1268 posts
Joined: March 2014
Offline
sjyie0303
dded base normal

Yes. It was in a Solaris pre-release video as part of an Q&A section. I will see if I can find it, but if they added it
in 18.0.387, it should answer your question.
Werner Ziemerink
Head of 3D
www.luma.co.za
User Avatar
Member
7 posts
Joined: May 2020
Offline
I recently purchased Houdini FX I'd and I'd generally expect/hope at that price to have a fairly robust quality rendering built in to get real time quality feedback of our work. It makes more sense that render nodes are the rental not Karma since production houses will need them in Quantity and if other customers want to ever see large pieces of work rendered they would pay for it too.
Karma should absolutely not be a “rental” for current FX users, it's unfair because it is Beta -that is if in the future they decide not to make it free with a single instance. Again additional nodes should/could be offered as rental but not a license strategy that impedes the ability to see professional quality as the standard built-in
display -Houdini was coming out as the pinnacle of what a 3D tool could/should be until i learned about the Karma rental.

Edit: I was a bit concerned that there was no real time PBR shading, I thought it was available when I watched the promos but I didn't realize it only became available in the Stage environment.

I thought I'd give this a mention as well.. please focus on making user controls simple like a single control panel with sliders for the most part for the layout.. for big generators like oceans etc. If people want to go deeper and change some of the nodes that's fine. It seems like there is often 10 steps just to do one thing that is normally simple/efficient in other programs with maybe 1 or two steps. I realize the Power of Houdini that there could be many ways to do things, some better than others and it's usually up to the artist to discover them.


Setting up a material library is a big one.. many programs are providing texture packing & batch import solutions whereby if a customer has a library of thousands of materials he/she can simply give a prefix or suffix to import them like “_nm” custom entered designated to the normal map slots, direct the importer to the folder library and then batch creates full materials automatically for each material name. Mari is one of those programs.. Some assets for Unity does this as well like “Megasplat” or they just accept full libraries like Substances. Mari is another that helps with batch importing RDT photo scanned textures and creates the materials with the correct settings.

If there is a workflow for this please excuse me, I've been looking for a good tutorial on how to do this but there is none.

Sorry if it sounds like a rant, just giving some feedback and overall I feel that Programmers should make things easier, not make everyone else become the programmer no?
Edited by Ascensi - June 5, 2020 10:54:27
i7 4Gz 32 Mb | RTX 2080 Ti | Houdini FX 18 | Fusion Studio | Sonar Platinum | Zbrush 2020 |
User Avatar
Member
2627 posts
Joined: June 2008
Offline
I just noticed that XPU doesn't support emissive materials, but CPU does. There is no mention of emission on the FAQ link.

Is there any planned support for XPU emission support?
Using Houdini Indie 20.0
Windows 11 64GB Ryzen 16 core.
nVidia 3050RTX 8BG RAM.
User Avatar
Member
8043 posts
Joined: Sept. 2011
Offline
Enivob
I just noticed that XPU doesn't support emissive materials, but CPU does. There is no mention of emission on the FAQ link.

Is there any planned support for XPU emission support?

It definitely does by using the Mtlx Standard shader. You might be thinking of geometry light support, which is listed as 'planned for future release.'
User Avatar
Member
2627 posts
Joined: June 2008
Offline
Ok, it looks like there is a bug with data flowing through the mtlxswitch using H19.0.591. Shouldn't the fallback data, and thus an attribute value flow through the switch?


In this material setup, I've set the color of input 1 to black, for specifying areas where emission should not occur. With the broken data flow, I bet I'm always getting a zero routed to emission. This doesn't happen in CPU mode.


I only want certain parts of the mesh to be emissive. Here's the CPU render.


Here is the XPU render.
Edited by Enivob - April 16, 2022 16:29:52

Attachments:
emission_switch.gif (434.0 KB)
Untitled-2.jpg (111.8 KB)
Untitled-1.jpg (45.1 KB)
Untitled-1a.jpg (60.8 KB)

Using Houdini Indie 20.0
Windows 11 64GB Ryzen 16 core.
nVidia 3050RTX 8BG RAM.
User Avatar
Member
8043 posts
Joined: Sept. 2011
Offline
Enivob
Ok, it looks like there is a bug with data flowing through the mtlxswitch using H19.0.591. Shouldn't the fallback data, and thus an attribute value flow through the switch?

I usually use the native mtlx versions of the texture and primvar nodes instead of the usd preview ones. The fallback value is working with the geompropvalue node for me. Although changing to the default fallback value seems to fail to update. The attribute value is working either way.

Attachments:
mtlxgeompropvalue.png (963.3 KB)

User Avatar
Staff
531 posts
Joined: May 2019
Offline
The MaterialX "mtlxUsdPrimvarReader" definition appears to have a bug in it (ie not recognizing the fallback value at all).
I'll pass on the issue to the MaterialX guys.
In the meantime try using the regular "UsdPrimvarReader" instead.

Regarding "Switch" not updating when going back to default, that seems a bug in our UI and I've reported it.

Thanks!
  • Quick Links