The point position and overall transform of an agent is always the agent's root transform, so I think the easiest approach here is to move the point so that other joint is positioned where you want.

After spawning the agents, you can read the transform of the relevant joint, and then use that to adjust P however you want
e.g. to get started:

There is a new SOP Import parameter to configure this in tomorrow's build, 21.0.464

The multiplication should be in the opposite order (`Mw * M_agent`), but otherwise that looks reasonable to me

The result from `agentworldtransform()` is still in the space of the agent packed primitive, so you'd also need to combine it with the packed primitive's transform that you get from e.g. `primintrinsic(0, "packedfulltransform", @primnum)`

You could then use a function like cracktransform() to extract different components

Attached is an example of a custom trigger which reads the velocity attribute from the Bullet solver

I'm not sure if the USD docs explicitly talk anywhere about the render-time skinning. The closest I found from a quick search was
https://openusd.org/dev/api/_usd_skel__a_p_i__intro.html#UsdSkel_API_BakeSkinning [openusd.org] which is more an indication that you don't need to bake out the point deformations

For performance reasons I wouldn't recommend unpacking on each frame of the simulation
If you're only examining the joint velocity / angular velocity for ragdolls, there would already be array point attributes on the agent which provide the velocity of the rigid body associated with each joint (https://www.sidefx.com/docs/houdini/nodes/dop/rbdpackedobject.html#agentattributes)

You could use VEX functions like https://www.sidefx.com/docs/houdini/vex/functions/agentlocaltransform.html [www.sidefx.com] to query the transforms of specific joints

Perhaps I'm not understanding the question, but Hydra already supports render-time skinning for UsdSkel (otherwise, you'd need to always be applying something like the Bake Skinning LOP to see deformation).

The motor target position is clamped to be within the allowed translation range, so you'd need to have a non-zero translation range along at least one axis for there to be any noticeable effect (similarly, the target rotation for the motor should be within the cone rotation limits)
Depending on your setup, you might also need a higher Target Position Stiffness too to see a more noticeable effect

I think you'd want to configure most of the attributes to not be time-sampled using the Set Default Values parameter - e.g. in the attached file this is set to "* ^transform" so that only the instance transforms are time-sampled

I haven't got the source animation downloaded to test out, but if the animation is in-place you would currently need to add locomotion to it yourself. E.g. if it's at a pretty constant speed, add a transform SOP to animate the skeleton at the constant velocity after the FBX Animation Import SOP. There would be more procedural ways to do this, of course, but that's the simplest approach to describe if you don't have many clips to deal with

(Alternatively you could also directly set up the __locomotion__ joint on the skeleton, but it's probably easiest to visualize the motion on the whole skeleton and then extract locomotion afterwards)

redpaw
What I'm ultimately after is being able to swap out the agentShapedeformer on particular shapes after the
Agent is set up.. Is this possible without unpacking the agent?

For example if I were to swap linearskinning to blendshape on a specific agent?
What node / workflow could I use to do this? Can I do this with an attribute?

The deformer is a property of the shape binding (https://www.sidefx.com/docs/houdini/crowds/agents.html#layer), so you had the right idea with creating a separate layer which binds your custom deformer to the shape.
Then, after you've populated the crowd you can use something like the Crowd Assign Layers SOP, or just an Agent Edit SOP etc, to switch which layers are assigned to each agent.

redpaw
Is this something related to a draw override when agents are packed, that they only evaluate linear or blendshape ?

Yeah that's correct, the viewport only provides shaders for instanced linear skinning and blendshapes for agents, so custom deformers are only applied when unpacking or for non-viewport rendering, etc. I suspect the viewport is falling back to linear skinning for unknown custom deformers so that there is still some visualization of the agents' pose if possible.

I don't think there's a workaround other than unpacking, but this would be something to submit an RFE for

No, that all is specific to OP nodes. It should be roughly something like:

redpaw
In this case, does "deform" still work similarly/replacing (cookMysop) at the sops level? or is it different? I see that you get access to a detail based on what "shape" is passed to it, which I assume is a standard detail gdp I can iterate thru the points of?

Yeah this would be essentially the same idea - the GU_Detail that's provided contains a copy of the shape's rest geometry, and your deform() method should modify it to apply your deformer
Unlike a SOP node, one thing to note is that there is only a single instance of your deformer and its deform() method might be called in parallel to deform multiple shapes. So you just need to be cautious about any caching anything in member variables of your deformer

redpaw
Also hoping that I can access the "rig" skeleton to get transforms/names etc.. from the GU_Agent that is passed?
I'm a bit fuzzy on what the "xform_idx" refers to, any better explanation for that? What data array is that an index into?

Yes, from the GU_Agent you can access the joint names etc via GU_Agent::getRig(), and methods like GU_Agent::computeWorldTransforms() will give you the agent's current pose

The `xform_idx` is from the shape binding [www.sidefx.com], and would be >= 0 if this shape was attached to a joint in the agent's skeleton. This would be an index into the agent rig's list of transforms
As the documentation notes, you may not need to do anything with this since the resulting geometry is always transformed for you afterwards by this joint's transform. But for certain deformers you might need this (e.g. the skinning deformer first needs to apply the inverse of this transform)

redpaw
There is only explanation in the docs.... "Deformers are registered by calling GU_AgentLayer::registerDeformer() from the GUregisterAgentShapeDeformer() entry point." but I'm not entirely sure what that entails? Are there other examples of "registering" nodes I could reference?

You would need to have a function named GUregisterAgentShapeDeformer() in your plugin, which will be called when it's loaded by Houdini - https://www.sidefx.com/docs/hdk/_h_d_k__intro__creating_plugins.html [www.sidefx.com] has some more information and an example for the newSopOperator entry point
The SOP_BouncyAgent HDK example also has an example for GUregisterAgentCustomDataItemType() which is essentially the same idea as GUregisterAgentShapeDeformer(), just with a different function name

Great!
One other note is that you might be able to use GA_Range to build the point range from the primitive offsets, something like (untested)

I think you likely want GU_Detail::getLookupTable(attrib) which can give you a list of the unique string / int values for the attribute, as well as a list of the element offsets for each value which you can iterate over

Since ragdolls are using the Bullet solver, the important parameter would be the Geometry Representation on the static object's Collisions -> Bullet Data tab. If it's a convex hull, that isn't an ideal fit for your concave terrain (you can check by turning on the collision guide geometry) and the ragdolls are likely inside the collision object when they activate

There isn't really any issue with using multiple static objects for different regions, such as a separate one for the ground plane and the protruding regions. Or, turning on Convex Hull per Set of Connected Primitives can work nicely if your terrain is in several separate pieces
A height field might also be a viable approach here.

If it's the scene graph details pane you're referring to, that's expected because each agent has its own unique `SkelAnimation` prim (which describes its pose), while the 'geometry' child prim is instanced since it contains the rest geometry that's shared between the agents

The viewport playback is not currently expected to be as fast as the SOP viewport, due to the lack of instanced GPU skinning when rendering through Hydra that I mentioned in the other comment.

If it's the "Visualize Instances" option on the crowd procedural you're referring to, then that would mean that none of the SkelRoot's will be instancing the same deformed geometry (there are also some stats about this in the render log, if verbose logging is enabled)
You could try adjusting the tolerance parameter to see what effect it has