DC - How to make an object rotate, while making sure it doesn't rotate

[scottalanclymer]

Am trying to animate a snow plow. Two things going on, in the simplest terms: Blade swings left/right and blade lifts up/down. For the swing, it’s coded and working nicely. For the vertical articulation, I have the arms and the cylinder all working as desired, but the last component to get programmed (“FrontBulkheadAssembly”) needs to move up/down in an arc about the X axis, while maintaining a fixed attitude in that axis. The conundrum seems to be making this item rotate, while making sure it doesn’t rotate. Can this be done in dynamic components?

File attached.
Cylinder cases may be temporarily transparent so plunger can be seen easily.
One of those cylinders needs to be retweaked, I know, I’m on it.
Otherwise, use the interact tool to see what I mean. Two different areas to click on. Tooltips will appear with descriptions.

Any suggestions about how to make this work with SUDC?

SNOWPLOW EXPERIMENT w DC.skp (3.2 MB)

[tweenulzeven]

Just to be clear, I guess by rotating without rotating you mean moving along an arc?

[MikeWayzovski]

from left to right, all parts should be nested correctly, so if you nest the FrontBulkHeadAssembly in the SwingMassAndCilinder and then that into the SnowPly, you could add two ANIMATE actions to deal with the green/blue movements.

Pick the pin, for instance:

second position:

and third:

Now you know how much you need to offset the SwingMassAndCilinder. (Y and Z positions)
It would not rotate, because it is suppose to. The movement might not follow a true arc or anything, but with both ANIMATE(s) set right, that might not be noticable…

[scottalanclymer]

Mike,

Well, a true arc is what I’m after, for the front bulkhead and everything that rides with it, the swingmass included. Actually I feel the opposite for the nesting. As the artbox arms, the aft bulkhead, the diagonal brace etc are attached to the vehicle, they don’t move. The upper and lower ArtBoxArms rotate up and down about the aft pins, and everything pinned at the forward end of those arms (frontbulkhead, then swingmass (potentially) nested within it) moves up and down on the arc that those holes follow. The following idea, I feel, MIGHT make that arc just happen naturally, if I could figure out how to execute it: I’ve tried nesting a set of pins (in the lower holes or the upper, it wouldn’t matter), then nesting the swingmass in the pins. Then, as the artbox arms rotate up/down, the nested forward pins and in turn the nested frontbulkhead and then the swingmass would all rotate in that arc, to which I was going to counter the rotation with equal and opposite RotX values, applied where appropriate. But when I nested the swingmass into a pin, it all inflated to about 5 times the size it should be and distorted to some crazy geometry that made me thankful there’s an UNDO button. If I could somehow lock the scale of all that, would it prevent that from happening? I’m just into dynamic components recently and am surprised that in just a short time I’ve been able to do what you see in the model. The lock scale feature however is something I’ve only read about others doing, not having need for it myself. So I wasn’t paying much attention to it. Apparently I should look into it further. Would that even work?

[scottalanclymer]

After nesting the pin group into the artbox arms (at the forward holes), then the front bulkhead into the pin group, then the swingmass into the front bulkhead, I lose independent clickability of the 2 separate functions. So that is not what I’m looking for. I’ll back out of that idea. Good thing I have a backup copy.

[MikeWayzovski]

@scottalanclymer

I lose independent clickability of the 2 separate functions.

No, that would not be the case. I was suggesting an easier way to get to the three states (positions) instead of revitalize my knowledge of trigonometry

[scottalanclymer]

It was the case. I just tried what I described and the experiment, due to nesting, completely hid the bladeswing onclick visibility because it was nested under other things. Even the bladelift feature was buried. And then there was the wild scaling / distortion behavior. It was an idea. It sucked. So I moved on to the next.

For your idea in your original reply, I did not follow your logic in nesting the front bulkhead in the swingmass. If nesting would have it’s equivalent concept in the real world, the opposite order would be proper, in that the swingmass would be a child of the front bulkhead, as the front bulkhead’s up/down movement (the arc) will carry everything attached to it (SWINGMASS (swingplate, blademount, blade)) in the up/down arc that I’m in pursuit of, which represents the actual product. At least that’s the way I think, as an engineer. Trying to grasp what you were saying, my brain short circuits, as I don’t get the logic. But that’s just me getting old probably.

As for the trig. I don’t want to revitalize mine either. The values it took to program these moving parts so far, I gathered from making 2D sideviews, grouping into “parts”, placing the grouped “parts” on a flat surface, moving them through their ranges of motion, and taking measurements throughout the process. Used a spreadsheet as a notepad. Then somehow, through a great deal of mental struggle, was able to translate the values into formulas and animate/onclick statements. Understanding what Sketchup needed from me as the programmer was the vast majority of the struggle. Relationships of the various nested objects and how all that shows through in the attributes window, and how I was supposed to perceive all those relationships. Hard to describe, but it’s getting slightly less muddy as I work through the issues. To my head it was like a trip to the gym for my body. A lot of reluctance and resistance to doing it, but muttled through it. The desire to make these parts animate, however slightly, exceeded the desire to say screw all this technical math and stuff. Just one little challenge left. Have an idea or two remaining. If you could expound on or help me understand what you meant with your original idea, feel free. I don’t mean to dismiss it, I just don’t get the approach you offered.

[scottalanclymer]

Here’s a quote from Referencing Dynamic Component Attributes, Functions, HTML Tags, and Operators | SketchUp Help

“To develop your dynamic component interactions, use the following references to the predefined attributes, functions, and operators. These are the building blocks for any dynamic component behavior that you can imagine.”

I take that at it’s word. I believe that. And I have some ideas about how to make this object follow it’s arc while simultaneously offsetting the rotation at a different level. But this interface… ughhh.

I think that a better understanding of the DC programming interface REMAINS my primary struggle. IMO, it’s just not intuitive, at all. I select an object in the model, expecting to see a certain thing in the attributes window, and something ELSE shows up. I know it’s an issue with heirarchy. I don’t know how old you are, but I’m in my late 50’s, and somewhere along the line my brain decided that it knows what it needs to know. New information and concepts - I’m having a hard time processing. The Old Dog vs New Tricks phenomenon. Any ideas how to help me get a better grasp on this interface?

[MikeWayzovski]

The interface hasn’t changed since it’s implementation,
so best to start here:

Dynamic Components Resources [wiki]

Dynamic Components Resources These lists are wikis. They can be appended or repaired by anyone with wiki privileges. Directory of Resource Lists User Guide: Sectional Outline Keyword Index [image] Training Components Tutorials Books News & Blogs Tips & Tricks USERGUIDE | INDEX | BOOKS | [image] COMPONENTS | NEWS | TIPS | …

The nesting is best controlled in the outliner panel, but SketchUp doesn’t have a ‘Assembly’ concept like in other CAD software.

I might delve into it later.

[pcmoor]

to rotate an object around a point, could use Polar coordinates

polar cordinates.skp (19.4 KB)

I agree with Jack, nesting each part, finger to hand, hand to wrist, wrist to lower arm… makes the animation easier, sure onclicks need to be all on the same level, but at the first nesting, consider a control panel of arrows, up/down, left/right with small steps to clickon and pass the values.

[scottalanclymer]

Ya, I’ve been a big fan of and user of the outliner since I discovered it early on. It not only presents an outline but makes several other tasks downright easy. Like SELECTING when you have buku instances of something, or moving things to different contexts, or searching for stuff you lost, and lots of other stuff. That’s why I always name things as I create them.

Mike I think I had a victory. It wasn’t easy, but I got these arms articulating the way they would in real life. I definitely had to work for it. You’re one of only two who engaged the topic, as I had reached out in several places / forums. So I thank you for the help. I’m still cleaning it up a little. I brought the pins down and stuck them in their holes and all the geometry in the plow went wacko. So, am just taking care of that minor detail (and now several other things). Whenever I can get the updated model posted, I still wouldn’t mind hearing what you think about the programming that I came up with. At this point it’s going to be into tomorrow though. Thanks again.

[scottalanclymer]

Haven’t looked at Polar Coordinates yet. Would that be something like plotting waypoints then having the object move through those waypoints rapidly - to resemble an animation? Well I’ll take a look a it.

Not familiar with Jack or what he said.

But the nesting order you describe is the only way that makes sense. Whether it’s a human arm, an excavator, or a snowplow attachment. Mike Wayzovski suggested the opposite, which I couldn’t make sense of. The blade (SwingMass) is the last thing in the collection of parts that has to move. It’s relationship with the front bulkhead is downstream of it.

I have onClicks at different levels. There’s one at LiftArtBoxAndCylinder, and the other is at SwingMassAndCylinder which is 2 levels deeper and in a different branch. See why I’m so confused?

What I ended up doing is grouping SwingMass and FrontBulkhead. Of THAT group I made the axes origin at the ArtBox arms aft pin, while leaving those two (now children) origined at the front pin. I rotated the GROUP at the aft pin while giving the children the opposite rotation values about the front pin. Made for a lengthy onClick statement, but it did work. Passing the values through the ether across the nesting levels was an Alice in Wonderland journey. I just had to figure it out.

At some point shortly thereafter I moved SwingMass to be a child of FrontBulkhead, and the values transfered with it. At least I think that’s what happened. I tried so many different ways to do this today, I’m actually not clear what happened there at the end. It’s still hard to wrap my head around. That’s why I need to stay engaged with these dynamic components and work through more projects.

As I told Mike, I struggle with the “interface”, but it’s slowly getting easier with more exposure. Relationships and all that. What just shows a value and in other cases what references that value. Just need practice. Though I AM warming up to the concept of passing values upstream / downstream via what I’m calling proxies or relays. And since that procedure is apparently what’s necessary with a complex model, then it’s a good thing I’m finally getting it.

Not sure why I jumped into the deep end of this pool, but it does have a tendency to make you learn to swim real fast.

Soon as I massage some extraneous geometry out of this model I’ll share it back to this thread. Thanks for chiming in. I’ll check out the Polar Coordinates.

[pcmoor]

@scottalanclymer

Not familiar with Jack or what he said.

[MikeWayzovski]

just to add, the two different movements are allready in a Parent container, I think I did not realise this at first.
A component can ‘see’ three levels, one above, one below and the current level (eg. Parent, sibblings and children)
The 'SwingMass… ’ and ‘Lift…’ components are siblings (and children of ‘SnowPly’)

Now the SwingMass needs to know in what position or state the Lift is, so it can position itself accordingly.
I use the positions of the artbox pin to see what changes in the positions according to the state the liftbox is in:

and create a new attribute for the Lift (state) and add the SET(“state”,…) command for the Onclick attribute:

Now, we can add formula’s voor the positions of the SwingMass

[scottalanclymer]

Just took a look at your polar_coordinates.skp file. So “ANG” is the function I’ve been wishing for all along? I can’t find that in in the functions list or in any supporting DC documentation online. Where did you find this or how do you know about it? (And where have you been for the past week?)

[scottalanclymer]

Just depends on what mood he’s in, what name he goes by? Ok, well I had no way to know that. I see Mike. I know nothing of his background.

[scottalanclymer]

And that makes it move instantly from one position to another position?

[pcmoor]

polar coordinates are based on the unit circle, so from this can derive the sin and cos of the hypotenuse angle at any point on the circumference, these equate to the coordinates.
so there no special function, just maths
the plane is on the XZ
so x = Radius * cos (angle)
and z = Radius * sin (angle)
I used the animate to run through a range of angles.

@scottalanclymer

And where have you been for the past week?

We are volunteers, not paid to do work at the drop of a hat, some like Dave are very dedicated and give the appearance that they are at call.

[scottalanclymer]

That was tongue in cheek. I assumed you were volunteers. No one expects you to be standing by. Your help is appreciated. Where is this ANG function in some documentation?

[MikeWayzovski]

@scottalanclymer

Just depends on what mood he’s in, what name he goes by?

And on which machine I am. Usually on a phone, I had an unfinished answer somewhere on a private laptop that I posted accidentally, I guess.
I kind of like these dynamic puzzles, but I wouldn’t advocate it to our clients (I do work for an official Partner for SketchUp, as you can see in my profile)

Too much hassle😉

The Animate functions to control the positions always has some inaccuracies (see the piston, for instance)
Even the ANG method is restricted by steps.
But might give better results.