With this minimal scene, still seeing “WARNING: Invalid op name network: Object op: kinefx__rigpose” on my console.

HoudiniFX 18.5.393 on a 2013 Mac Pro.

So, after having done that, I get a couple of these messages each time I click on the HDA:
WARNING: Invalid op name network: Object op: kinefx__rigpose

Guessing kinefx__rig_pos.py createViewerStateTemplate() was never called. Any idea what else is missing?

I'm enjoying the new KineFX rig tools. What's the recommended approach for rest angles as input to the FBIK Solver? For an arm with a control only on the hand I'm getting locking elbows, which for bones I was minimizing using a rest angle on the elbow.

Glen

Ah, that's very illuminating. Set Capture Pose does wonders. Thank you, John.

Just made my third stab at the Frankenmuscle, trusting that in 16.5 things have settled down a bit, but I'm getting the same result I always have in 16.0. See the attached file.

Created some muscle geometry and two muscle pins, and put the whole thing together using the Franken Muscle shelf tool. No joy. Digging into the frankenmuscle1 asset I see many errors, starting with the Bone Capture Biharmonic node (/obj/frankenmuscle1/muscle/bonecapturebiharmonic6). Looking at the rig, I see that the capture regions (/obj/frankenmuscle1/internal_core/capture_indices) are not in the muscle pin positions, but clustered around the origin. Since the cregions are nowhere near the geometry, nothing gets captured.

I've seen similar behaviour with the Muscle asset as well, in non-sphere mode. Since fumbling the muscle pin transforms would be a catastrophic bug, I've been assuming it was something I was doing wrong. Any ideas?

Houdini 16.5.309, MacOS 10.12.6, 2013 Mac Pro. The geometry in the attached file is locked, but I can provide the .geo file if necessary.

Good suggestion, and I may do unpack/pack as an interim step. I'd be adding this to an existing custom SOP, and would like to avoid the need for extra SOPs before and after to keep things tight.

Correction, 20-float pCaptData record, not byte.

I would like to modify the cregion capture transform for an existing bone capture from within a custom SOP using the HDK. I think I understand the point (region#, weight) pairs attribute and the detail attribute for the capture frame, but the properties with the cregion names and the transform information are more elusive. GEO_Detail provides a number of promising functions, but they seem incomplete.

Can some please provide me some code snippets for the following:
1) Determine the number of cregions in the capture.
2) Map a region index to a cregion path
3) Get access to the 20-byte pCaptData record for a given cregion, for both read and write.

I think I understand what you're going for visually, but physically the stream from the thruster wouldn't bend as such. Each particle should follow the axial direction of your source that was true when the particle was emitted. A visual bending effect happens when particles further away from your thruster are following a different direction than particles closer to the thruster (i.e. emitted more recently).

Try slowing down the velocity of your particles, to make this difference more noticeable. If all your particles have a high velocity and short lifespan versus the rotation rate of your thruster, the effect is probably too subtle to be seen.

16.0.626 does work well for me for the squab example. It also made a big difference in my more complex example, although I have a lot of tweaking to do before I'm happy with the FEM behavior there. Self-collision is back to working off-the-shelf, as illusionistics put it.

Thanks for your help, Michiel.

Thanks for the replies.

Illusionistics, thanks for the tip. I'll find a use for the Granular Solid at some point.

Michiel, I was able to get the squab example working with more collision passes, as you suggested. I have a more complex model that started all this, too unwieldy to post, in which bumping the passes as high as 16 isn't helping. No sign the self-intersection is even being detected by the solver. Is there a practical upper limit on the collision passes, beyond which we know that's not the problem?

Created a simple squab, and used the shelf tools to make an Organic Solid. Turned on Collide within connected components on the Solid Object in addition to the default collision options, and added a ground plane. When I simulate, the middle tentacles settle intersected starting at about frame 40. See the attached screenshot, in case your mileage varies.

I'm expecting the tentacles to stay separated. What am I missing here to make the mesh self-collide correctly?

Houdini FX Version 16.0.621, Mac Pro 2013, Sierra 10.12.5.

Houdini 15.0.244.16. OSX El Capitan on Mac Pro 2013.

Create a sphere primitive, set the output to polygon mesh. Enable primitive numbers in the viewport.

“I'm Spartacus. No, I'm Spartacus!”

Houdini 15 is pretty clean and zippy for me so far in other respects.

I have a custom HDK SOP which implements a skinning algorithm. It cooks on every frame, updating point positions and a fixed-size block of rigging data stored as a detail attribute. The output topology is always the same as the input mesh. Cook times are in the sub-30ms range.

With this SOP, animation plays very slowly, about one frame per second. Using performance profiling, I see that it's the viewport that's taking up >95% of the processing time.

HDK gurus, two questions:
1) What state info is the viewport code looking at to decide if the viewport geometry needs to be rebuilt, as opposed to just the point positions updated?
2) What are the programming tricks I can use to avoid the unnecessary viewport update activity?

H14.0.291, observed with both Linux and OSX.

Gave it a try, and it works well in practice. Definitely a clean solution. Thanks, Edward.

This also forced me to read the documentation on attributes more carefully. I've discovered a number of opportunities to clean up my data management.

Got a custom HDK SOP, which contains geometry and cooks on every frame. The SOP generates a set of float output values, which are set in parameters for sharing with other nodes.

I connect this SOP to the input of a second SOP, which makes use of both the geometry and the output parameters from the first SOP. As soon as I enter a parameter expression in the second SOP with a ch() referring to the first SOP, instant cook loop. The first SOP cooks continuously. I understand this is quite normal, based on how Houdini cooking works.

The behavior I want is that the output parameter values in my custom SOP be used exactly as-is, without recooking the custom SOP. Google offers three suggestions:

1) Set the PRM_BEHAVIOR_NORESIM flag on the parameters. Did that, and the SOP doesn't seem to respect it. Is it supposed to, or is this just for DOPs?

2) Use a chop to buffer the values, and chop() instead of ch() in the expression. Sounds good, but I haven't found a way to apply this that doesn't just make the cook loop one node bigger.

3) Share the output values in attributes instead of parameters. This would be really awkward, as the output values don't correspond to any entities in the geometry, so I'd have to contrive something. I may want to reference the values from a SOP other than the downstream one which has access to the geometry.

What's the cleanest way to break the cook loop?

Houdini 13.0.477 on 2013 Mac Pro with OSX 10.9, if it matters.

derrick
There is a typo in the “Constrained Object” field on /obj/AutoDopNetwork/rbdangularspringconstraint1. “RDB_Torus” should be “RBD_Torus”.

So there is. Thanks, Derrick. Working now.

Attached is a DOP simulation for testing two angular constraints, where the goal orientation is tied to a control object with expressions. There's a switch in the DOP network to select either an RBD Angular Constraint or an RBD Angular Spring Constraint. Unless I screwed up, the goal orientation expressions are the same in each constraint.

With switch=0 (RBD Angular Constraint), the constrained object follows the control object. With switch=1 (RBD Angular Spring Constraint), the constrained object doesn't move. No amount of swearing seems to help. Tested in Houdini FX 12.5.371.

Is this a bug, or am I misunderstanding the semantics of RBD Angular Spring Constraint?