was talking to paul esteves and he realized that it works only if its connected through the surface shader but not otherwise... so maybe this would be a nice thing to change? its kind of awkward to test stuff that isnt plugged in. can do an rfe.

im still confused about this, it seems to work differently than the unlit shader. would be great if this worked consistently. anyone know whats going on here?



is there documentation on this feature? having a hard time finding it, seems like this should be easier to understand...

ronald_a
Are you sure the machines are actually using the gpu? We had cases where we rendered with xpu and the Gpu would fail. We also had cases where the cpu and gpu had very weird load. It would go up to 100% load for 2 seconds just to drop to almost nothing for 6 seconds, go back up, etc… i recommend checking the taskmanager (or similar on linux) to see how the load on the cpu/gpu is during those slow xpu renders. To be fair, our problems seems to be related to rendering highres image which xpu which it seems to have problems with (I still need to RFE that)

Yep I checked and the GPUs seemed to be fully active for the whole time

My scene has clouds (volumes), smoke simulation, some instanced bits of particles, a character with SSS, a handful of different objects and shaders and a few lights + per light aovs with LPE tags. So its a bit more complex.


i'm actually not sure what the settings are that its rendering with for cpu, since i have my render settings set to xpu and then the usdrenderfile top is rendering it but changing it to CPU. its set to 256 samples on xpu. idk if its rendering with that many on cpu? regardless though it looks equally clean.

I just made a bug report that included this among a few other issues I found with Karma XPU.

the new change on the usdrenderfile top that requires me to specify the render engines is something I keep forgetting and accidentally have been rendering stuff with Karma CPU. This is something I made a rfe / bug report about a while back.

In this instance though it caused me to discover that render times on karma CPU were pretty similar to karma XPU, which is unfortunate, I'd expect xpu to be a lot faster.

When i rendered some frames on XPU i found that the first frame took longer (i think it had to translate some cop materials or something) and then afterwards it was a little faster.

first frames on XPU:
"BRUH" took 3:27 seconds (64 core threadripper + two a5000s)
"CRUMPUTER" took 2:25 (32 core threadripper + 4090)
"DESKTOP-1HSKGC8" took 3:55 (32 core threadripper + 2 3090s)
"TROGDOR" took 5:16 (12 core intel cpu + 3090)

following frames on XPU:

BRUH 2:59 and 2:48
CRUMPUTER 1:50, 1:50, 1:44, 1:44
DESKTOP-1HSKGC8 3:00, 2:49, 2:44
TROGDOR 4:30

same frames on Karma CPU:

BRUH 2:15, 2:14, 2:14, 2:09, 2:11
CRUMPUTER 2:40, 2:39, 2:47, 2:50, 2:46
DESKTOP-1HSKGC8 3:02, 3:02, 3:10, 3:02
TROGDOR 4:48, 4:58, 5:02

so my machine "BRUH" with a 64 core threadripper and two a5000s was actually significantly faster on Karma CPU than Karma XPU always.

my machine CRUMPUTER with a 32 core threadripper and a 4090 was faster on Karma XPU (no surprise esp with the shader execution reordering stuff that was added)

my machine "DESKTOP-1HSKGC8" with a 32 core threadripper and two 3090s was pretty similar, slower to start on XPU and then slightly faster.

and my machine "TROGDOR" with a 12 core intel cpu and one 3090 was pretty similar too, slower to start on XPU and then slightly faster.

it seems kinda crazy to me that these speeds would be so similar when I have pretty beefy gpus. ill also mention that i'm using
Nvidia Driver 555.99 on BRUH, CRUMPUTER, and TROGDOR.
on DESKTOP-1HSKGC8 i'm using 552.22

on one hand im impressed with how fast karma CPU is rendering the scene, but on the other hand I'm a bit bummed that it's not rendering faster on XPU.
you'd think that having two a5000s would add a lot of extra render speed but apparently it just slows my 64 core cpu down.
karma xpu feels way more optimized for 40 series cards, of which i only have one, and thats the one machine i was getting significant improvements. def makes me wanna sell my 3090s and my a5000s. also kinda makes me want to consider just selling all my gpus and building a cpu farm instead :P

i think this should help

blakshep
I am not sure what are they thinking ,i guess now they felt they needed to score some points with the animators.

Absolutely agree, though had great hopes for this as houdini always missed a proper layout/lighting context, but sad truth its still missing it.

They released this 4 years ago in a pre-alpha state, to never really touch it again.

this is just incorrect, they have had plenty of updates and work that has been done / is being done on solaris over the past 4 years and prior. they have a completely different team of people who are dedicated to animation/rigging.

Jonathan de Blok
Translating native Houdini on the fly into USD will always be a bottle neck. USD in general isn't a performant design, it's made for handling massive Pixar style scenes using cached out animations and instancing techniques.

I think I understand your frustration, but I disagree that it's as big of a problem as you suggest at the moment. I fully transitioned to solaris+karma from redshift and could never go back. IMO you can really mostly ignore most of the USD stuff if you don't want to bother with it, but it can be incredibly handy especially when you are trying to scale up which as you say it's built for.


To me, the main gotcha here, is that at the moment, solaris can't really replace obj, at least for me and many other people I would assume, and a big part of that is due to the translation of native houdini to USD on the fly as you mentioned. I hope and trust that this will change and improve over time, but in the meanwhile, I treat solaris as PURELY an enviornment for doing my lighting, lookdev, and rendering. When it comes to the layout part-- i think most people would agree with me that it's just not there yet, and I wouldn't recommend using it for that.

If you just use obj and then scene import stuff to solaris for lighting etc, it's pretty dreamy. Especially if you end up caching USDs of your scene, which then makes lighting/rendering smooth as butter, and much nicer than working in obj for that. But its super easy for users to get confused about this and end up trying to do it all in solaris, which I think will usually end in regret (for the time being).

There's definitely a lot of UX improvements that can be made to solaris and I know sidefx is very invested in doing this, but it will take some time, and I also want to give them credit that solaris has gotten much much better with important UX improvements that come each release. I'm looking forward to those improvements, as well as optimizations, but in the meantime I do find Karma + solaris to be pretty great for my workflow, and I tend to be working as a solo freelancer or very small studio responsible for all aspects of cg produciton including rendering.

I was mentioning this recently to mark tucker, and have been meaning to provide an example, I just recorded a little video demonstrating the issue where doing material edits in solaris is so slow and requires really just setting the houdini ui update mode to manual. doing basic things like dropping new nodes in the mat builder for example will cause upstream nodes, including sop/obj imports to re-cook. Would be great to make this smoother, video attached!

malexander
MaterialX should work in /obj, though there is the caveat that all VOP nodes in the network must be Mtlx-prefixed.

what does this mean exactly?

ive never been able to get this working so maybe this is something im doing wrong? but regardless its really not obvious what my issue might be.

ive made a video of my issue and will submit as a bug report and DM to you.

Hello!

I know that there's work happening on this new vulkan viewport, but I have been playing with switching between obj and lops more frequently, trying to pick and choose to use the best of both worlds.

the TLDR is that I am unable to get materialX shaders to show up in obj context at all. I would really like this to be addressed because it makes it a lot easier to work with the obj level preview, and im liking assigning shaders in obj (which ive sort of reverted back to after doing it the proper lops way for a year plus) and then bringing them into obj with the scene import. it works great, but I just dont get as nice of a representation in the viewport as i'd like in obj since it doesnt pick up anything from the matx shaders.


here's the longer version:

working fully in solaris is still a huge pain due to the translation from sops to usd that can be a bit laggy. obj is still wayyyy more responsive. so i really like to stick with obj for animation / everything but lighting and rendering and lookdev, and then come into solaris. this works fairly well. it would be great if the sop import was more efficient, but i don't really mind jumping between the two although it is slightly clunky ux wise. also things like setting up camera rigs with nulls and stuff is just way way easier in obj.

i'm finding though also that applying materials in solaris can be a bit of a pain. the mat library can get really slow and lag bewteen putting down different nodes. i'm often having to switch to manual mode just to drop down a bunch of nodes and hook things up and then switch back. it doesn't feel super great. i realized that obj doesn't actually have this issue at all. so recently i've been using more of the scene import vs the sop importer, and it's made my workflow faster and also fixed this material issue. this does seem to me like something that should be looked at on the solaris side though.



i was told that this was fixed, but went to test it in the latest daily build and couldn't get materialx shaders to show up in obj. i'm doing the normal workflow of matnet, create shader, material sop, assign that shader to object. when i do that with the karmamaterialbuilder library i'm just not seeing anything in the viewport shader wise. literally just getting a representation of the base color would be huge, it really doesn't need to be fancy, just something to help with working with animation and previz in obj so that i dont have to have a DIFFERENT shader like principled that displays in obj sops and then change it to a matx shader at the end which is obviously a very clunky way to work. get matx working in the obj gl viewport (and vulkan of course) and i will be sooo happy.

Definitely encourage people to join in on that! Also might be wise to start a discord or google sheet or something. I have no idea what the deal is with riggers working with houdini in studios, I know a good handful of people who are playing with various kinds of rigging in houdini, but im not sure what exactly studios would be looking for from them at this stage.

I've also personally found xpu to generally be faster than redshift, however in some cases, slower to clean up frames (which makes sense as rs has adaptive sampling and bucket mode and rs is just progressive). Rs also of course has the IPC pass which helps clean up GI bounces.

That said, the big thing that killed me with RS was an utter lack of interactivity. Karma having both a great cpu implementation, as well as XPU being built from the ground up with embree and optix, means that you get a much better time to first pixel than rs, as well as more viewport interactivity, and less crashing (in my experinece). plus i've found it to be much less fiddly with drivers and not having to deal with a third party engine has just been a blessing.

i'm personally not prioritizing final render speed over those other things anymore, but i definitely understand if you are, and if thats the case, maybe its worth waiting some more for adaptive sampling to come to xpu at least.

for me though i definitely cant go back to redshift, ive found xpu to be a godsend. I don't tend to do a ton of stuff with heavy refraction though, and I do do a lot of furry characters, deforming motion blur, and sss, so i guess its just worked out better for me.

one thing i will add though on the topic of drivers, I was a fan of xpu, and I recently updated drivers and found it to be sooo much faster and more responsive.

defininitely looking forward to xpu maturing more, it seems to have the most momentum of any renderer in my eyes which is definitely largely due to the fact that it is relatively new, but I am super glad to see xpu very rapidly improving.

i have 3 available machines but it's only running on one machine currently. i did set the "tags" to single, because i want every task to run one at a time per machine, but i want all 3 machines to run at the same time. Any ideas what I might be doing wrong here?

originally i made this character the other day for "Run" -- but didnt get the chance to finish an animation. So I decided to re-use him for "Shadow" where I decided to play around with some custom viewport rendering. I did ultimately render with karma, but it was so basic that I might as well have just viewported it-- i just thought it would be a good idea to crank out a proper exr sequence.

And then i did some fun post stuff with good 'ol COPS

Lots of fun, the point renderer stuff was partly inspired by this amazing 2 year old sidefx talk from mark fancher https://youtu.be/qSkG0ac5RmU?t=2289 [youtu.be]

and did the sound myself in ableton for fun !

Finally hopping into this 20 days late

Made this little seamless loop starring my new character Bulby!

Sculpted this character in medium, everything else done in Houdini. Had some fun with kinefx rigging, custom collision deformers, the spark trails, and rendered of course with Karma XPU!

Hello, is it possible to keyframe the lens shader, and if so how? Seems like it should be. I want to animate the "amount of curvature" if possible.

I can see theres a primvar in the camera prim in solaris which is blue (so not animated) for the "karma:camera:lensshader"

usually I just make a matnet and put the lens shader in there. Was thinking way at least when i make changes it doesnt re-trigger my whole lop node graph. I guess I could put it into a matnet in the graph and set it to allow shader parameter animation, and then i do see the values in usd in the physicallens1 shader, with green values for the curvature, but im not sure this matters at all.

Anyway was just digging around trying to figure this out, if there is an answer would love to know. And if there isn't would love this to be added as a feature!

haven't heard of geometry subsets and not sure how that works? i can look into it but any pointers you can give are appreciated. still seems like this should be doable though with the addition of trace sets !

jsmack
They need to be a single mesh to shade continuously.

right, so basically the answer is no for now hope this gets fixed soon!

I can't seem to figure out how to get rid of these lines. They show up in karma / solaris when i have different name attributes for diff parts of the mesh (which it should because it uses different materials for different parts). But even when the mat is the same, and they have different name attributes, i still get these dark lines. if i just remove the name attribute and give the whole thing one name attribute the lines go away. so theres got to be some kind of way to tell karma that these objects are meant to be shaded together as one piece of geo and not treat them as different pieces of geo just because they have different name attributes.

i think i remember hearing that this was not ready in karma xpu yet and needed to be added (hopefully it will be ready soon) but i was playing around with the principled shader and couldnt figure out how to do it in there either which i assumed was how you would do it with karma cpu.

so whats the deal with this, how should i / can i even address the issue now in karma?

thanks