# Parametric SketchUp Dynamic Component – Stable Setup, Common Pitfalls, and Solutions

**URL:** <https://forums.sketchup.com/t/parametric-sketchup-dynamic-component-stable-setup-common-pitfalls-and-solutions/345817>\
**Category:** Dynamic Components\
**Tags:** layout, dynamiccomponents, parametrics, dynamic-attributes\
**Created:** [April 1, 2026, 9:26am UTC](https://forums.sketchup.com/t/parametric-sketchup-dynamic-component-stable-setup-common-pitfalls-and-solutions/345817 "2026-04-01T09:26:49Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![smokey2k](https://sea2.discourse-cdn.com/sketchup/user_avatar/forums.sketchup.com/smokey2k/32/257626_2.png) [@smokey2k](https://forums.sketchup.com/u/smokey2k)\
**Post date:** [April 1, 2026, 9:26am UTC](https://forums.sketchup.com/t/parametric-sketchup-dynamic-component-stable-setup-common-pitfalls-and-solutions/345817/1 "2026-04-01T09:26:49Z")

</div>

**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:

* * *

**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:

1. **The Dynamic Component’s internal parametric size**

2. **An extra transformation scale on the instance itself**

* * *

### 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:

1. Select the Dynamic Component instance

2. Open **Ruby Console**

3. Paste this code and press Enter

```ruby
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:

```auto
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:

```auto
e.transformation.xaxis.length.to_f

```

If that returns:

```auto
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](https://forums.sketchup.com/uploads/short-url/6dxnZcpcdHM8Byb4poIdO6kSbOG.skp) (187.0 KB)

---

<div class="post-metadata">

**Author:** ![ryan.moore](https://sea2.discourse-cdn.com/sketchup/user_avatar/forums.sketchup.com/ryan.moore/32/106089_2.png) [@ryan.moore](https://forums.sketchup.com/u/ryan.moore)\
**Post date:** [April 1, 2026, 12:29pm UTC](https://forums.sketchup.com/t/parametric-sketchup-dynamic-component-stable-setup-common-pitfalls-and-solutions/345817/2 "2026-04-01T12:29:43Z")

</div>

Umm ok,

> [@smokey2k](#):
>
> 1. Never use Scale Tool on complex DCs

My entire workflow is DC, I use the scale tool primarily to configure them and have no problems. My whole workflow is scale tool. So this is not true.

> [@smokey2k](#):
>
> 1. Never rely on LenX/Y/Z in nested components

Not sure where you are getting this. DC logic can be complex, if you have math that does not fully resolve it’s a formula problem, not a DC extension problem.

> [@smokey2k](#):
>
> SafeLenX = IF(Width \< MinLenX, MinLenX, Width)

Maybe Floor or Ceiling, or Smallest or Largest functions?

> [@smokey2k](#):
>
> 1. Avoid zero dimensions

Yes.

> [@smokey2k](#):
>
> **5. Nested Dynamic Components are fragile**
> 
> reduce dependency on built-in attributes

No more than the parent DCs… you may be experiencing Unique problems.

> [@smokey2k](#):
>
> you need to build your own stable abstraction layer (like W/T/H)

Again not my experience. Seems convoluted to add the extra attributes IMO.

> [@smokey2k](#):
>
> If a Dynamic Component behaves strangely even though:
> 
> - the formulas are correct
> - the user attributes are correct
> - redraw works
> - the logic seems right

Then chances are that one on these is wrong.

> [@smokey2k](#):
>
> Normalizing the transform

What exactly are you doing to normalize the transform? Passing the attributes through a custom attribute? I fail to see how this achieves anything?

I appreciate the post trying to help others, some of the info seems incorrect and misleading though. I wonder what @pcmoor has to say? I played with your DC for a bit, you have some positioning and thickness issues, and some circular logic somewhere. I removed the “safe Len" and allowed it to scale. The jumping behaviour when it scales is because the math does not fully resolve, so every redraw it recalculates to a different size. This is totally fixable without all the extra layering of attributes, and it should work fine with the scale handles when all fixed up. I have some other stuff to do right now but I may mess with this a bit more later if I have time.

[Template\_Front\_Fluted - MOD.skp](https://forums.sketchup.com/uploads/short-url/jToQwQ9T2ewlo2HWDvDt4870xiV.skp) (235.1 KB)

---

<div class="post-metadata">

**Author:** ![smokey2k](https://sea2.discourse-cdn.com/sketchup/user_avatar/forums.sketchup.com/smokey2k/32/257626_2.png) [@smokey2k](https://forums.sketchup.com/u/smokey2k)\
**Post date:** [April 1, 2026, 5:07pm UTC](https://forums.sketchup.com/t/parametric-sketchup-dynamic-component-stable-setup-common-pitfalls-and-solutions/345817/3 "2026-04-01T17:07:10Z")

</div>

Dear ryan.moore, thank you for your answer, it seems you are right about many things and I made statements that may be misleading, on the other hand I discovered that my example component is full of errors, I have since fixed it but in the meantime I realized that the design is bad.  
I don’t even know what to do with this post because it might have to be deleted. Or rather, as soon as I have time I will edit it in a way that indicates what I thought wrong. For example, I used custom variables instead of LenX/Y/Z, as I realized it was unnecessary, in fact, from the point of view of redrawing it is better to work with the original built-in attributes. The scaling also seems to come from user error, I did it wrong. As soon as I have time I will correct the post. Thanks again for your answer!