Can you reflect a sub-component in a dynamic component?

Can you reflect a sub-component in a dynamic component? This would be nice when I have a right and left component and the right is simply the left reflected. That way, when I change the left, the right is automatically changed.
If I can’t reflect a component, then I have to have 2 components and edit each of them separately.
Or, if you have a reflected component placed in a dynamic component how can you work with it? I did this but odd things happened to it when I changed the attributes.

components will still copy each other even if scaled or reflected. So yes, this can be helpful for any mirrored object that you are making.
For dynamic attributes, just note that the axes are flipped, so if you want one to move in a certain direction, be aware that the mirrored one will move in the opposite direction.

There seem to be problems with reflected components.
TestShutter2.skp (59.1 KB)
Here is an example.
This is was started to be 2 shutters, the right being a reflection of the left.
Interact was set to rotate the shutter.
The left shutter rotates fine.
The right shutter rotates in an odd manner and when the rotation cycle is complete the right shutter is no longer reflected.

Is there a way to deal with this?


Look at the Rotation attributes, because of the reflection, the right shutter is now -180.
You would need to figure out a formula that works for both cases.
You can make a new attribute with an IF statement so that when your model is reflected, it’ll know

Reverse: IF(ROTZ=-180,-45,45)

And then: ONCLICK(ROTZ, ROTZ+Reverse, etc)

So that it does the opposite when flipped. I’m not sure if this will work properly, but it’ll put you in the right direction I think.

Changing rotation angles for the reflected component doesn’t help. After the interact the axes have been changed. The component is no longer reflected. It is now with the same axes and same orientation as the unrotated component. Rotating in 180 degrees doesn’t change anything because it is a left-right handed difference, so no rotation gets you to the reflected component.

Here is an example TestShutter2b.skp (84.7 KB)

I also noticed that if you have a dynamic component, say a door the opens with the interact tool, if you reflect it, the interact tool no longer works.
As a result, you can’t take a dynamic door component that is set for an left hand in swing door and get a right hand in swing door by reflecting it (i.e. one that still works with the interact). And no rotation will give you that. So if you want a dynamic door component that works for all conditions, you can’t get it, you have to make 2 components.



Rather than reflect the door, copy and then right click to flip it along the X-axis. Flipping saves a lot of redundant hidden left or right doors in DCs, you can make the flip door unique or leave … if you want to open both simultaneous

I tried it. If you copy and flip a dynamic component you get a reflected component and the interact works as expected.
However, if you copy a component inside the dynamic component (as I want to do with the left and right shutters) and flip it, the same problem occurs with interact: it opens in a funny way and the right hand shutter is converted to a left hand shutter.
See this example TestShutter2c.skp (85.3 KB)

I purged the drawing after deleting the second door, plus renamed so as remove any reference to a copy and that seems to work

I believe one has to be careful when reusing DCs, as sub-components can update, and residue definitions influence the outcome. So either start fresh or purge after each deletion. This is why I use groups for sub parts as there is no worries about uniqueness and no definitions remain in the drawing after deletion

Edit: Realized that the doors are no longer a single unit, had to enclose them in “shell” to preserve their “world”

TestShutter.skp (34.3 KB)

Which actually solves the problem you are experiencing, having said that the previous advice still stands as good practice

1 Like

Thank you.
I’m having some very puzzling results looking at your file…
The variables (attributes or options) don’t show up for the main component.
I started to try to add them back but discovered that they are there for each of the subcomponents you named “Shell”
After a moment or two of clicking, just to open and close, not making any changes, they suddenly changed to “Shell” and “Shell#1”. At that point they are 2 separate components.
I wasn’t able to get the variables (options) accessible from the top level of the component.
I then did an extremely simple test starting from scratch, with no variables. See this exampleTestShutter4.skp (53.6 KB)
It is just 2 rectangles with a line at one side to distinguish left and right.
The same problem occurs when I use the interact tool: the right shutter loses it’s reflected position and becomes an unreflected copy.

TestShutter4.skp (15.0 KB)

I deleted right door, left with component#1 inside component#2, which is the same structure as shutter within the shell, component#2 being the environment (“world”) in which component#1 exists.

I copied and flipped component#2 then selected both and made component#3

you can pass attributes from 3 to 2 to 1 as required.

I’m using SketchUp 8 Pro so I couldn’t open your file.
Are you able to save it in SketchUp 8 format?

TestShutter4.skp (18.6 KB)

no worries…noticed before but forgot to saveas…always saves to current version

1 Like

Very nice. Works beautifully.
I haven’t fully understood what you did to make it work.
However, I had fun playing with it because is could do exactly what I was wanting: i.e. make changes to component#1 on the left and see it immediately reflected on the right.
Before I saw this I had gone ahead and made a dynamic component to do this using just groups, so I had to do a completely separate bunch of work for the right side and left.

Thanks for your help @pcmoor,
I had the same question and this helped me find one solution for the RH/LH door problem.

Here is my first solution -I do not know if it is the most efficient way to do it but it seems to work so far.

The door is from the very nice TruStile collection.

3.8 Mb

Hi Chris, I must admit I am not a fan of the hidden detail types of DCs, they tend to be heavy on resources and problematic when doing takeoffs. Rather I would promote the swapping abilities of DCs or the use of outershelling and exploding to absorb the alternatives. (My warehouse page needs to be updated to reflect these views, which I hope to do do soon)
In regards to changing the swing, I would flip the Door along the red axis.
Can I suggest you use a basic plain door as your starting component and add the required actions and other details like the door path arc, jambs…then flip as required.
The door can be swapped, individually at the moment. However I hope in the new release we will be able to swap all and have more control otherwise I hope to build a ruby with help from this community to suit.

1 Like

Thanks for pointing me in the right direction.

The door itself is about 3.45mb

I am brand new to SketchUp and am thinking that currently creating a DC door that is truly smart enough to know how to be a door must be impractical. Otherwise we would probably find one already made in 3DWH. So this exercise is really just me playing around learning what can be done with DC’s

Unless I do not understand fully:
Swapping requires each door to come in a right and left version
Flipping the door along the red axis is not a function in DC so the door would not know whether it was RH or LH

DC’s seem to lack any any drawing abilities (except copy) so that components which have optional materials and parametric components requires a lot of hidden geometry. I see the inefficiency of creating a complex DC -if I fully explode that door getting ride of all hidden geometry it goes down to just over 1mb. (which is still probably heavy) It seems that DC’s are better restricted to simple objects. Even creating a parametric door trim component would seem to be impractical.

I am thinking that this level of intelligence actually requires ruby script.
I am a little surprised to not find a good door generator already made.
Unfortunately I have very little programming knowledge.

Whoever made ProfileBuilder2 truly understands the power of a good Follow Me tool and parametric component.

It seems to me that the most efficient method of handling doors without very complex programming will be create to a library of standard doors.

Thanks for your help.

One other thought just occurred to me.

It might be practical to use a complex DC as a component generator.

And then use a plugin to delete hidden geometry or explode the output and create a new component or group which seems to effectively get rid of all hidden geometry and dynamics.

I can’t actually explode that door all the way because it crashes SU.

Anyway doing a search I see this has been discussed for a long time.

When mirroring a door in this way it works alright at first, but if you need to add an X Y Z position attribute for either of the doors (to make them closer or farther from each other for instance…) it makes one of them unique… and if there is a door nob, handle, hinge etc… inside, you then have to code everything twice… or maybe I’m missing something?

voici un model de composant dynamique

test volet dynamique.skp (25.7 KB)