Parametric SketchUp Dynamic Component – Stable Setup, Common Pitfalls, and Solutions
Introduction
I’m working on this kind of setup because I create visualizations for furniture manufacturing companies. As part of my work, I often need to model complete furniture pieces or detailed elements such as cabinet fronts. In this particular case, I was building a parametrically driven fluted (ribbed) cabinet door, where the geometry adapts automatically to different sizes and design constraints.
Overview
This Dynamic Component represents a fluted cabinet door that:
1. automatically generates ribs based on width
2. keeps rib width constant
3. adjusts the left and right edge elements dynamically
4. supports minimum size constraints
5. is fully controllable via Component Options
Component Structure
Main component:
Template_Front_Fluted
User parameters:
1. Width → total width
2. Height → total height
3. Thickness → panel thickness
Safe dimension system
To prevent invalid geometry:
SafeLenX = IF(Width < MinLenX, MinLenX, Width)
SafeLenY = IF(Thickness < MinLenY, MinLenY, Thickness)
SafeLenZ = IF(Height < MinLenZ, MinLenZ, Height)
LenX = SafeLenX
LenY = SafeLenY
LenZ = SafeLenZ
Internal layout
The component is built from three main parts:
-
Left (left edge element)
-
Clone (repeating ribs)
-
Right (right edge element)
Rib generation:
RawMaxClones = FLOOR(AvailableWidth / RibsWidth)
MaxClones = IF(AvailableWidth < RibsWidth, 0, RawMaxClones)
Problem #1 – Using the Scale Tool
Why you should NOT use it
The SketchUp Dynamic Component system is not deterministic under scaling.
If the user scales the component:
-
calculations happen in the wrong order
-
the system tries to “fix” geometry afterward
-
results include:
-
duplicated geometry
-
broken rib distribution
-
misaligned parts
-
completely unstable behavior
-
Correct approach
Only use:
Component Options → Width / Height / Thickness
And disable scaling:
ScaleTool = None for every axes
Problem #2 – Using LenX / LenY / LenZ directly
This is the most critical issue.
Bad practice (very common mistake)
Inside subcomponents:
LenX = Parent!LenX
LenY = Parent!LenY
LenZ = Parent!LenZ
Why this breaks
The DC engine:
· does NOT guarantee evaluation order
· especially in nested components
So:
· some elements use updated values
· others use outdated ones
Result: broken geometry
Typical symptoms
· ribs splitting or shifting
· corners floating or misaligned
· geometry breaking only at certain sizes
· “random” errors when resizing
Correct Solution – Use Custom Dimensions (W / T / H)
Instead of relying on LenX/Y/Z, define your own variables.
Example (for Left / Right / Clone)
Custom attributes:
W = width
T = thickness
H = height
Assign from parent:
W = Parent!LeftWidth (or RightWidth / RibsWidth)
T = Parent!SafeLenY
H = Parent!SafeLenZ
Then define size:
LenX = W
LenY = T
LenZ = H
Inside ALL nested elements
Do NOT use:
Parent!LenX
Parent!LenY
Parent!LenZ
Use:
Parent!W
Parent!T
Parent!H
Why this works
Custom attributes:
· are simple values (not “special” DC properties)
· are evaluated more consistently
· do not trigger internal recalculation conflicts
Much more stable in nested setups
Problem #3 – Zero dimensions
Avoid this:
LenY = 0
Why it’s bad
· SketchUp may drop geometry
· bounding box becomes unstable
· rendering artifacts appear
Use instead:
LenY = 0.001
Problem #4 – Axis consistency
If you accidentally swap dimensions:
W ↔ H
everything breaks instantly
Always keep this convention:
X = width (W)
Y = thickness (T)
Z = height (H)
Final Lessons
1. Never use Scale Tool on complex DCs
always use parameters
2. Never rely on LenX/Y/Z in nested components
use W/T/H custom attributes
3. Avoid zero dimensions
use small epsilon values
4. Keep axis logic consistent
5. Nested Dynamic Components are fragile
reduce dependency on built-in attributes
Conclusion
The SketchUp Dynamic Component system is powerful, but:
· it is NOT a true parametric CAD system
· it behaves more like a spreadsheet engine with side effects
For complex use cases like:
· furniture modeling
· cabinet fronts
· panel systems
· ribbed structures
you need to build your own stable abstraction layer (like W/T/H)
Additional Note – Previously Scaled Dynamic Component Instances Can Cause Hidden Problems
One more issue that turned out to be very important in my case: if a Dynamic Component instance was previously scaled with the Scale Tool, it can cause very confusing behavior later, even if the component itself is set up correctly.
This is especially relevant when working with more advanced Dynamic Components such as furniture fronts, repeated rib systems, nested subcomponents, or any setup that relies on formulas and custom user attributes.
What happens when a component was previously scaled?
When you scale a component instance in SketchUp, SketchUp does not rewrite your dynamic attributes in a clean parametric way.
Instead, it applies an instance-level transformation scale on top of the component.
That means you can end up with two separate size systems:
-
The Dynamic Component’s internal parametric size
-
width -
height -
thickness -
LenX / LenY / LenZ
-
-
An extra transformation scale on the instance itself
-
applied after the DC logic
-
often hidden from the user’s point of view
-
Why this causes problems
This can create a mismatch between:
-
what the Dynamic Component thinks its size is
-
and what its actual size is in the model
Typical symptoms:
-
Component Options show the correct values, but the real geometry is larger or smaller
-
setting a width such as 397 mm does not actually result in a 397 mm component
-
clone spacing appears wrong
-
the component behaves inconsistently
-
formulas seem correct, but the visible result is not
In other words, the DC logic may be fine, but the instance is still carrying an old scale transform.
Why this is especially problematic in complex Dynamic Components
In a simple component, this may not be obvious.
But in more advanced setups, such as:
-
furniture doors
-
ribbed/fluted fronts
-
nested dynamic subcomponents
-
repeated elements driven by formulas
…a previously scaled instance can make debugging much harder, because the formulas can still evaluate correctly while the final geometry is being multiplied by an extra transform.
That means the problem is not in the formulas themselves, but in the already-scaled instance.
Why it is worth normalizing the instance transform
A very useful cleanup step is to normalize the instance transform before continuing to work with the component.
This means:
-
keep the component in the same place
-
keep its orientation
-
remove the scale part of the transformation
After that, the instance no longer carries a hidden scale multiplier.
This makes the Dynamic Component behave much more predictably.
Ruby Console snippet – normalize the selected component instance
If anyone wants to test this quickly, the following code can be pasted directly into the Ruby Console in SketchUp.
How to use:
-
Select the Dynamic Component instance
-
Open Ruby Console
-
Paste this code and press Enter
e = Sketchup.active_model.selection.first
if e && e.is_a?(Sketchup::ComponentInstance)
tr = e.transformation
origin = tr.origin
xaxis = tr.xaxis.normalize
yaxis = tr.yaxis.normalize
zaxis = tr.zaxis.normalize
clean_tr = Geom::Transformation.axes(origin, xaxis, yaxis, zaxis)
e.transformation = clean_tr
puts "Transformation normalized."
puts "X scale raw = #{e.transformation.xaxis.length.to_f}"
puts "Y scale raw = #{e.transformation.yaxis.length.to_f}"
puts "Z scale raw = #{e.transformation.zaxis.length.to_f}"
else
puts "Please select a Component Instance first."
end
What this does
This code:
-
reads the selected component instance
-
keeps its current position
-
keeps its current orientation
-
rebuilds the transform with normalized axes
-
removes any scale factor that may have been left behind
So effectively, it resets the instance transform to a clean, unscaled state.
Important note about the scale values shown in Ruby
If you inspect the transformation axes in SketchUp Ruby, you may see values like:
25.4 mm
This does not necessarily mean the component is scaled 25.4 times.
SketchUp internally uses inches, so a normalized axis may display as 25.4 mm, which is simply 1 inch shown in millimeters.
To check whether the transform is really normalized, it is better to use:
e.transformation.xaxis.length.to_f
If that returns:
1.0
then the scale is normalized.
Practical takeaway
If a Dynamic Component behaves strangely even though:
- the formulas are correct
- the user attributes are correct
- redraw works
- the logic seems right
…then it is worth checking whether the instance had been scaled previously.
For script-based workflows, normalizing the transform before writing new dynamic attributes is often a very good idea.
Final conclusion
For complex Dynamic Components, hidden instance scaling can be one of the most misleading sources of errors.
A previously scaled component instance may look fine at first glance, while internally it is no longer in a clean parametric state.
Normalizing the transform can save a lot of debugging time and makes the component system much more reliable.
**
If anyone is working on similar furniture components, this approach can save a LOT of debugging time**.
Hope this helps someone !
Template_Front_Fluted.skp (187.0 KB)