You should only need to init the vars that are present in your houdini.env file. That licensing issue is new to me - I'm guessing you're using the new Maxon installer. You do need to make sure that you're logged in as the same user when you install Redshift as the one that you run hclient from. What happens if you try running a job manually from that machine (ie with hbatch)?

(just to add - you don't necessarily need to do all this variable set up with scripting; if it's just you using this network you may as well set up an HQueue ROP node with whatever vars you like, then save it as the default. Then whenever you drop an HQ ROP in it'll already have things the way you like 'em)

(another thought: I haven't used this new Maxon installer, but I seem to remember it's not node-locked - so you may have to login manually on the client machine before you can expect it to service Redshift jobs)

I need to be able to calculate where the midpoint of a smooth function will land for a given power. Or rather, the reverse - what power/rolloff to put in if I want the midpoint to land in a certain place.

I'm mucking about with CHOPs, generating my own channel data with Channel Wrangles and VEX. Lots of fun. I'm using the smooth() function to ease between values. It looks a bit like the smooth(start, end, amount, xxx) function works a bit like easep(xxx) function in the Animation Editor, with the power/rolloff parameter moving the transition forwards or backwards in time - values over 1 seem to be... uhh ... reciprocalated and inverted. Or something.

Ultimately I'd just like to work out how to "invert" the function, so if I want the midpoint of the smooth transition to land, say, exactly a quarter of the way through the transition, or exactly 2/3 of the way through, what power/rolloff I would need to use.

Any thoughts/pointers appreciated. Thanks

Logged an RFE and got a very swift and comprehensive response. I used the "postman checking every address in the country in order to deliver one letter" analogy:

Developer response:

"It actually maybe faster to send the postman to every address than it is to try and send to specific addresses in serial. VEX and multithreading gets a bit weird about what is "fast".

Note that if vex had a setvoxel() it would actually be much slower than you may envision. Because we don't know the order, we'd have to record all voxel writes into a large list; sort that list; then play back a second time.

You can actually get a first-order approxmiation of this by just creating a point for each "setvoxel" and using volumerasterizeparticles to copy all those points into voxels. As crazy as it sounds, this might not even be that much slower than if we added directly to VEX, as we'd pretty much have to do exactly this internally anyways."

Interesting, huh - makes me curious about how the data is stored internally, and what layers of obfuscation sit between it and us.

So the fastest way to play with things at the voxel level will probably come down to the specifics of what you want to do. If it's a single voxel you want to access, then a vol wrangle will probably be fast enough. If you're trying to write to lots of single voxels, then creating particles and rasterising them may be fastest.

Sorry cman - never got round to it. Naughty. But I have now. I'll report back if there's any news... just typing out the RFE got my imagination going with things I wanna play with if/when it gets implemented

Well done on getting HQueue set up!

Re your sim: it'll be a number of factors.

Assuming your render is multithreaded, it's understandable that 3 x 8 core machines will take longer than 1 x 36 core machine even if all else was equal. On top of that, though, there's the network overhead as all the machines are trying to read and write to the server, and there's the overhead of having to spin up the Houdini instances.

Network overhead: if you can afford it, it's worth running a 10GbE network (cost me around £300 for the switch, then £50 each for second hand network cards). It's made a huge difference to renders; I can actually comp footage directly from the server, no need to copy it locally. And sims and geo processing is significantly faster. *Everything* is faster.

Houdini spin-up time can be significant as well; I started with plain old HDDs in the render nodes, and when I eventually replaced them with cheap and small SSDs (after all, you don't need much space) they fire up Houdini incredibly fast now. With rendering (my main farm task) picking the right batch size is a matter of balance; small batches mean lots of time spent loading and unloading Houdini, big batches can leave you waiting for that last one to render while the other machines sit around doing nothing.

I'm digressing.

That 20% CPU usage thing - it could be that it's averaging out the usage, so it may be counting the time the machine's waiting for data to arrive or files to be written. Does the sim max out the cores on your main machine?

I've an unlocked HDA that I'm diving into and making changes to specifically for a hero object. As long as it stays unlocked none of these changes will affect the actual HDA asset, which is good.

It'd be even safer, though, if I could disassociate this unlocked node from the HDA asset on disk - get rid of that little red unlocked padlock - and get rid of the "Save Node Type" and "Match Current Definition" context menu items, both of which would spoil my day somewhat.

I don't want to create a duplicate HDA, as this is a single-use situation (and zomg I need to stop feeding my HDA library as it's got kinda obese). And there's nothing to stop me copying everything into a new geo node, but then there's all the parameters, of which there are... many.

Is there a quick way?

Hopefully someone more experienced than me will chip in, but I still can't quite put my finger on what it is you're trying to do, and despite that, this smells like the wrong approach (!)

You have an object moving and spinning, and it's sourcing smoke. There are no collisions set up, and no velocities are being read into the sim, so the smoke's only motion is upward (from the temperature differential) plus dissipation.

What are you hoping to see?

As an aside: if you want to uniformly scale down the speed of an animated transformation - ie reduce rotational and translational speeds by the same factor - it's the same as scaling time, which you can do by adjusting the frame / frame-rate parms on the Alembic SOP. No need to extract components.

If you absolutely have to "scale down" how much an object rotates over a frame, you could slerp between the current and next frame's orients, but I'm not sure what that'd achieve here that couldn't be done more simply.

It'd make the scene easier to understand and debug if you only import the alembic once (make a dedicated "get_the_alembic" geo, say, with an Alembic SOP wired straight to a null called "OUT") then object merge that null into the various places you need it.

Use chs() rather than chsraw() if you want Houdini to expand aliases. Is there some particular reason you're favouring chsraw()? You can still perform string manipulation shenanigans - this works, for example:

The scene is very strangely set up (there's some unnecessary ocean stuff mixed in there making it a little hard to debug). It'd be worth watching a few tutorials to get the basics of FLIP sorted out (the applied houdini ones are well worth the money, but there are free ones out there too).

Not clear on what you're trying to do exactly, but I've limited experience with alembics. When you say you're trying to reduce the inherited velocity, what exactly do you mean?

Scaling rots and translates... it sounds like you're not trying to slow the animation down (ie run it longer) but rather just scale down motion blur, or scale down the velocity that's getting passed into a sim. In which case you may as well just deal with the v attribute directly. Unpack the alembic, add point velocities with a Trail SOP (which has a velocity scale parm right there too, saving you a wrangle).

Or have I misinterpreted what you're after?

Intriguing problem It's hard to give anything but very general advice without knowing more specifics.

30 secs a frame is fairly heavy; if practical, Redshift (or similar) may help knock that down significantly. You mention GPU but not which renderer you're using - if it's Mantra, the GPU isn't helping.

Then it's about batching stuff. 4000 separate jobs is a lot of winding up and winding down of Houdini instances, so if there's a way to consolidate batches of videos together that'd help. Can you set up your scene so, say, 50 films are treated together? Every 75 frames, reset the camera position, set up the next objects. Best to allow a frame or two of "reset" time between consecutive shots to allow motion blurs to reset as well. But that way you have 80 renders instead of 4000. Chunking them into output videos is then just an ffmpeg / shell script task.

Just thoughts, but do colour in some more detail if you want better quality suggestions

The scene you posted seems to hang at the extraction (conversion to RS/GPU) point, because there's a mix of packed prims and normal geo within a single object.

For RS to instance the packed prims properly they need to be in their own object, then you can go to Redshift OBJ > Settings > Instancing and enable "Instance SOP Level Packed Primitives".

In your scene I've split off the packed prims and Object Merged them into a separate geo; it renders nice and quickly

Trying to set up an HQueue client node purely to cook stuff.

But because my scenes contain Redshift nodes, Houdini errors out on load, and the job fails, with lots of “Bad node type found: redshift_vopnet” and “Error: Bad parent found (parent is not a network): mat/redshift_material”.

I'm not trying to render, and the Geometry ROP I'm trying to cook isn't dependent on anything Redshifty.

Any thoughts? There must be other people who use Redshift in their scenes but need to cook stuff without tying up a Redshift License, surely?

Putting this here for reference. Could be that my problems were an edge case (like the rest of my existence, ha) but just in case it helps someone…

Unlike previous upgrades, the move to 18.5 gave me real problems with licensing on my linux machines.

Sesictrl kept timing out, saying:

Licence Manager - machinename:1715 Timeout was reached
ERROR: You do not have read access to server machinename

After many hours, I sussed it: Sesictrl has started (?) trying to contact the server using the machine's name, rather than internally looping back, or using the machine's IP address. So the solution was simple in the end:

Add the machine's own name to /etc/hosts. There's probably already a line to resolve localhost to the 127.0.0.1, so just add the machine's name to the end of that line:

127.0.0.1 localhost machinename

All is well and my various machines are working again. But that cost a fair bit of time to sort out…

tags: sesictrl license problem timing out

(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