Cone Twist constraint Goal/Constrained

   1418   5   2
User Avatar
Member
24 posts
Joined: Jan. 2018
Offline
Hi I was testing out all the different constraints and ran into a problem with cone twist constraints in the constraint network node.
I know how most of the parameters work however there seems to be no way to assign which packed object should be the constrained object and Goal object. I looked through all the documentation for the constraint network node and couldn't find any attribute where you can assign an goal object or constrained object which I would assume is possible as you are assigning each constraint prim point with a “name” attribute where it can identify the packed object it should be connected to.

It doesnt seem to be an issue if the goal constraint is supported by an constrained object however if the constraint network automatically selects the unconstrained object it becomes loose and basically unconstrained (eg.wheel on a car). Even if I switch the order of the points or reverse the attribute “name” of the anchor point it will auto select the same packed objects to be the goal/constrained object.

The only way I was able to assign the cone constraint properly is making an rbdobject and manually select the objects that are the goal and constrained object using the solo rbdconetwistconstraint node.

So is there a way to create goal and constrained object targets for anchor points where constraint network node can use to auto assign?
User Avatar
Member
24 posts
Joined: Jan. 2018
Offline
Was corrected below

Solved the problem

The assigned goal and constrained anchors are based upon the numerical or alphabetical order of the packed pieces name.

I have tried to just change the order of the packed points and primitives however this did not work. It is solely based on the name attribute.


eg. have 2 packed geo, sphere and box, named “sphere”, “box” respectively:
using the packed node -> packed based on name which will result in a geo spreadsheet

name
pt1 box
pt2 sphere

after creating the constraint primitive you can chuck it into the DOP net constraint network node, with input cone constraint.
This will result in the first object being the constrained object and the second object the Goal object.
(due to alphabetical order)

box = constrained object
sphere = goal object

so to change the anchors all you have to do is change the “name” so it reads the object you want to be constrained first.
eg. alphabetical order

asphere = constrained object
box = goal object

or
e.g numerical order

1box = goal object
0sphere = constrained object

0box = constrained object
1sphere = goal object

or
e.g numerical order with the same object name

box_0 = constrained object
box_1 = goal object

box_1 = goal object
box_0 = constrained object
Edited by MakoPolo - Aug. 13, 2020 22:39:28
User Avatar
Staff
727 posts
Joined: Oct. 2012
Offline
That sounds very wrong, do you have an example file?
The primitive vertex order should control this, except for when there is a static object (which becomes the goal object)
User Avatar
Member
24 posts
Joined: Jan. 2018
Offline
It seems like changing the name of the object also changed the vertex order of the prim created by connect adjacent pieces.

Thank you for the info. Changing the vertex order with the primitive node does indeed change the anchor points.

Cheers

Also on the note of constraints do you know if changing the anchors DoF and direction should lock it on an axis?
For example 2 objects attached with a spring constraint with each packed objects point set with an attribute i@condof = 2, v@condir = {0,1,0}. Is this meant to achieve a spring motion locked on the Y axis? Only rotating about Y axis and moving up and down the Y axis?
When I try to do this the spring seems to fall off the axis when any force is applied.
I have also placed this problem in the file.

Thanks again.

Attachments:
cone_constraint.hiplc (617.3 KB)

User Avatar
Staff
727 posts
Joined: Oct. 2012
Offline
It looks like the condof attribute isn't currently supported for springs, so perhaps submit an RFE for that? You could accomplish the locking using a hard constraint, though

There would be a couple different ways this could be interpreted - one would be that condof specifies the number of axes along which the spring constraint has any effect ( I think this is how the old-style RBD spring constraint worked), versus specifying the number of axes that are locked. It might be more clear to just instead expose rotation / translation limits …
User Avatar
Member
24 posts
Joined: Jan. 2018
Offline
Amazing thanks for the insight.

Was able to achieve what I wanted using the hard constraint mixed with spring constraint.

Also attached the file if anyone else is curious.

Attachments:
spring_condof_condir.hiplc (329.1 KB)

  • Quick Links