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?

Just to draw this to a close: yep, the pygame.midi module (once you manage to get the damn thing installed) lets you send and receive MIDI data. Finally got a decent jog wheel and (gasp) a practical timecode display, yay. PM me for the code - I'm not putting it anywhere public (yet) as it's ugly

Yay… getting somewhere…



This is Houdini talking to a MIDI-based DAW using the pygame Python module. Which mostly doesn't work apart from pymidi, which is all you need. Getting the pygame module to work on the Mac has been… entertaining. But it's possible.

Gotta do some actual work for a bit but once I get some time I'll get the whole thing going… it's quite fun hitting play on the DAW and seeing Houdini play, and then watching as the motorised slider moves up and down in sync with a Houdini parameter

jordibares
Nice idea the Palette gear thing… I wonder cost wise how is relative to professional audio equipment.

$199 for the starter kit: 2 push-buttons, a knob/encoder, and a non-motorised slider.

Or £106 for my DAW control surface (a Behringer X-Touch One), which has 34 buttons (with sexy lights), two knobs/encoders, and a motorised slider. A programmable LCD display, 12 x 7-seg displays. And it's a solidly built thing.

Whichever path you choose you still have to integrate it with Houdini; button presses are simple to do, but funkier stuff is… well, watch this space

goldfarb
they support MIDI and keyboard inputs…plus the sliders are cool.

They're nice looking, but expensive, and they'd give me the same problem: how to interface them with Houdini

Keyboard taps are grand but I'm after something better. And if I solve the problem for my control surface, it should work with the Palette stuff or anything else that sends/receives MIDI, whether it's a keyboard with a pitch-bend (live control of your character's mouth, anyone?) or a timecode display (because 100 times a day I have to divide by 25 then 60 in my head gahhh).

Plus my controller thingy has a sexy display on it, and Palette Gear stuff doesn't, and I'm just a sucker for blinkenlights. It's my weakness

and my slider's motorised muhahaha take that palette gear

jordibares
Meaning, Midi In does not allow to listen to devices, just open midi file

Ha - hadn't noticed that. But I'm trying to avoid CHOPS if possible anyway; don't want to have scene files clogged up with workstation-specific Houdini control stuff.

I think Python's gonna be the way; when I have a moment I'll install one of the MIDI py-packages and see whether I can get ‘em talking. I’ve had luck using Serial ports from within Houdini already so I'm guessing it should be doable…



¯\_(ツ)_/¯

jordibares
If you are trying to hack it using Python MIDI i would love to hear about it.

I'll keep you in the loop. This is the thing I've got on the desk:



I've got basic transport controls working already just using a translator, but it'd be nice to get the timecode display working too, save me constantly having to mentally translate between H's frame numbers and HH:MMS:FF

(and as an aside, it's bloody frustrating that there's no standard protocol for these control surfaces. You can get audio ones like this pretty cheaply, or video jog/shuttle wheels. But audio-oriented ones don't work with video apps nor vice versa, despite being pretty much the same hardware. Bah.)

CHOPS looks like the most appropriate way to tie MIDI input into a particular scene, but I've got a sexy control surface (buttons / slider / job wheel) that I'd love to use to control Houdini more globally.

At the moment I'm using a Mac utility that converts MIDI input into keystrokes, which works OK, but it'd be much more powerful if I could access the raw MIDI input from within Houdini and do my own finagling with Python: not everything lends itself to keystroke input.

Has anyone done this kind of thing before? Are there any other physical control surfaces that work with Houdini that I could investigate?

I'm guessing I'd have to install my own Python MIDI module, though most of these require you to poll the MIDI input rather than giving you a way to set up a callback.

Any suggestions / pointers appreciated.