David Pekárek

szabolcs.illes
Hi,
How could a gallery be shared with others? The goal would be that every artist would have a gallery category folder and that would be used to drop nodes into. So I created a category inside gallery. After when I drop a node into it it is saved to a local drive which means it is not shared with others. Can any ENV. VARIABLE exist to save default galleries into different loaction? I tried HOUDINI_GALLERY_PATH but i think it is only for read galleries from.
Any Ideas ? THX!
G

Hi, these are some things I learned about using galleries in a collaborative environment:

In Gallery Manager, you can right click any item and choose Edit. In the window that pops up you can modify a bunch of stuff.

"Gallery path" entry specifies in what gallery file on disk is it saved in.

"Category" entry, translates into folders in the Gallery Manager interface.

Long story short, if you want, for example, a shared gallery for a project called "Car_chase", you save your item into a "/project_folder/Car_chase.gal" file, and set its items Category as "Car_chase". Anybody who loads that gallery file will see a new folder called "Car_chase" populated with the stuff anybody put in there. Done.

There is a couple of caveats thou. If you drop a new item into a Gallery Manager, it will inherit a Category based on the folder you've dropped in into. It doesn't know thou, in what gallery file you want it to be saved into. So it defaults to your local gallery file unless you edit it manually. Super annoying.

Another thing is that if you want to access a gallery file stored in some arbitrary location, Houdini will not load it automatically (of course). Unless you want to be adding it manually every time you start Houdini, you need to either modify the houdini.env file, or use some sort of a scripted solution.

Editing env file may seem to be easier but the major disadvantage here is that it is hard coded, and it doesn't offer anything in terms of automation. It's good enough thou if you just want a shared sandbox for artists somewhere on the network.

With Python scripting you can push it a bit further, and avoid most of the manual editing, but still HOM support here is rather basic.

cheers, D.

Alright, thanks for your answers Mark, I'll stay tuned for the future development.

Hi, my post will maybe sound as a rant, so let me first appreciate the effort Sidefx have put into developing this new LOP context and Karma. I think the general idea of LOPs is great and having Karma is exciting, but right now it needs more work I think, before everybody will be able to use it in production. Fingers crossed

So after some testing, I've got some feedback and a few additional questions to those already answered:

1 - Apart of mplay support, does anybody know whether there is going to be any sort of more dedicated render window, similar to Render view? I mean it has all sorts of convenience functions, like region render, mouse tracking, ROPs list, Cameras list, progressive render on/off, auto-update switcher, pixel inspector, and others. All this seems to gone away with rendering through viewport. Is Image view (Space+5) supposed to become that? Right now it doesn't offer any additional functionality compared to viewport.

2 - This is not exactly a Karma question, but I don't understand the LOPs camera. It's different from SOP Camera, and I find the LOP one very inconvenient to work with right now due to some bizzare controls (or maybe a lack of it). Am I missing something here? Is LOP camera going to be improved significantly? I can still import my camera from SOPs but that seems to be broken right now (when you move the imported cam view it breaks it). On top of this, the resolution is dialed in Karma not on camera which is not great in my opinion. What I am missing are especially these things - a convenient way to set the image aspect ratio and standard image formats, separate zoom control, crop region, rendered resolution, different projections (panoramic, etc.). Of course, a bit more modern take on camera would be very appreciated - physical controls (ISO, exposure, white ballance…) and a nice collection of lens shaders (glows, flares, etc) would be more than welcome.

3 - How you do ray contributions and ray limits with Karma? I figured all this is supposed to be controlled per object with Render geometry settings LOP, but it doesn't seem to do anything. Broken?

4 - How can you get verbose? There is a statistics tab but right now it doesn't seem to do anything (on Windows). Also, it'd be great to have switchers for different things to show up in verbose rather than a slider. I mean, I might wanna just see a texture handling info and nothing else for example. Not sure if that's feasible to do but would be great to have.

6 - Could Render scheduler become a bit more useful? I mean, It alwas pretty much only told you that something is rendering. What about some more functionality, like estimated time remaining for the frame/job? Or maybe a clickable path where the output goes? Or a click to open sequence in mplay?

7 - I presume features like LUTs support, cryptomatte, render scripts, image overscan, image filters, auto-folder creation, render missing/invalid frames, etc. are not there yet, but will be soon?

8 - Given how things have changed now, is OUT context become eventually obsolete and removed, alongside with Mantra?

9 - How dependency/chained renders, or generally complex render scenarios, are (will) be implemented into LOPs?

10 - Is Texture baker gonna be translated into Karma world?

Well that's a bit more questions than I thought I'll ask at the beginning, but that's what I'm wondering about in terms of rendering with Karma. Some of those things are just a convenience features, but alongside with a new renderer I was a bit hopeful that some annoying persistent old Mantra quirks will go away in favor of a bit more modern user experience. Others are absolutely critical for me to even consider using Karma as a production renderer (which I'd very much like to).

Cheers, D.