Thanks all - Leaf, that works perfectly

As per subject - if I drop a few instances of my HDA into a scene, what's the simplest way of generating a different seed value to use within it?

I could just put a “parm_seed” parameter on the HDA's interface, but knowing me I'll forget to change it on each instance.

I suppose I could hash the node name somehow to generate a seed, given that Houdini will automatically give each instance a new name (by appending 1, 2, 3 etc on the end), but if anyone has a cheeky expression I can use it'd save me reinventing the wheel…

OK: I've sussed it, but I'm leaving this here in case it helps anyone.

If you use a button strip to return a single (exclusive) integer value, the Token for each menu item is ignored: the parameter returns the index of the selected button.

But that doesn't mean you don't need to create a token for each item.

So creating a menu like this will work fine:



… any channel references to the button strip will correctly return the index of the selected item. HOWEVER, the state of the button strip will not be saved with the hip file.

You need to add tokens, though they can be anything. I've happened to put 0 and 1 in here, but any numbers will do - the channel returns the index of the menu item, not the token (unless you enable “Use Menu Item Token as Value” above).

So this is the fix:



Phew.

My HDAs refuse to remember the state of button strips between sessions. So I've made a minimal scene to test. What am I doing wrong? Any other type of parameter I create works properly, saving its state in the scene file, but button strips don't.

If you load the example file, you'll see a subnet with a little button strip on it:



Change the button strip selection to “sphere”, and maybe dial in a different “Some value” beneath.

Save the file and reload it straight away, and while the “Some value” parameter has been remembered, the button strip has reverted to “box” again.

This is costing me time and hair… any help gratefully received!

I suspect it may be tricky to do this in a foolproof, trustable fashion. It's not about moving the files - that's easy enough - it's about ensuring all the references to those files still work. For example, it's a common workflow to use a wrangle to create (say) instancepath attributes on points, but if Houdini were to collect those referenced files into another folder, it'd have to do some pretty crazy analysis of your VEX code to make sure the folder part of the string got updated without upsetting anything else.

Keeping your assets organised is gonna be up to you, I'm afraid. I agree it's a pain sometimes: while $HIP and $JOB let you keep stuff together, I make a lot of use of $HSITE for assets shared across projects, and if I ever wanted to send stuff to an external render farm, I'd have to copy those site files over and update the references manually. Can't see an easy way round it though

Used to trip me up all the time, and still does every now and again. I'd alter an animation, and when the shot was rendered, every now and again an object (often the camera) would occasionally flick to an old animation position just for a frame.

I *never* want Cache Object Transform enabled, but it always defaults to on. (And why is it usually on an object's “Misc” tab, except for cameras, where it's on the “Render” tab, of all places? Wouldn't the “Transform” tab be a more sensible place?)

Is there a way to tell H to always have it disabled on new objects? Can't find an env variable for it.

I'd be interested to know if people generally find it useful, or a pain in the ar^H^H neck - maybe I should raise an RFE… but not if it's just me ¯\_(ツ)_/¯

Goodness me. This looks ever so useful. Well done.

(but also your username is making me hungry)

Might need to know a little more about how you're creating the effect - is the POP network feeding a smoke simulation?

But in general, if you want particles to fade at a certain point in their lifespan, a POP Color node will do it, though you'll probably want to set the Alpha (opacity) rather than the color. There's a little dropdown box next to the Expression box that'll put in a “fade based on age” expression for you so you can see how it works.

Don't forget to set an appropriate lifespan for your particles in the Particle source node (wherever you're birthing the particles).

Thanks tamte - that's thrown a light on it for me. (And I see you used the same method of permanently disabling a control as I did - makes me feel a bit less naughty for doing it that way now)

I often use ramps to control things like point sizes, so I can weight the distribution: lots of small ones, fewer large ones etc. The ramps usually end up with three knots: one at each end and then the one that I actually want to play with in the middle.

I discovered you can tie an individual ramp knot to parameters, too, like this:



Now I can control the curve of the ramp with a couple of sliders instead. Dandy. You could probably do the same thing without the ramp (using the spline() function perhaps) but the ramp gives nice visual feedback of how the distribution will look. You can disable the ramp now and control the middle knot with the sliders instead:



I can't do this trick in an HDA though. I can have a ramp hidden somewhere inside the HDA, and control it with the sliders, but if I want the ramp to be visible in the HDA's UI, it seems I can only have its default knot positions be literal values, rather than channel references.

So is there a way I can programmatically put the expression onto a ramp parameter's second knot's Value parameter (etc), when the HDA is instanciated?

Thanks /u/jlait: that's great to know. Love these insights into the back-end.

Thinking about it, the VEX stuff in a lot of the factory SOPs - like if you dive into a Bend SOP and nose around - seems to contain plenty of calculations that will remain static across all the elements being processed, so I should have just trusted the compiler to be smarter than me

Ooo - hasn’t thought of using a parameter to store it: that’s super. Much tidier, means I can store the whole shebang in a wrangle preset rather than an HDA. Thanks!

I've written a simple bit of Vex in a Point Wrangle that enlarges any points that'll end up less than a pixel wide in the render. It reduces the point's Alpha to compensate.

The calculation is based on a factor derived from the camera resolution, sensor size, and focal length - this only needs calculating once per frame, so doing it in the point wrangle itself means it'll be evaluated for every single point.

I've got round this by creating another wrangle above that calculates the factor and stores it in a detail attribute: but is there a way of doing it all in the one wrangle, rather than two? A way of saying “you'll need to run this bit of code once, then you can run over all the points”?

Some #pragma voodoo?

Or is the VEX compiler smart enough to recognise variables that won't change per-point, and just calc/cache them once?

I think what's bothering me is that workarounds are certainly possible (eg do all your point generation and a previewable copy-to-points in another node, then obj merge it into the Instance Node) but that they shouldn't be necessary.

Feels like a bug. Toggling a Display flag shouldn't be the only way to update the viewport.

I'd appreciate it if anyone can tell me if they have the same issue so I can RFE it without wasting SideFX's time - I'd hate to find it's just some setting I've got wrong

Trouble is, this is a simplified file - I'm really trying to instance volumes and lights and what-have-you. But this is enough to show the problem.

If I could just copy-to-points, I would

Seems like this is worthy of an RFE unless anyone can spot anything stoopid I've done…

I'm constantly hitting this problem but finally had a moment to throw a minimal scene together to illustrate. I must have something simple wrong.

If I have a bunch of points in an Instance Node, and I animate them, I can see them animating fine while inside the Instance node itself. Jump up out of it, and choose an object to instance, and the animation no longer updates the viewport. All my instances display OK, but they never update their positions onscreen unless I toggle the Instance Node's display flag.

Try it: open the file, and play the animation: nothing happens. Toggling the node's display flag makes it update properly (even while playing!).

Dive into the Instance Node to see what it's supposed to look like - it'll animate fine.

And it renders fine - just doesn't work interactively in the viewport.

Am I missing a setting? Or does it work fine for you?

h / 16.5.571

Can't find info on this anywhere. Even just the scope would be useful: is it only stuff going on within the Houdini app, or could it be external processes (eg Safari, other apps running on the machine, OS overhead stuff)?

I'm running on a Mac, and I've Redshift installed too.

Trying to track down viewport performance issues in a big complex scene, and even with almost everything turned off, that “Unaccounted” process is eating a lot of cycles, it seems.

The crazy thing is that Houdini even runs on my dinky little MacBook (2016 12“ retina). It's the most ridiculously skinny and light little machine, definitely not intended for 3D use; I got it for writing scripts/pitches while away from the studio, never imagining I could use it for anything more than a bit of word-processing or browsing.

And though you wouldn't want to try running chunky sims or rendering, for experimenting and coding it's perfect. And it means that I can have this tiny little sliver of a machine in my bag I can take anywhere, and if I get 10 minutes to myself (a precious and rare occurrence) I can flip it open and carry on creating and learning. Portable heaven.

Back at the studio (ok, the spare bedroom) I have a couple of cheese-grater Mac Pros upgraded to 12-core Xeons and GTX 1080Tis, and they handle my rendering and sims with ease. They're nearly 10 years old now, and while I thought at the time I was making an incredibly risky decision, they've more than paid for themselves…. and they've still got a few more years' life in them.

Man, it is interesting that Apple decide to deprecate OpenGL while at the same time using Houdini to show off their interim ”professional workstation" solution. And Apple's gambits don't always pay off; I hope they don't throw out the baby with the bathwater.

(I'd probably end up going Windows rather than Linux, if I had to; but there's something dark and scary about Win10 and its need to inform the mothership of every move I make, every app I open)

Just to throw my tuppence in too:

I'm a proud owner of two Indie licences - I'm probably a typical example of the new users SideFX are trying to reach. One-man studio, relatively new to Houdini, but with enough exposure to it that I now engineer my project proposals in such a way that I'll get to use Houdini for projects. Utterly in love with it.

And I love my Macs. Hated the whole idea of Apple's walled garden for years, but now I'm in it (and the reality-distortion effect has had time to kick in), I dread the thought of having to go back to Windows, or having to deal with Linux distros and device drivers and all that tech-supporty stuff again. Spent most of my life doing tech-support, but now I'm a relatively successful graphics bod, I don't want to to tech-support stuff ever again, even if it's just for me.

So for me the additional costs of buying a Mac (vs a Win/Linux box) are nothing compared to the amount of time I'd be spending doing all the administration tasks the other OSes require.

I would be gutted to find Houdini (or Blender, for that matter) not working on MacOS in the future. It would feel like a new dark age.

Just got news back from Support that the feature is deprecated.

arctor
all the above notwithstanding, its far better to render to an images seq, save that seq, then make an mov (or whatever) in an app designed to do it - there are lots of free ones around

I'd agree if we were talking only about meaningful renders, but for flipbooks and scratch renders (particularly in the fast-moving mo-graphics field) you may generate half a dozen iterations in an hour as you're testing timings (or whatever) and just want to keep a record of them. Lack of a movie export option creates a burdensome amount of extra work, plus a load of extra file wrangling / organisation.

still love Houdini though