With every new project I like to experiment with new stuff to find cool things I didn't know about and to learn more about 3D in general. I decided to upgrade my Mardini bee and thought, hey why not, let's finish it up in Solaris.

Here's my feedback about the experience. I bet a lot of these are going to boil down to just stuff I don't know, but some may be genuine bugs or things that can be improved.

Preliminary verdict: working in Solaris was a pleasure and I didn't run into anything that I felt was missing or wished I could do but couldn't. I think once a few of my relatively minor concerns are addressed (Houdini 19 maybe?!) it will be my go-to renderer.

First, the render, then my comments below.



The Good

- It's really easy to bring geo in from /obj, including groups (via the name node) and vertex colors.
- It's simple to set up a very clear scene graph, cameras over here, geo over there, lights here, etc.

- It's great to have the viewport IPR, giving quick feedback when things are changed.
- I have a custom OCIO config (brian.ocio!) and Karma seemed to know what was up and I never had any colorspace issues.
- The camera focus visualizer is the greatest thing ever, even better with the OpenGL DoF approximation that you can turn on.

- The finished scene rendered super fast, only about 5min on my kind of old desktop (i7 something).

The Bad

- I originally had all my mats in material builders, but that seems to break updating the Karma IPR. Put a shader into a mat builder and no changes propagate up to Karma. You have to disconnect the shader from the collector and reconnect it for it to see the change. This is solved by not using mat builders, but then you get this big ol' mess.

- EDIT: Resolved this. I moved the matnet to the top of the tree and split up my material assignments per section of the model. Lag gone! There is some massive lag if you have the view flag set at the end of the tree, after the matnet. It seems to need to cook the entire material collection every time you make a change. Move the dome light 1 degree and something starts thinking and it all grinds to a halt. Set the view flag before the matnet and it's nice and snappy.
- I ran into trouble with my wings in that the principled shader doesn't have thin film. I ended up using the classic shader and it looks great, but it's a little odd that the "main" shader doesn't have that feature.
- Shader assignment gets more and more confusing as you add new ones. This list is so visually monolithic that it takes some real thinking to find what you're looking for. I suppose it would be possible to break it up across several nodes (wings, body, hair, etc), but still...

- Solaris is a little bit crashy. Not too much though, and honestly I feel like Arnold or Octane would have crashed a bunch too, so no big deal. But it did happen 5 or 6 times today.

The Ugly

- Render region in the image mode of the Karma IPR is broken. I submitted a bug report about it, but this makes it really really hard to fine tune individual areas. I couldn't look at just the eye since the ENTIRE thing had to keep rendering and it took forever to converge on the spot I was interested in. Render region worked way back in 18.0, but something broke over the last few months. MINI EDIT: There's a crop feature in the Karma properties that lets you zero in on a detail you want to work on. But, trying to guess a set of coordinates between 0,0 and 1,1 for the crop area is suboptimal. I'm definitely still looking for a real render region feature in the next update.

So there you go, just one ugly! All in all Solaris and Karma are very good and useable. I love that everything works as I expect and I can get EXACTLY the look I want. I didn't feel I was making any compromises. There is nothing in the finished scene that I feel would have looked better in Arnold.

It was a fun project and I'm excited to see what improvements SideFX is cooking up for the next release!

When you had the shaders in a material builder, did you have that material builder plugged into a collect and point to the collect on the material assignment? I think that would be the methodology for if you were making you asset compatible with multiple renderers, and putting them all into the collect. Then husk determines which branch to climb based on your renderer. Just wondering if that would have resolved your not updating issue as just a better workflow, or if it is a bug.

mrxalpha
When you had the shaders in a material builder, did you have that material builder plugged into a collect and point to the collect on the material assignment?

Yep, that's what I did, but I still had the problem with changes not being seen by Karma. It's a complicated topic so I wouldn't be surprised if I'm missing something, but as it stands now I tried a bunch of stuff and nothing worked. I did have a similar bug in an earlier project that I reported to SideFX and they confirmed. Hopefully will be fixed in H19!

Have you tried the material linker instead of assigning the materials through the material library node?
I personally prefer that.

No_ha
Have you tried the material linker instead of assigning the materials through the material library node?
I personally prefer that.

Yes, I found that recently and started using it instead. Much better!

While we're at it. I have another "issue".
The AOVs seem to be ordered alphabetically. So when I exported one called "Backlight" that was shuffled to the first RGB input. The next time I opened the project, the viewport in Solaris now showed the Backlight image plane instead of the color, because color wasn't first. Took me quite some time to figure out why my render was suddenly pitch black (in interactive mode). When doing a render to disk, Karma will send a notice to the console that it shuffles Color to the main RGB channels, so it would be nice if color would always default to the first in the list, including in interactive mode.
Or maybe a way to manually set which channels should go into the main RGB channels.

Even if that behaviour isn't changed, maybe this description will help somebody to save half an hour of figuring this out.

No_ha
The AOVs seem to be ordered alphabetically. So when I exported one called "Backlight" that was shuffled to the first RGB input. The next time I opened the project, the viewport in Solaris now showed the Backlight image plane instead of the color

Yes, the viewport and husk behave differently here (and I agree it's not super-obvious). There's an existing RFE to address this.