(I'm on Linux, but there's a chap on Reddit this morning having exactly the same issue on Windows. Redshift loads fine in the GUI but not via hbatch. Thought I'd finally get round to asking for the canonical solution)

The houdini.env file is the place to set up $HSITE, playing with $PATH, stating the location of plugins like Redshift - at least as far as the full-blown GUI Houdini app is concerned.

But when HQueue asks a client to render something, any houdini.env file on the client's drive is ignored, it seems.

For the last few years I've resorted to stuffing my essential env vars into the end of $HFS/houdini_setup. It works but feels wrong.

Where are environment variables supposed to be defined on HQClients? I know you can add job-specific environment variables within the HQueue ROP in a project, but that seems inappropriate for variables that are static / sitewide, like $HSITE.

People running Redshift on an HQueue farm, where do you add your redshift folders to $PATH?

Gerardo Castellanos
I put this on my callback script (python)

hou.pwd().hdaModule().node(“paint_zoneID”).setSelected(True)

I got this error message

SyntaxError: ('invalid syntax', ('<stdin>', 1, 28, ‘hou.pwd().hdaModule().node(\xe2\x80\x9c./paint_zoneID\xe2\x80\x9d).setSelected(True)\n’))

I just got this error too Turns out it's the forum's fault - if you look carefully you'll see the quote marks in the snippet you cut and pasted are “smart quotes” - 66 and 99 - rather than good ole' fashioned code quotes. Delete them and retype them.

But besides that, I also had to remove the hdaModule() bit.

Depending on what your HDA needs to do, you probably need to move the display flag to your Paint SOP too, so my callback ended up looking like this:


… plus I had to add a similar button to “finish” painting and move the Display flag back to the end of my network again.

Cool. A TC/beats display may as well have its own pane you can put where you like, rather than being in the viewport, but this'll do me nicely until I get time to learn some Houdini-UI skillz

Ha! That's spectacular. I'd never have guessed that existed… crikey, I'm going to be using that for all sorts of feedback now. Thanks!

This seems to create a new viewer state though - ie the text will disappear the moment I exit it, say, by hitting Escape to go into viewport navigation mode, or Enter to use a handle/manipulator.

I'm trying to create a persistent UI element, independent of viewer state: is this not possible with Python?

I'm working with music, and I'd like to put beats and bars in the corner of the viewport. Not dissimilar to the fps/render time display you can enable with Display Options > Guides > Show Time.

I've got an external MIDI display working by registering a callback with hou.playbar.addEventCallback() so I imagine I'd need to take a similar approach, but how do I actually write a string of text to the viewport?

The only clues I've got are the custom viewer state examples in the docs; there's a text_drawable object I could create but I'm not sure how to actually tie its draw function into things.

Suggestions etc appreciated

Heh - that is akin to the postman knocking on every door in the country to see whether it happens to be 96 Birchwood Crescent, Croydon, so he can deliver a letter. But yep, technically possible

I’m gonna submit an RFE for a vex equivalent of hou.Volume.setVoxel() though: not least because it gives me a cheap way of having a rudimentary 3 dimensional array

Tamte, that’s spectacular. You’ve not only answered my question but given me a whole technique to explore I hadn’t thought of. Thanks

Yep, there's other ways to skin this particular cat. But this is only one cat. I have others, and they're not all as easily subdued.

And besides… being able to directly write to a voxel in a volume seems like something one ought to be able to do on those odd occasions where you want to tweak values directly. Seems needlessly complex to have to create and rasterize points just because I want to change the value of the voxel at index 972.

Are points the only way of storing multidimensional data in Houdini? Seems horribly inefficient, but I'm not sure there's a way to do it in VEX directly in an array without cheating: an array stored in an attrib on a 2 dimensional grid of points, maybe. Eww.

We can read voxels, get their index number, convert between that and the voxel position, etc etc - gotta be a way to write one surely?

I'd like to put it forward as an RFE, but if I've missed the obvious, please let me know and save my embarrassment

I can't decide if this is a stupid question.

Vol Wrangles are great for doing something to every voxel as fast as possible, where you don't really care what order they're processed in.

I need to go through the voxels in a specific order, though, updating surrounding voxels as I go. I can sample any voxel I like (with volumesample), so I can iterate through in the order I need, but how do I write out new values to other voxels?

Or am I going to need to convert it to points or some other data form first?

(I'm doing a kinda flood-fill based cloud pruner. Imagine filling a volume with some nice fluffy clouds with space between them - a bit of tweaked turb noise. Some of the clouds will be cut off hard by the volume's bounds: I want to go round each side of the volume and remove any clouds that are cut off, without affecting any clouds that are fully contained in the volume.

Which means I need to do a kinda of “voxel connectivity” thing: start at one edge, anywhere in that first slice that there's a voxel > 0.0, set it to 0, but then mark the neighbouring voxels on the next slice as needing inspection. Then carry on through the slices of volume, but only checking the marked voxels each time. Do this process from each side of the volume in turn and you should be left with only 100% unchopped clouds.

There are other ways of approaching this particular problem but this'd be the simplest way to create the tool I want. Not least: I could do it in reverse - mark a position within a nice cloudy volume, and fill outward to select just that single cloud and ditch anything not connected by “active” voxels)

I hate this aspect of my work. Solo shop here, so I'm the tech support as well as everything else. And I'm currently having to support 3 OSs.

Mac OS: I just haven't found any editing s/w as fast as FCP X. It's an incredibly frustrating package to use at times, but the rendering, and the way background rendering is tied into things, makes it incredibly fast for throwing comps on a timeline and playing with timing and scratch grades. I can drop several 4Kx4K layers with transparency on top of each other on the timeline, and it plays back pretty much immediately. It's a maxed out 4,1, NVMe drives and all that jazz. But the GPU situation means I now have to run…

Windows: After Effects just runs faster on this machine than the Mac. Multiple GPUs not a problem. But it's a horrible operating system to use - I get that this is a matter of opinion - but the whole “I'm gonna install updates regardless of whether you're mid-render” thing, and the constant update=reboot thing is a pain. But it runs Tomb Raider really well (gotta research the latest in real-time gfx, eh? On-line / off-line rendering convergence… it's *research* sweetie)

Linux: Houdini just seems to *feel* better on Linux. Once I'd learnt how to uhh… linux, it's worked out really well for Houdini and Redshift on my tiny farm. Everything feels solid; it feels like I'm closer to the metal than the other OSs. So I've ended up with Centos or Mint on more machines on my network than any other OSs.

But it's frustrating that I can't find one OS that does it all. I love Mac OS as a user experience; managing all the start-of-the-pipeline “officey” stuff, bouncing scripts around etc, and I trust it when it comes to colour management and the end-of-the-pipeline stuff. But Linux feels like an extension of Houdini somehow, and it just works. Windows… eating glue in the corner of the classroom, but it's the only way I can comp stuff at any speed (at least until I drop several grand and lots of learning time on Nuke)

My couple of cheese-grater Mac Pros are over 10 years old, and I'm typing this on my main workhorse one. It's got new CPUs, has had a new GPU every year or so; it's been spectacular. Best investments I've made in the IT world, really.

So I'd love to think a shiny new Mac Pro would give me another 10 years - but I'm still sore about nVidia. Yep - looks like you can upgrade the RAM / CPU, but I look at those inviting industry-standard-looking PCI slots with distrust. What does it matter if the slots are industry standard if Apple prevent half the industry from writing drivers for their cards?

* * *

I can afford to chuck out the Win/Linux Threadrippers and buy new ones every few years, if necessary, but for summat as costly as the new cheesegrater, I need confidence in its longevity.

Apple are both my reliable companion (iPhone/MacBook/macOS), and the petulant, unpredictable child in my life, constantly threatening my workflow with their whims.

/rant

Whelp - it's horrible code, pls wear thick gloves - but I'm not likely to have time to tidy / refactor etc for a while, so here it is:

https://gist.github.com/howiemnet/280d937d3507950a62b516dd93dcae38 [gist.github.com]

(warning - it's hardcoded to display timecode in 25fps format cos it was just for me and that's all I use)

In a nutshell: install the Python pygame stuff, and Houdini can then send and receive midi messages. You can add callbacks within Houdini to call your code every time there's a frame change (if you want to update displays etc), and you can have H poll your code regularly to see if there's a midi message (play / stop etc) it should act upon:

hou.ui.addEventLoopCallback(yourCheckForMIDIeventsFunction)

hou.playbar.addEventCallback(yourUpdateTransportFunction)

Took less than a day to knock together, and it's been in constant use for several months without a glitch. I'd hate to go back to life without that jog wheel now; particularly when tweaking and tuning character animation. Yay Houdini

Andr
there was indeed a better way to do that

Yeah but now we've learned a variety of alternative approaches that may come in handy one day

And thanks jsmack - that's perfect. The excuse I needed to do move it into a wrangle instead of a VOP (I do get a bit tangled in VOPs after a while, but they can be handy for finding the right function name - that “View VEX code…” thing is a godsend)

Thanks, andr - that's great. May not be tidy but it'll do for now Much appreciated

I'm sampling pixels from a bitmap to control point attribs - rows contain the values I need, and I scan across the columns to animate the attribs across time. Simple enough.

But I may want to extend the bitmap sideways to lengthen the animation time, so I need to know how many pixels there are to divide my “u” coordinate by the right amount.

Is there a way I can avoid hard-coding – or requiring the user to update parms – my bitmap file's dimensions into my VOP SOP? The SOP's already got the filename as a parameter, which it uses with a Color Map VOP to actually grab the pixels.

Ahh - so Houdini *does* use the node path/name as its sole identifier. Fair enough. I can work with that.

Thanks all for your help and insights

Thanks - but I'm not sure how this helps. I'm using instancing, so these are basically just objects with a single point inside, referring to a disk instance. Not sure what the Assemble SOP would give me in this situation (unless you mean I should hash one of the attribs it generates?)

I'm manually placing copies of objects (ie at the /obj level) but need each to have some random stuff internally - spin axis etc. So each object needs a different seed value to work with internally (@ptnum has no relevance here

Houdini must use some kinda UUID-ish thing internally to refer to objects, so you can rename stuff and all the references across the scene are updated (right? Or does Houdini just do a global “search and replace” whenever you rename something?)

But I can't find any kinda unique number in objects' detail attributes.

Or do I just have to hash the objects' nodepaths and make my own? (I'd rather not if I don't have to: it'd be nice to be able to rename a node without it altering its unique seed)

Answered my own question: you can edit the presets' .idx files and remove the lines you don't want in the opvalues section at the bottom. Not sure whether there may be bad side effects, but it seems to work.

This is ace: I can now have presets that just overlay a subset of settings without annihilating everything. Yay. Does feel naughty though.

As per title - is this possible? For example: I may have a couple of camera node presets I like to use, but if I've already positioned a camera, applying a preset resets its transforms too, making any preset useless.

Or a Mantra ROP preset that doesn't change, say, frame ranges, but sets all the sample parameters.

Is this possible with the normal preset UI, or do I have to roll my own pythony thing?