Hello,

I am currently working on puting a vellum sim on top of agents after a vellum sim following this tutorial [www.sidefx.com].

At step 4 they showcase how it is possible to put attach constraint on the agent but puting down an attach to geometry node.
My issue comes when you do that and you don't want to use the ‘Use closest location on Primitive’ checkbox. If I don't use that it seems that that constraints after the post sim unpack are connected to the wront points of the agent.

I usually specify which points are connected to which points and agents usually have 1 or 3 primitives as polygons soups so it is an issue for me to only be qble to connect to primitives and not points.

I join my hip file in houdini 18.0.460 sim1 has the issue and sim2 and the checkbox enabled for reference.

If anyone can confirm that this might be a bug, I will send a message to support.
Any help appreciated.

Thx

Hi Kadeno,

I have checked your file, it seems working fine on cape geometry, if doesnt stick to the right closest point on the agent primitive probably gemetry doesnt have enough details which you can increase iterations parameter on agentunpack node. and I could see your network that you used grid object for vellum collision geometry instead of agentunpack geometry. that makes you the problem in the setup.

Hope you find this useful.

Cheers.

Hey,

Thanks for taking the time too look at my hip file.
I am not sure if I understand you corretly but here are a couple of key elements that you might be missing :

• My main issue is the point of the string of the hat suddenly being attached to the arm in sim1.
  
• I acutally want to use the grid object as collision geometry to setup the constraint for the sring as I whant the rope to be attached to the hat and not the agent.
  
• I feel like the vellun agent unpack after ‘create_agent’ already unpack everything that might need to be unpacked.
  
• The cape indeed works fine even if you uncheck the ‘Use closest location on Primitive’ checkbox which why I believe the unpack for vellum node might be failing the retarget the constraint porperly.
  

Let me know if there is anything I am not understanding.

Hi Again,

I got your point, Here is What you missing on.

we can use grid/hat any objects on vellum collision but for crowds the geo should comes from agent. So, you can add them into agent shape library then use that for whatever you want to do.


And after crowd Simulation, If you do vellum sim separately on cape and hat, It works properly bcoz of clear inputs.


Hope you got it now!!

Well when you take a look at the second sim, you can see that it is possible to handle objects that do not originate from the agent as collision geo. And you can see that I add the object in the shape library before the crowd sim, so I don't think the issue is coming from here.

It is kind of a bummer to do the 2 sim into different solvers, in my exemple I only have 2 different shapes that have a low chance of colliding but in other setup you could have much more vellum that collide with one another so I would not recommend it workflow wise.

At the end of the way I think that the agent vellum unpack node might just support point attach constraint properly. I will just send a message to support because that is something that should precised in the documentation.

Thx for the help.

For anyone who comes across this issue, turns out this an bug that is now reported.

The full message from the support :

Unfortunately the vellum unpack is not properly correcting the target_pt attribute on the constraint primitives to the value in the merged collision geometry. It does correct target_prim, which is why attaching by closest location works.

Attached shows a correction factor for this file. Unfortunately, the precise update depends on what geometry you have merged together, and which agent if you are unpacking multiple agents. Either you need to encode the target point yourself in an invariant manner to unpack (which will not be simple, about the same complexity as fixing vellumunpack directly…), or use the primitive attach until the bug is fixed. In this case there will be a primitive attach value that matches the behaviour of the point attach.

This bug is now logged in our database as (ID# 106732). I will update you when our developers have fixed this.