constraint bug on packed objs?...

[rich_lord]

... or am I doing something wrong?

 

Creating constraints with regular RBDs always works as expected. However, when I constrian stuff with packed prims through a constraint network, I'm always tearing my hair out wondering why its not doing what I expect it to.

 

Here's two setups - as far as I can tell they are exactly the same. I'm attaching one piece of geo to another with a pin constraint. Then another pin constraint is used to constrain rotation. Its set to only allow rotation to happen around one plane. (condof = 1, condir = {0,0,1})

 

I the attached file is a regular setup using the constraint node, and a packed prim version using the constraint network node.

 

All data is set the same. Condof and Condir are the same on both setups for the rotational pin constraint. However the packed prim version dosen't seem to use the data properly.

 

Its too confusing for me to know if this is a bug or human error. Any insights?

 

 

 

constraint_error.hip

[Skybar]

I haven't worked that much with constraints in a while so I don't really know. But send the file to SESI, they're usually able to help/determine if it's a bug.

[rich_lord]

Thanks Skybar, I've sent it in.

[DennisSchmidt]

That's really interesting. Never noticed that happening with packed prims. Normally i would use a cone twist constraint for this situation. Nevertheless this workflow should work as well. Would You mind posting the reply from SESI? I am curious if it's a bug or a setup problem.
Thanks,
Dennis

[rich_lord]

I will! SESI have the file now and are looking into it. 

 

How would you use a cone twist constraint in this situation? Can you make them act like a hinge? I havent used them too much.

 

Ill play around with them later tonight and see if I can get them to do what I want.

[DennisSchmidt]

I change the Max Up Rotation to 0 and set the Goal Twist Axis and the Goal Up Axis to the perpendicular plane of the wanted rotation axis. Since you want a hinge You could also try the slider constraint. Although i find it a bit unstable. It sometimes starts to slide even if the slide range is at 0.

 

Dennis

[rich_lord]

I got the cone twist constraint to act like I want! Its pretty cool, and seems rock solid.

 

After playing around with it for a bit, I realized I could add some springiness through an extra, world space rotational spring constraint. It gave me exactly the motion I was after.

 

Thanks so much Dennis! I'm going to move forward with this method while I wait to see if SESI think my previous problem is a bug. I'll let you know.

[rich_lord]

Hi, I heard back from SESI. They too suggested the cone twist constraint, and pointed out something I didnt realise about constraints in general. Heres their response if you are interested Dennis. Thanks to SESI for looking at this so quickly.

 

"The two setups are actually not equivalent - the setup with regular RBD objects uses "*" for the Affected Objects and Affector Objects fields, which actually creates two orientation constraints. If you change those parameters to "arm" and "body", respectively, you will get the same behaviour as the constraint network case.

Regardless of the setting, though, it looks like the Bullet solver is interpreting the condof / condir parameters differently than the RBD solver when condof is 1 or 2 (this is easier to see when rotating around a specific axis).

A workaround (and a more flexible option, actually) is to use a cone twist constraint with the up/out/twist rotation limits set appropriately."

[DennisSchmidt]

Thanks Richard for posting the answer. Really interesting and good to know. Earlier i noticed that when displaying the constraint guide that they start to separate and seem to have one guide for each constraint point. Now i know why. To bad it's not directly transferable from the regular RBD. At least the cone twist does the job and is easy to set up. Plus it seems more stable.
Thanks again for sharing the answer.

Dennis