How do I make angles not distort when scaling in my DC?

I’ve been using sketchup for a few years but I just now have started dabbling in dynamic components. This is my first one, I have been able to figure out how to do most of it, but I can’t figure out how to make the angles behave properly when I change the size of the component. I need to keep the 40 degree angle on the Rafter beams when I change the width and height of the frame.

Really what I would like to do is to hire someone to turn my components into dynamic components. I don’t really have time to learn how to do this. Anybody think they can handle that job for me? Dynamic Gable Bent.skp (1.5 MB)

I can’t help you with the dynamic component work, but I think your encountering skewing, when you scale non-uniformly. Consider the ungrouped overlapping faces below (which kind a look like carpenter squares):

In the next image, I use the scale tool on each of the models, doubling the scale factor in the X direction only.

In the right image, you can see that parallel lines remain parallel, but the right angle between the two rectangles has been lost.

The easy solution is to scale the same in all directions.

Thank you for your response Bruce.

Are you saying that if I scale 1.5 in the x direction, that I should also scale 1.5 in the z to maintain the correct angle?

Problem is that I need to be able to scale in just one direction without a distortion of the angle.

You will have to split the Post into 2 parts. The bottom will be a “normal” post (no angles other than 90°). The top will be the wedge-shaped part with constraints. Something like the attached, although I didn’t bother with the formulas.

Post-P1_2.skp (18.4 KB)

Scaling impacts everything in the Scale box proportionately.Simplify the problem to a right triangle for a moment. If you change the length of one leg of the triangle without changing the length of the other, the length of the hypotenuse must change as well as the angles between the legs and the hypotenuse. This is very basic geometry.

Jim beat me to explaining how to make a DC work so I won’t add that.

1 Like

@BarnGeek See:

User Guide: Constraining attributes of a Dynamic Component

User Guide: Hiding the Scale Handles in a Dynamic Component

Thanks! I see how that works, and I like the simple solution! That will work great for the posts.

I do however need the R1 and R2 Rafter beams to change length either longer or shorter depending on how wide the whole component is, but maintain their size on the other axis, and maintain their angle in relation to the Tie beam.

I would rather not just duplicate a short component to make a long one, like I see done on some of the stair step components, since I also need to generate a materials take off list for the models.

Thanks Everyone, I am going to try some of these and see where I can get and report back. I really appreciate all the help!

Therein lies a little problem. If you divide the rafter into three sub-components, a middle section and two ends, you can scale the center and move one end as needed to adjust the length but then, if you use the lowest level components for a materials list, your rafter will be listed as the three parts.

Yeah I see. Looks like it would have to be solved with some sort of formula, which is beyond me… I would pay someone to solve this problem, but I guess I will just have to use my fingers and an old fashioned pen to generate my materials list, or at least remember to edit the rafter portion of the list.

To not have the rafter listed as 3 parts, try this: Create a custom attribute like “tag” and give it any value you want (but do give it a value) for the parent rafter component and whatever other components you want listed in your takeoffs, then include that attribute when you generate your report. The report will only include items that have the “tag” attribute with a value.

Also note that you can hide some of the lines in your sub-components to make the rafter look like one part.

rafter beam.skp (50.9 KB)
if you decide, the DC in this file needs to be saved via right click to a folder of your choice
this DC can be outer-shelled and exploded one nested level down. this process can be easily done via the Outliner.
Why consider this process or workflow? by simplifying a DC to one level it can be easily painted, taken off and greatly reduces file size (after purge) and best for making copies without the unique updating associated with nested DCs
moreover the DC is wrapped so that it can be swapped and retain the existing size. So if you want to amend the component then swap it with the previous (right click) saved component.

I leave the sections visible, so its easier to identify a simplified DC, on outer shell these are absorbed.
An advantage with this system is you can swap the DC with a similar DC where the common attributes will update,

1 Like

pcmoor - I know this is an old post but are you able to provide any more information on component wrapping. Would I drive the level below of the wrapper? As in just a clone of the top level attributes?

I believe this will help me solve a number of issues I am encountering with DC’s.

Yes, you pass the attributes through
The parent generally contain the user input, this next level, a wrapper of the existing sub components does become somewhat a clone of its parent, however you could move some of the initial workings (formulas) to this level.

It depends on the purpose for this insulation, the example given allows the leny, the run of the rafter to be scaled and swapped with say a truss of the same coverage and they will match
The key is that the size attribute needs to be exposed in the parent with use of the current(“leny”…) formula then you can swap the component with a different definition (not just its own) and the child reference that, thus updating to the size in your model. Once the component is installed into the model it may not matter if that current(“leny”) is overridden, so long as the “saveas” definition contains it.

This intermediate wrapper can be used as the point of simplification, I now place named attributes that act as a script for a ruby script to follow at this point, that is the order of operation like explode, outershell, explode and at what level, another to change the status of the parents options access to view only.

Although the DC can be simplified manually, a script can do the job so much quicker. Ruby should be considered in your workflow, just like “lisp” in AutoCad. I suggest you consider Aerillus “toolbar editor” as a way of running the snippets, Ruby code editor by Schreyer as a script writer, attribute inspector by Aerillus for insight into the DCs data base. There are many examples that are helpful, is a good source, a version of his rotate,align scale tool can be used to place components without the need to do all the separate actions to place and scale a DC

Please private message me for specific details

1 Like

Thanks for your detailed response @pcmoor.

I already have use of the ‘toolbar editor’ and attribute inspector. But the latter I haven’t used very much.

There is a clear need for me to look into this more, I need to understand core principles of ruby to be able to implement it into my workflow. I have some learning to do in this regard.

Thank you for offering specific details, I will drop you a dm.