Dynamic Components -Wish List


I know that there is already a general wish list for SketchUp so hopefully this is not considered redundant. -DC’s are a broad subject unto themselves.

Be able to organize Options Menu independent of variable names.
Also add check or radio type buttons.
Also to be able to access the entire DC tree structure without having to use the outliner.
Also be able to pull components from the library as needed instead of having to store all possible variations within the DC itself.
Fix the Options menu blanking problem.
Move the Options Menu Up to the first menu when Right clicking a component
Make the Options and attribute menus collapse-able
Make the component menu scroll-able with the mouse wheel

I lack knowledge but I think that it would be handy to be able to access the ruby console from the DC. I have not played with Ruby much but it seems like it would open DC’s to do just about anything.

More interaction with user input would be good -sometimes it would be easier for the user to select a point for example.

Behaviour when scaling DC different with mouse, or using Measurements

I do not see why textures should scale with the component.

It seems to me that when a component is swapped it should retain it’s name.

The component name should match the name in the component attribute tree

When saving a component the file name should not be changed from the user inputted save as name to the component description

The starting axis and glue to function needs improvement.

A component probably should automatically redraw when swapped or at least include a redraw function.


The documentation says that a group is just a collection of objects and each is unique but when you copy a group and then edit the attributes in a DC all copies of that group change. Whereas a copy of a component would be unique.

It seems to me that there is a lot of confusion between group/component and names and there needs to be consistency.

What is the purpose of linking a copy of a group that is part of a DC?
What is the purpose of allowing both components and groups to act as DC’s?
Why can’t I change the name of a component or group and make it unique?


I would like this also.


Thanks for Starting this thread Chris! Please keep the wish list items coming. I know DCs have not had any updates in a long time but we are listening. :smiley:

~Bryce Stout
Product Manager


[quote=“Bryceosaurus, post:5, topic:12075”]
… Please keep the wish list items coming. I know DCs have not had any updates in a long time but we are listening.[/quote]

Here’s another one, Bryce:

Make GOTOSCENE("…") respect the scene settings, unlike how it is now.
This will allow making better/great interactive models.


I would like the ability to either grey out, or make attribute input boxes invisible in the option dialog depending on the result of a drop down. So for say a scaling option the input for sizes, being redundant are either greyed and not editable or invisible


I have been playing with DC’s a lot over the past couple of months as a way to learn SU and just for fun.

What I have found is that DC’s tend to be slower than just drawing geometry and or using non-dynamic components in many cases.

For example in my Door DC
They will not insert facing the camera so often need to be rotated first.
Will not cut a grouped wall unless actually inserted into the group
The gluing and cutting plane being tied to the axis makes it difficult to work with RotXYZ
Creating options often requires a lot of hidden geometry
You can not create a custom right click options menu
You can not set global variables

Ideally you would want to place a door by selecting the wall and using the mouse to identify it’s width and swing but it is not possible to make DC’s interact with mouse clicks. It would also be much more efficient to store door and door trim styles in a library and insert them as needed rather than having to have all possible combinations hidden in the DC itself.

I realize that Ruby is the way to do this but that is not a very simple solution and I would have to guess that it would take a year or more to learn Ruby enough to create an interactive Door Tool.

The nice thing about DC’s is that they are like a pre-made Ruby script where the basics are already set up.

I may be very naive about how it is being done but it seems to me that if I could work with the actual points that define an object I would not need hidden geometry.

For example I made a component which can have an angle on each end (like a piece of molding) -Because I can not move the points independently I have to use up to eight hidden ends -or one end with fairly complex logic to manipulate copies. Having an angle on each end creates 12 faces and 48 points +all the hidden geometry. Where as it could be defined by 6 faces and 8-24 points (depending on how a face is defined)

Also the Highest level LenXYZ values often do not match the actual size of the component when sub components change.


RotXYZ does not seem to accept decimals -it seem to round them down which is not helpful.


My two cents:

The DC units system still has a bug where if you turn off “Display units format” in Model Info/Units, all the units dispalyed in the Component Options dialog switch to inches.

Several instances of the same component placed inside a DC should be able to be controlled individually. now they all have to be made unique which creates a proliferation of component definitions. Also, when a component is placed inside a DC and outside of it, the component outside is not isolated from the nested one.


OSX Feet and Inches Input in Plugin Webdialogs somehow broken?

It is interesting that DC’s use some sort of special code and not the standard Ruby API

Was that done just to simplify them or is it something intrinsic about their nature?

What is the difference between a cube created thru ruby commands and one created by drawing it?

I found this little bit of code which creates a box:

depth = results[1]
width = results.first
height = results[2]
angle = results.last
point1 = Geom::Point3d.new(0, 0, 0)
point2 = Geom::Point3d.new(0, angle, height)
pts = []
pts[0] = [0, 0, 0]
pts[1] = [width, 0, 0]
pts[2] = [width, depth, 0]
pts[3] = [0, depth, 0]
face = entities.add_face(pts)
line = entities.add_line(point1, point2)
status = face.followme(line)

It seems to me that if this sort of code could be inserted as an object it would make DC’s much more powerful.

I can see the advantage of simplifying Ruby though -the syntax and structure is hard to grasp. But then again it also took me a good month before I had a fair basic handle on DC’s so there is always some learning curve.


I don’t know because the DC source code is scrambled, but I believe DC’s are implemented in Ruby with some JavaScript for the WebDialogs. DC’s are just another Ruby extension for SketchUp. There really isn’t anything special about the code, or special about the Components. Given enough motivation, a person could create an extension very similar to DC’s.

Adding parametric objects which carry their own code to draw themselves in SketchUp is an interesting idea. It is entirely possible. In fact, there is a Parametric class that’s been around for a long time which has some of this functionality. It’s in a plugin file named parametric.rb. Parametric adds user- editable parameters to Groups and Components, and then redraws them using the user-supplied Ruby code. You can see it in action if you use the SketchUp Shapes extension.


Interesting bit of information jim_foltz
Yeah, I thought that DC’s where made that way. I will look up that parametric.rb

DC’s seem to have several functions that I can not find a use for. There is a function to count faces on an object but objects can not be made on the fly so the number of faces is never in question. Same with edges. A function for exponential but not exponent. A function that produces a random decimal number between 0-1, etc…

As near as I can tell a DC is just a pre-made container. and RotZ does not operate substantially different than transformation = Geom::Transformation.rotation point, vector, angle
-just the point and vector is fixed from the objects axis instead of being variables.


I could not determine exactly what parametric.rb did other than draw shapes. It seems like at one time the intention may have been to create an easier way to make an object parametric.

I noticed that Fusion360 seems to have solved parametrics much better.

It looks to me like they may be establishing planes within a component to regulate scaling. Freedo has a scaling tool that works like that.

Holes seem to be able to move or be added and still cut the object they are attached to.


Currently in order to make a parametric stair stringer for example the stringer would have to be defined as a collection of squares and right triangles with a lot of extra faces and hidden lines rather than being composed of an array of points which can be defined in a formula.

Here is an example of what I mean " would have to be defined as a collection of squares and right triangles with a lot of extra faces and hidden lines"

DCStick.skp (37.1 KB)


This video shows how a stringer made using the parametric.rb extension works. You would select a menu to draw the stringer, then use a right-click menu to bring up the edit dialog. All instances are modified.

But there would need to be some more Ruby code to make this redraw itself if it were part of a DC. So instead of getting its parameters from a dialog, it would get them from a DC attribute. The trick is to trigger the redraw whenever the DC is redrawn.

Parametric Stringer code.


Yeah I had found that stringer code but it would not execute. Even though I had the shapes plugin which I thought loaded the parametric.rb file -and the parametric.rb would not load on it’s own.

Anyway it serves as a good example of how to do a more complex parametric shape that involves angles and an unknown number of faces.


Looks good Chris
I see you are coming along nicely.