Howard Matthews

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.