Cool - that's good enough for me

Thanks!

Keeping mats and rops separate from objects seems sensible enough at first, to keep stuff organised. Different contexts - different network types, with different sets of nodes etc etc.

It's a pain when you're working on different parts of a scene in separate files, and then need to pull them together into one, as you have to cut and paste (and reload and reload) each context's nodes separately.

But we can make Material and ROP networks within the /obj network if we want. (Otherwise we couldn't make HDAs that contained, say, a mesh and its material together)

So is there a good reason not to just ignore the /mat and /out nets and do everything in /obj?

It'd mean you could cut and paste in one go. Which would be nice.

Just seems strange: the whole scene sits in a single hierarchical address space, but the node editors won't let you go up to the root level. (Sure, you can see it in Tree View, but you can't cut and paste from there)

Am I going to hit some issue if I just stay in /obj, making a ROP net there (etc)?


* edit to add: if I'm making a thing in Houdini, doesn't it make sense to develop the thing's materials right there by it? If I do as I've been taught and create the materials in /mat, I'm only going to have to move them into the /obj context if I want to HDA the thing later. So why are we taught to use /mat? I don't get the thinking.

I'm rocking a couple of old cheese-grater Mac Pros. They're pretty mean machines: 12-core Xeons, plenty of RAM, but they're definitely getting on a bit (9 years and counting).

I don't feel any urgent need to upgrade, but I have nothing to compare them to. If putting together a new machine would cut my simming time in half, though, that could make economic sense…

So are there any “standard” benchmark scenes - and results - I can use to compare my machines to other setups?

(Blender has long had a standard scene people can render, and then submit their results to a Google spreadsheet: incredibly handy for comparing graphics cards. It makes it easy to judge whether spending a chunk of cash on a particular graphics card will be worth it)

I'm pre-vizzing some long scenes, cutting between cameras with a Switcher. It plays back beautifully in the viewport (the Switcher shows up as just another camera in the viewport camera list). So I can judge the edit nicely when playing back.

The Flipbook generator ignores what the viewport was doing, and generates the whole scene from one camera, which is a pain.

I have to instead select each camera in turn in the viewport, set the frame ranges for that shot, then generate a flipbook, appending to the current Mplay sequence. Makes iterating a bit painful (and error-prone).

Is there some setting I've missed? Or can anyone suggest a script/plugin/incantation that'll flipbook what I'm seeing in my viewport, cuts and all?

Paolo Oliverio
Do you know a renderer I can couple with houdini with faster warmup times?

I've a fair bit of experience with Redshift: one thing that certainly speeds up renders is its option to not reload the entire scene on each frame render. You can specify a set of objects that do need to be updated, and it'll just keep everything else cached ready for the next render.

And of course it's blazingly fast, next to mantra, but it has a number of other limitations, some minor, some major. Mantra is a car, Redshift is a train. Great to have both options. And then there's Octane, and a number of CPU-based renderers available too.

Can you put a hip file up for us to look at? Even with my limited exp of mantra 17 seconds sounds insanely long.

If I want to display a ramp (or any other parameter, I guess), but have it permanently disabled, I have to create another dummy parameter just so I can say

{ my_dummy_parm == 0 }

in the Disable when: box.

And then I have to make my dummy parameter Invisible.

It works, but it seems a bit silly - trouble is I can't find any thing I can stick in the Disable when: box that evaluates to true without referring to a real parameter on the left hand side. So this doesn't work:

{ 1 == 1 }

So - any way to disable a parm without having to create another parm?

(Why permanently disable a parameter, you ask? So I can do this: https://imgur.com/a/e80Ewzi [imgur.com] )

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