I think you're right. After far too much troubleshooting for my own good I finally landed on a very simple solution - adding the LPE tag in a Render Geometry Settings LOP instead of the LPE Tag LOP. I totally missed this option in the Render Geometry Settings node before, but this way I can use wildcards to exactly match the primitive path I'm using in the karma render settings node, and it seems to be working as expected now!

Thanks again very much for the help and hip file, it really helped a lot

Just to add onto the last post, the main difference I'm finding between working geometry lights and not working ones (in terms of generating AOVs, to be clear the lights are all contributing in the main beauty render) is that the ones that aren't working are loaded via asset reference nodes.

The working light group, the fire geometry lights, are loaded in via a Sublayer LOP.

The common denominator between the NOT working geometry lights is that they were all cached out to .usd files using the standard Component Builder workflow with default export settings.

The working geometry lights however were manually imported to LOPs using SOP imports and cached out using a file cache node.

I've tried importing one of these assets using a Sublayer LOP instead of the asset reference LOP, but it's still not generating a separate set of AOVs.

Is there some sort of limitation here in which types of primitives can be used as Geo Light Primitives in the Karma Render Settings node?

npetit
Geo light LPEs are supported in 20.5 for both XPU and CPU.

Geo lights must have the "Treat as Light" tag enabled and have an LPE Tag. They must also be included in the Geo Light Primitives Paths on the Karma Render Settings LOP so they'll be found by the "Split by LPE Tag" option.

Here's an example hip.

Thank you! This already helps a bit, however when I follow the steps outlined in your hip file but in my more complex scene, it seems to just... not work on one of my geometry lights. See screenshots for examples, the "fire" tag works but the "portal" tag does not.

I wonder if I'm missing something...? I don't see why one of the lights would work while the other doesn't. I can confirm that I see the LPE tag and the treat_as_lightsource primvar set to 1 on my "portal" light, and yet it doesn't appear in my AOVs.

Hey, does anyone know if it's possible to add something like LPE tags to geometry lights for Karma XPU? To split up render AOVs by light contribution. As far as I can tell according to the docs it might be impossible and the only workaround I found is for Karma CPU only, unless there's something new in H20+ that I haven't found.

johnmather
If you open the display device and render stats in the viewport, you may get more details as to why it's failing. See "Display device and render stats in the viewport" here: https://www.sidefx.com/docs/houdini/solaris/karma_xpu.html#howto [www.sidefx.com]

Thank you, this is helping - my guess is it has something to do with running out of VRAM. My scene is using just barely more than 16GB of memory just for geometry instances, which is of course more than the VRAM on my GPU.

If you don't mind me asking, do you know if there's a way to break these render stats down further? Now that I know I'm using too much memory on geometry, I need to find which geometry exactly is using the most amount of memory. Rather than painstakingly going through my entire scene testing objects one by one, it'd be nice to just get a list of memory usage per object, or something along those lines. (this might be something fairly basic in Solaris I've totally missed so far, seeing as I'm still learning)

To make a long story short, I'm working on a quite big project right now and realized that my GPU (RTX 4080 16GB) isn't being used on render time at all. Instead, when I first render after restarting Houdini I get this error:

"KarmaXPU: device Type:Optix ID:0 has registered a critical error , so will now stop functioning. Future error messages will be suppressed"



After this error shows up once my GPU isn't even showing up in the list of XPU devices when rendering. Just 100% CPU usage. This remains until I restart Houdini, at which point it attempts to use my GPU only the first time initializing a render and eventually gives me the error above.

I've tried switching from Nvidia Game Ready Drivers to the latest Studio Driver (560.81). For the rest of my system, I'm on Windows 11 and using an AMD 7800X3D CPU, as well as 128GB of RAM. Full PC restart also doesn't fix the issue, and I'm getting the same error in the current daily Houdini build (20.5.328).

I don't have time right now to troubleshoot and find the exact source of the problem, so I'm throwing a hail mary here: Has anyone had the same issue, and if so, did you find a fix for it?

sniegockiszymon
Hey I would like to know why this is so crusial for you that you cant use karma because of that. You can mix everything before shader unless you are using the same type of shader. I've started this question deeper here https://www.sidefx.com/forum/topic/93336/ [www.sidefx.com]

I've demonstrated why in my original post here. If you look at the screenshots you can see the difference between the two methods, one using Karma CPU and mixing multiple materials, and the other using XPU mixing each individual PBR texture before going into a single material.

Simply put, it gives different results and the one in Karma CPU looks much more natural, with natural looking gradients between materials, whereas the XPU method has sharp transitions, less details and generally looks less natural to me. Not to mention, as Jacquesf mentioned, it's just easier to mix finished materials rather than multiplying each mix node by however many PBR textures you're using.

To be clear, in both cases I used exactly the same masks, the only difference is where in the node tree I placed the mix nodes. This is as clear of an example as I can give you.

All in all this is a major workflow bottleneck and I'm actually in the process of transitioning to a dedicated procedural texturing software, because I feel this Karma/MtlX workflow is currently limiting me and ultimately reducing my final render quality.

brians
Although this feature might seem trivial, sadly it requires a very large amount of work under the hood. So although we do have plans to address this, it won't be happening in the immediate term. The current design means we need to hard-code common combinations of BSDFs.

Thanks for the insight, great to know. It's unfortunate but understandable - I know Karma XPU is very different from Karma CPU under the hood so it makes sense that it takes a while to get some of these more advanced features implemented.

I suppose I'll just have to invest in a better CPU rather than relying too heavily on XPU for the moment

I realized in the presentations done so far for the Houdini 20 launch, it was mentioned that Karma XPU only supports mixing between 2 MtlX Standard Surface shaders. Any more and it turns into a regular greyshader. Meanwhile, mixing more than 2 shaders works flawlessly in Karma CPU.

As an example I've ran into this limitation while trying to use the new Hex-Tiled Triplanar texturing workflow, where I'm trying to mix multiple PBR materials on a single mesh procedurally. I can already tell that this will be a reoccurring bottleneck for me, and while mixing the individual PBR textures (albedo, roughness, displacement etc) together before inputting into a single Standard Surface shader works, it doesn't give nearly as nice of a result as mixing multiple shaders in Karma CPU. Attaching screenshots to give an example of what I'm talking about.


So my question is, is it in the plans to work on supporting more shaders in a single material for XPU? And if so would it be expected to be far down the line or could it be patched in fairly soon? Maybe it's hard to say but I would love any possible insights on this.

If there is such a thing that is. To give an example of what I mean: I have, for example, three models on disk in .abc format - tree1, tree2 and tree3. Each of the models use the same PBR textures in the same materials. I want to prepare the tree models as variants for future use, mainly randomly instancing on points, in Solaris/USD.

What is the intended workflow here? It's been a very confusing experience so far trying to figure it out. Every single forum thread or discussion I'm seeing on the topic is filled with confusion, completely different ways of accomplishing the same task, and quite often custom python tools to get the job done. Tutorials on the topic run sometimes over an hour in length, at least the ones I've found.

Surely such a basic task isn't intended to be so complicated? Is there something seemingly everyone is missing here, maybe something new in Houdini 20 that can make the task easier or more artist friendly? Or maybe I've misunderstood something and variants isn't at all what I should be looking at?

Any clarification or help would be greatly appreciated!

Update to this:

Posted the same question on Reddit today and I've gotten a lot of valuable input there. In case anyone's interested, there's some interesting ideas! https://www.reddit.com/r/Houdini/comments/hgsq31/gaswind_dop_vs_importing_velocity_vectors_in_pyro/ [www.reddit.com]

Hey, thanks for the responses! The VolumeLight github link looks great!

I posted about this on reddit [www.reddit.com] aswell, and after a little testing I came to the conclusion that switching from Redshift to Mantra wasn't actually the best option for me in this project. I've now switched back to using Redshift for the moment, but at the very least I learned a lot about Mantra for the future!

Hey!

Before I start, I apologize ahead of time for what might be a bit of a wall of text.

I have a pretty specific scenario on my hands right now - I'm trying to rig up a sci-fi space ship for pyro fx on the thrusters. I started by coming up with a proof-of-concept RND .hip file:

https://i.gyazo.com/114eb0b9cc794d7f9a61b54334972f57.mp4 [i.gyazo.com]

The short explanation of how the sim above works, is it's mainly driven by gas expansion and a gaswind node pumped into a sparse pyro solver. The only shaping outside of that is some slight shredding and turbulence, but as you can see it's overall a very uniform, regular shape and movement.

Now, when I got to actually rigging this on the ship, I realized this setup wasn't going to work - because I have multiple thrusters and each thruster aiming in a different direction. So, I decided to switch from using gaswind, to instead using velocity pointing in the direction of the geometry point normals. This is all up and running, and this is a hardware preview with that setup (blue lines = velocity):

https://i.gyazo.com/0aa0ab3779503717ece97ce182c941b1.mp4 [i.gyazo.com]

So at this point, you can see where I'm going with this - what my end goal is. I want to correlate the blue lines of the hardware preview to the original pyro simulation. The problem, however, is I can't seem to get anywhere close to the look of my original, gaswind driven pyro sim, being driven by velocity instead. Currently this is the look of my pyro sim being driven by velocity:

https://i.gyazo.com/ddc0068df39d5de672d718e16da517f0.mp4 [i.gyazo.com]

So, super turbulent. And this is with all kinds of noises or randomization turned OFF in the pyro source, and both shredding and turbulence turned off. Velocity is purely just pointing in the direction of the normals, which in turn is all pointing uniformly directly up on the Y axis. I just don't understand why it's being this turbulent, I don't see how velocity is that different from a gaswind dop node.

So, at this point I'm just stuck. Does anyone have any idea how I can get my velocity driven pyro sim closer to the look of the gaswind driven pyro sim? Alternatively, is there a way to use the effect of the gaswind node but in a limited area, so I can use a seperate gas wind for each thruster? Preferrably I wanted to keep all the thrusters in a single sparse solver for simplicity's sake, but maybe the only viable answer here is use the original setup but split each thruster into it's own seperate sparse solver, each with a different gaswind node? But then the question is how to rotate the gaswind direction with the ship as it's moving in world space.

I'm going around in loops but never coming up with a viable solution. Any ideas or input would be very appreciated!

Hey!

So I'm working on a personal project right now and it's my first time using Mantra - I decided to switch from Redshift to Mantra because I think it'll work better seeing as there will be tons and tons of pyro effects in this shot, and the redshift pyro shader.. isn't exactly the best.

Now, on top of hopefully being able to make better looking pyro shaders with Mantra, I was also hoping to be able to skip setting up individual lights for my ship model and instead just rely on the emissive materials for volumetric light rays scattering through all the volumes in the scene. Though I can't seem to get this to work. In fact, I can't seem to get any volumetric light rays working? I tried looking up some tutorials on the subject but it seems almost everything is out of date, using nodes that doesn't exist with Houdini 18 to “fake” volumetric lighting.

What is the current “best practice” for setting up and controlling the intensity of volumetric light rays, with or without the inclusion of emissive materials?

For reference, here is the current look of my Mantra render:



This is using one distant light and the emissive textures on the ship for lighting, and with a general “atmosphere fog” volume covering the entire scene.



And this is an old render using Redshift as the render engine. This is more or less the general look I'm trying to recreate:





Any ideas? I'm kind of lost at this point, I thought adding a light and a density volume would be enough to get some good light rays in Mantra, but it doesn't seem like it?