Rotate action results in "One or more constrained objects cannot be resolved."

[dmfrazier]

I have what I thought was going to be a fairly simple DB that has turned into a challenge I cannot resolve on my own.

It's a "slot" (elongated hole) that allows the user to dynamically change the diameter and the length.  These properties work "well enough" (sometimes I get quirky results, but I can deal with it; I may add lookups to minimize exposure to the quirks), but when I attempt to add the ability to rotate the slot, I get a hint (a brief preview) of the block rotating, but when I drop the grip it stays where i drop it, but the geometry reverts back to the default rotation and the message "One or more constrained objects cannot be resolved" shows on the command line.  Attempting to enter a rotation in Properties is similarly fruitless.

I'm stumped.  Any help would be greatly appreciated. 

[Anonymous]

Seems like it does not like your constaints. have you tried using parameter sets for the increments instead of the constraints?

[dmfrazier]

"Seems like it does not like your constaints."

Agreed.  But the (obvious) question is why?  I can't see anything in the constraints that would preclude the ability to rotate the whole thing.

"...have you tried using parameter sets for the increments instead of the constraints?"

Yes, I have tried to achieve the same results using stretch actions, etc., and combinations of the two, but the only way I can get the correct behavior is with constraints. (It's possible of course that I may have missed something with those approaches as well.)  It is important that the Length and Diameter properties interact with each other properly, so that changing the length will not affect the diameter, and changing the diameter will not change the length.

Thanks.

[Imui]

Have you tried to devide the 2 arcs in half? So that you have 2 arcs per side.

[dmfrazier]

"Have you tried to devide the 2 arcs in half? So that you have 2 arcs per side."

Thanks for the suggestion, but no, I have not tried that, and I can't see how doing that would improve things.  It seems to me it would just introduce a couple more opportunities for the geometry to go all haywire.  (But I will give it a shot - who knows?)

Since my original post, I made another version in which I removed the vertical constraint named "Width", which was basically redundant anyway.  This block behaves a little better (some of the time), but still tends to go haywire in unpredictable ways after being grip-edited a few times or while changing properties back and forth.

Yesterday, after testing various other minor tweaks, I decided to add back that same constraint and was presented with a message/error saying that it couldn't be done because it would overconstrain the geometry.  (I wonder how I was able to get it in there the first time.  Maybe it has to do with sequence?)  Today, I repeated that process and got no such message/error.  It's hard to figure out what is going on.

[Libbya]

I am quite new to using constraints, but I believe the main issue is that you are attempting to rotate geometry that is constrained with vertical and horizontal constraints.

Attached is your file, I believe, working the way you intend.  It gets weird if you stretch the radius way past the point where the arc ends cross but you can use the other grip to pull the two arcs apart or enter dimensions to fix it as shrinking the radius doesn't seem to.   

[Libbya]

One more thought, instead of having the aligned constraint runing from one arc to the other, I would prefer the behavior of having one point on one arc and the other point at the midpoint.  That way, the stretch follows the cursor movement rather travelling at 1/2 cursor speed.

[dmfrazier]

Thank you for your input and the modified block.

"...attempting to rotate geometry that is constrained with vertical and horizontal constraints."

Yes, I got rid of those in a more recent version of the block, which made it behave better, but it still didn't resolve the rotation issues.

Although your version of the block does behave better in terms of the rotation, I still get some quirky behavior depending on the sequence of Property changes.  For instance, if I try to change the diameter (with the grip or via Properties) after changing the rotation, the diameter grip sometimes moves even though the geometry doesn't change.  This usually also (eventually) results in the "One or more constrained objects cannot be resolved" message.  Sometimes this can be "fixed" by gently nudging the diameter grip or changing the rotation, but it is inconsistent.  The inconsistency makes it difficult to figure out what exactly is going on.

[Libbya]

I agree that it should work and that it is a bit sketchy.  I think the remaining sketchiness comes from the complexity of the interaction of all the constraints.  I found the rotation worked more solidly if the increments were removed.  Even still, it was not 'unbreakable'.  The complexity comes because of trying to maintain the distance between arcs while resizing the radius.  If you want rock solid behavior you could eliminate all of the constraints and use a scale and stretch action but that comes at the cost of the extra step of needing to set the length of the center line first before setting the distance between arcs.  See attached.

[Libbya]

Here it is revised once more.  It seems to me that I got the issues completely resolved and it appears to be unbreakable.  All the actions are completely smooth.  I didn't bother to add increments but that's easy enough if you want them.    

[dmfrazier]

Thanks again for your efforts.

This one does work very nicely.  My only issue with it is that "ideally" the user-modifiable properties (in addition to"Rotation") should be "Length" and "Diameter".  In this version of the block these properties are actually "Half-length" and "Radius", so the user would have to do calculations to get the correct result.

I will play around with it when I have time and see if I can resolve this.  Maybe a lookup table for each of those properties would make sense.

[Libbya]

You can fairly easily make the stretch parameter equal the length or width by moving its startpoint to the other side of the block rather than the center.  That way, the user input equals the overall length, but I don't know of a way to do that and simultaneously stretch the two ends in opposite directions while maintaining the centerpoint without having the grip in never never land.  If anyone does know a way, I'm all ears.  

[ojuris]

hi!

Little bit different variant without constructs

Regards

Juris

[dmfrazier · Accepted solution]

"...but I don't know of a way to do that and simultaneously stretch the two ends in opposite directions..."

That is actually easy to do with the "Length" parameter; I just moved the left grip to the midpoint of the left arc and changed its basepoint to "Midpoint" and it behaves exactly the way I want (without breaking anything else - so far).

Trying to change the "Radius" parameter to "Diameter" using the same strategy was a little trickier because of the multiple parameters with chain actions, but I got that to work as well.

So, it's working now, thanks to a little collaboration (even though I'm not exactly sure why it works - or why it didn't before).

Thanks, again.

[dmfrazier]

Thanks for the input.

Your block works well, except that it is missing the Rotate action, which has been the cause of most of the difficulty.

I understand that adding that as a dynamic property is somewhat redundant (as all block inserts already have a Rotation property anyway, right?), but I thought it would be handy to have the ability to rotate it more directly with a grip control.

[ojuris]

hi!

sorry about rotation - I forgot about it

Juris

[Libbya]

"hi!

Little bit different variant without constructs

Regards

Juris"

That's a very cool way of doing it.  Thanks for the input.

"That is actually easy to do with the "Length" parameter; I just moved the left grip to the midpoint of the left arc and changed its basepoint to "Midpoint" and it behaves exactly the way I want (without breaking anything else - so far)."

That's awesome.  I was not aware of the "midpoint" property and have spent a terrible amount of time trying to do that in various other ways without success.  Thanks.

[dmfrazier]

No problem - we got it covered!

Thanks for your input.

[dmfrazier]

So much to know - so little time!

[Libbya]

Just to throw a wrench in the works, I'd want that length stretch to be polar and eliminate the rotation grip but I don't see 'Base location' in the polar properties.