This is now fixed in 17.0.472. Yay

… and the super thing about saving stuff as node presets is that it also saves any spare parameters your preset node may need.

eg. find yourself constantly needing to add a bit of human wobble to your camera? Houdini gives you approximately 792 different ways to do this, but my favourite has been:

Create a null, put some expressions to create some noise on its rotations, and add some parameters to feed/control that noise. You don't want to have to tit about with the expressions every time you want to control the wobble when you can make a baby UI on the Null itself:



The expressions I've stuck on are like this:


Change that 837 to a different number on each axis. Save it as a preset called “Camera wobble” or “Rotation noise” etc. That's the hard part over.

Now anytime you know you're gonna want a camera with a bit of humanising wobble, link your camera to a null, and animate that null with the main camera moves, instead of the camera object itself. Then you can stick another null in between:



and call up your wobble preset:



Now you have some nice friendly wobble controls, just by adding a null and picking a preset. Yummy.

Thanks tamte - I was hoping there was a sneaky simple way, but manually setting them up will do for now

I managed to unlock and alter the POP Source DOP to birth particles based on a source point attribute. Super.

But saving the node has (predictably) meant that the old unaltered POP Source node has gone, so even using the shelf tools sets things up using my new node, not the factory one.

Not a problem - it's easy enough to grab a copy of the factory node and stuff it back into my Houdini folder, and for now I've just added a switch into my franken-POP-Source node so it defaults to the original behaviour.

But what's the correct process to make a new HDA based on a factory one? Renaming HDAs seems to be difficult after creation, so I'm not sure how I'm intended to… well, “Save As…” my altered node.

I'm trying to make something similar to the Add SOP but with more attributes on each point. The Add SOP lets you place an arbitrary number of points in locations you'd like, but only has one extra attribute (“W”) you can set for each point: I need three or four other attribs I'd like the user to be able to set for each point.

A multiparm block will let me do it - but I can't figure out how to add handles to the points in the same way the Add SOP does.

Ideally I'd like each point/instance to display not just a translate handle, but a rotation handle too - though I'd settle for just translate

Any clues on how I'd go about this? Normally I'd have a nose around a factory OP that already does what I want, but the Add SOP give no clues about how the handles are created or bound.

Not quite sure what you're after: you can use a Bound SOP to make a box just big enough to contain the parts, or the Boolean SOP to merge multiple parts together into one union (as long as they do actually overlap); there's also a Convex Hull SOP (if I remember right) that'll give you a closer fitting hull, like the kind you'd want to use for RBD sims, which find concave surfaces difficult to deal with.

What are you trying to achieve?

I've just submitted it - thanks for checking man - I owe you one. My sanity was in question

Nope - just dragging the ends of the bar.

Just tried starting a new session, empty file, dragged the play bar range in a bit and typed in the textport:



Have to try trashing prefs etc. Boo. Thanks for checking for me

Didn't know you could scale the UI from houdini.env. Huh.

But the scaling seems to work properly if you do it from the Preferences dialog. Try removing the line from houdini.env, and setting your UI scale in the Prefs, then restarting Houdini.

Yup - a little frustrating that the old Voronoi Frac SOP has been replaced like this. I don't do much RBD stuff but use the Voronoi Frac SOP for lots of other stuff so it makes me a little nervous having to start dropping nodes with “RBD” in their name in

You can use a textport to add the old one in manually, though. Make sure you're in the right network first:

/ -> cd /obj/geo1

and then add the node with the -e flag (this makes opadd use the name as given, rather than using any later versions):

/obj/geo1 -> opadd -e voronoifracture

Not sure exactly what's going in but flooring the value would be at least tidier and more predictable. Otherwise you're implicitly converting a float to an int - better to be explicit for clarity:

int frame_num = floor(f@age * 24.0);

Pyro ain't my area of expertise, but if you already have a sim you like and just want to retime it, I'd cache it out and then use the Retime SOP to change its speed. It works really well for slowing stuff down.

Mucking with the timescale sounds like trouble

I could be going mad. So can someone confirm this behaviour before I report it as a bug, please?

$RFSTART and $RFEND refer to the start and end of the preview region of one's timeline, not the whole thing, so you could just render out, say, the middle of your scene. But they've stopped working for me: $RFSTART now equals $FSTART, and $RFEND equals $FEND. Which makes them useless:





Should be rendering from 184 to 227, not 1 to 250.

Just me?

(17.0.416 / Mac)

Easiest way to find out what attributes are used is to set up a DOP net and look in the Geometry spreadsheet. You're certainly missing things like @mass and the various spin/orientation attribs.

Unfortunately (as far as I know) you can't dive into the multi solver at the heart of the POP solver to see how it does what it does, but it's probably going to be a collection of simple physics equations. Stuff like accel = force/mass, v += accel/timestep etc.

If you don't use the force attrib, you can manipulate velocity directly (much like the way things like POP Advect etc give you the choice of whether to advect by applying a force or by setting velocity).

And you could probably work out what the airresist / targetv stuff is doing by setting some attribs manually, then stepping to the next frame and seeing what's happened (though that's a little hackery)

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] )