Dynamic Component Attribute Stability — Master Source Workflow for Reliable SqFt / LnFt Reporting

[edgewoodcustom]

I wanted to share a workflow discovery after a lot of real-world testing with SketchUp Dynamic Components and attribute-driven estimating/takeoff systems.

I’ve been building a fairly advanced material reporting workflow using:

• Dynamic Component attributes

• LenX / LenY formulas

• SqFt and LnFt calculations

• scalable framing/sheathing components

During testing I kept running into inconsistent behavior when:

• copying already-scaled instances

• repeatedly modifying copied components

• daisy-chaining modified copies

• scaling components externally

• mixing Make Unique workflows with scaling workflows

The biggest issue was:
attribute values such as:

LenX/12
(LenX*LenY)/144

would sometimes stop behaving predictably between different component copies/instances.

At first I thought:

• axes were wrong

• formulas were broken

• Make Unique was required every time

But after much more testing, I think I finally narrowed down a stable workflow.

---

MY CURRENT WORKFLOW

I now maintain untouched MASTER SOURCE components and ONLY pull fresh working instances from those masters.

Examples:

MASTER_7-16_OSB_DO_NOT_MODIFY
MASTER_3-4_TG_ROOF_DECK_DO_NOT_MODIFY
MASTER_2X8_RAFTER_DO_NOT_MODIFY
MASTER_F5_DRIP_EDGE_DO_NOT_MODIFY

I keep them on a dedicated tag/layer:

00_MASTER_COMPONENTS

Workflow:

MASTER SOURCE
→ copy fresh instance from MASTER
→ scale/edit working instance
→ only Make Unique if geometry fundamentally changes

Examples where I WOULD Make Unique:

• birdsmouth cuts

• special joinery

• holes

• geometry changes

• custom profiles

Examples where I DO NOT Make Unique:

• simple length changes

• standard scaled framing members

• standard sheathing panels

---

MOST IMPORTANT DISCOVERY

The biggest thing I found is:

DO NOT continue copying already-modified or already-scaled instances if you want stable attribute reporting.

It appears SketchUp/Dynamic Components internally track:

• component definitions

• instance transforms

• redraw/cache behavior

• possibly definition precedence/order

in ways that can eventually cause inconsistent attribute behavior when daisy-chaining modified copies.

Once I switched to:

• untouched masters

• fresh copied instances only

• disciplined scaling workflow

my SqFt / LnFt reporting became MUCH more stable and repeatable.

---

ANOTHER IMPORTANT OBSERVATION

It also appears there may be some relationship between:

• original component definition state

• first inserted definition behavior

• instance scaling transforms

• redraw/update order

I found forum discussions mentioning:
“the first placed definition will have precedence”

which seems VERY related to what I was seeing during testing.

---

QUESTIONS FOR ADVANCED USERS / DEVELOPERS

1. How exactly are LenX / LenY formulas evaluated internally?

   • definition dimensions?

   • transformed instance dimensions?

   • cached redraw states?

2. Is there known Dynamic Component behavior related to:

   • first inserted definitions

   • instance precedence

   • redraw propagation

   • scaling inheritance?

3. Is maintaining untouched MASTER SOURCE components considered best practice for stable DC reporting workflows?

4. Has anyone else experienced:

   • inconsistent LenX/LenY reporting

   • unstable SqFt/LnFt formulas

   • scaling propagation issues

   • copied-instance corruption behavior?

5. Is there any reliable way to identify the original source instance of a component definition after the model has evolved?

---

FINAL TAKEAWAY

For anyone building attribute-driven estimating workflows in SketchUp:

Keep untouched MASTER components.
Always pull fresh instances from the MASTER.
Avoid daisy-chaining modified copies.
Only Make Unique when geometry truly diverges.

This has dramatically improved stability and predictability in my reporting workflow.

I’d really appreciate hearing from advanced Dynamic Component users, Ruby developers, or anyone building similar estimating/takeoff systems.

Thanks

Richard P.

[edgewoodcustom]

One additional issue I discovered while testing this workflow:

Dynamic Component formulas like:

(LenX*LenY)/144

appear to calculate the bounding rectangle dimensions of the component, NOT the actual visible/cut face area.

Example:
A sheet of OSB with a large window cutout may still report as:

32 SqFt

because the formula is evaluating the full rectangular extents of the component rather than the true remaining face geometry.

This becomes important for:

• wall sheathing

• roof sheathing

• membranes

• drywall

• siding

• irregular cut panels

Right now it seems there are two separate concepts:

Gross_SqFt = stock/bounding sheet area
Net_SqFt = actual remaining geometry after cuts

It would be extremely useful if SketchUp or a Ruby extension could:

• evaluate actual face area

• subtract openings/cutouts

• automatically write true Net_SqFt into a component attribute

I’m curious:

• how are advanced users currently handling net material area?

• are there existing Ruby tools/extensions for this?

• is there a known best practice for true cut-piece quantity takeoffs inside SketchUp?

Thanks

Richard P.

[ryan.moore]

Hey. DCs can be buggy, but there are best practices and work arounds. I would be interested in seeing some of the DCs that had problem behaviour, or a recreation of the problem. My workflow is all DC and I copy and scale instances all the time and still get accurate reporting. Most often I copy and scale these lumber DCs, making unique as I change use case, ie joist, blocking or ledger.

DC lumber.skp (572.3 KB)

The Scale Definition attribute in the 2x PT is a custom one I added as a personal extension, originally I used a material scaler as in the 2x Framing. The Scaler will make each instance unique when scaled, also any direct editing of geometry in a complex DC (has 1 or more children) will break the LenXYZ attributes. Resetting the Nominal LenXYZ attributes can correct that:

Len X is incorrect on redraw

Whilst inside, I think you altered the length (lenx) so it became out of sync, used tape inside the DC measured and entered correct length then allowed resize, so should be okay now 2x lumber.skp (457.2 KB)

Here is a helpful list of DC Gotcha’s:

Dynamic Components - Gotcha List

Been spending the last week or two refreshing myself with Dynamic Components and minefield of gotcha’s that can frustrate the process. So I decided to begin summarising all the scattered advice and experience I have found throughout the forum contributions from people here much more knowledgeable on the subject… (shoutout to Dan Rathbun and PCMOOR… among many others) It seemed a wasted effort to have this only on my PC so I have created a Google Sheets online list for any forum members to acc…

And here is a DC reuse post:

Dynamic components - creating dc variations workflow?

What is the best practice for creating a DC from and existing DC? (in particular METRIC DC’s) Background - I am creating multiple DC variations of a door. They will have similar variables (attributes) and formulas but also have different elements and materials. I want to minimise the amount of scripting by reusing DC script structures that are common to all But I am aware of the many comments on the forum about the buggy handling of attributes and units in DC’s and the risk of hidden data a…

For the best answers on best practice workflow questions search @pcmoor Philip’s posts, he is the GOAT on DC how to. Not sure if any of this helps but without specific DC cases to look at it’s really hard to nail down what is happening with your DCs.

[edgewoodcustom]

This is extremely helpful and honestly validates a lot of what I’ve been observing through testing.

I think part of my issue may have been that I was unintentionally daisy-chaining already-modified/scaled copies instead of maintaining cleaner source definitions and use-case groupings.

What you said about:

• joist
• blocking
• ledger

being made unique per use case is especially interesting because I think I may have been over-separating by length instead of by functional geometry category.

The biggest thing I noticed was:
copying directly from a clean untouched master/source component produced MUCH more predictable SqFt/LnFt reporting than continuing to copy already-modified instances.

I’m also starting to think:
scaled instances themselves may not actually be the problem — it may be more related to transform inheritance, redraw/cache behavior, and workflow discipline over time.

One thing I’m still trying to solve is actual cut-piece area calculations.

Right now formulas like:

text id=“10l65i” (LenX*LenY)/144

appear to calculate the bounding rectangle dimensions of a component rather than the actual remaining geometry after cuts/openings.

For example…
a sheet with a large window cutout may still report as a full 32 SqFt because it is using the outside extents rather than the true face area.

Have you found any good workflow for calculating;

• actual remaining SqFt
• net material coverage
• cut-piece area

instead of just bounding dimensions?

I’m curious whether:

• advanced DC workflows handle this manually
• there’s a Ruby/API solution
• or there’s some best practice I’m missing.

Really appreciate the insight — this discussion has already helped me rethink how I’m structuring the entire workflow.

[ryan.moore]

@edgewoodcustom

• actual remaining SqFt
• net material coverage
• cut-piece area

Use FaceArea, it calculates area based on material. You can always apply it to a backface that is not visible for aesthetics. Here is a plywood example, the “plywood tag” material is applied to an interior face of the DC.

DC lumber 2.skp (971.7 KB)

This page might be helpful if you have not found it yet:

Dynamic Components Math Function Examples

[edgewoodcustom]

Morning,

Any idea of how to view instances, IU. I found that once a component is placed there is a hidden Element “instance” that sketchup may keep track of and this my be the path to changing it he game with DC

[ryan.moore]

Not really sure what you mean. There is a lot that goes on with DCs, all kinds of hidden attributes that make them work behind the scene. You can use Attribute Helper to see them.

[edgewoodcustom]

I’m trying to understand something deeper about Dynamic Components and reporting behavior in SketchUp.

After a lot of testing, I started keeping untouched MASTER SOURCE components directly inside the model on a dedicated tag/layer and always copying fresh working instances from those masters before making any geometry/scaling changes.

That dramatically improved:

• LnFt consistency

• SqFt consistency

• report grouping behavior

• Dynamic Component predictability

What I’m now wondering is:

Does SketchUp/DC internally track some kind of hidden instance lineage, transform history, or definition inheritance that affects reporting/calculation behavior over time?

In other words:

• if I repeatedly copy already-modified/scaled instances

• instead of spawning fresh copies from the original source definition

can stale transforms or inherited instance state affect:

• LenX/LenY/LenZ calculations

• report grouping

• DC redraw behavior

• Generate Report aggregation

• or attribute consistency?

The reason I ask is because I was getting inconsistent behavior until I started treating the model more like a controlled database:

• untouched masters

• fresh spawned working copies

• minimal inheritance chain

• strict attribute normalization

Another thing I discovered:
LenX/LenY/LenZ appear tied to INTERNAL component axes, not world orientation, which explained some strange LnFt reporting.

I’d really like to hear from advanced DC users or Ruby/API people:

• Is there actually hidden instance tracking happening internally?

• Does Generate Report rely on instance state beyond visible attributes?

• Are there known issues with copying modified instances repeatedly?

• Is there a “best practice” workflow around master definitions and instance spawning for reliable reporting?

I feel like I stumbled onto something real here but I’d like to understand what’s actually happening under the hood.

[ryan.moore]

@edgewoodcustom

After a lot of testing, I started keeping untouched MASTER SOURCE components directly inside the model on a dedicated tag/layer and always copying fresh working instances from those masters before making any geometry/scaling changes.

If you pull from the components browser it does the same thing.

@edgewoodcustom

That dramatically improved:

• LnFt consistency
• SqFt consistency
• report grouping behavior
• Dynamic Component predictability

I don’t think your Master Source approach would have any bearing on this.

@edgewoodcustom

Does SketchUp/DC internally track some kind of hidden instance lineage, transform history, or definition inheritance that affects reporting/calculation behavior over time?

Every group and component in SketchUp has a transformation matrix, Scale Definition (right click menu) literally does that and sets the definition matrix to match the instance you used Scale Definition on. That’s why Make Unique is so handy.

@edgewoodcustom

can stale transforms or inherited instance state affect:

• LenX/LenY/LenZ calculations
• report grouping
• DC redraw behavior
• Generate Report aggregation
• or attribute consistency?

Generally these come from DCs with formula issues, or the use of groups instead of components, or the LenX bug I referred to earlier, Sq.Ft. consistency being related to your Len calculations for it I imagine. Generate Report has issues with aggregating copies, it does not count the copies. A quantity with copies x quantity solves this.

@edgewoodcustom

• untouched masters
• fresh spawned working copies

pull from the Component Browser Window.

@edgewoodcustom

minimal inheritance chain

I really don’t think this is a thing. Every instance has one definition, there is no inheritance chain. Unless you mean passing attributes down through multiple levels of nesting?

@edgewoodcustom

LenX/LenY/LenZ appear tied to INTERNAL component axes, not world orientation, which explained some strange LnFt reporting.

Ya, otherwise the DC would break everytime you moved it to a new position.

@edgewoodcustom

I feel like I stumbled onto something real here but I’d like to understand what’s actually happening under the hood.

DC extension is private, but there are people who have been prodding it for years and most of that experience is here in posts. I suggest taking some time and reading about the issues you are experiencing individually and see if there are explanations here that can help. We would all love a look inside the DC extension but I doubt that is gonna happen any time soon. I think maybe you are looking too deep, try a more pointed approach to solving an individual DC issue, not the whole DC extension. Once you have a firmer grasp on building DCs and how they work take a stab at the whole DC extension. I ended up writing a personal extension to add the functionality I need to DCs, I had to learn Ruby for that but it was worth it and I got a lot of help here.

[edgewoodcustom]

Thanks, I appreciate your feedback. I was hoping I could go back into existing projects and set up DC easily but I do not think that will be the case. After many hours of trial and error after error after error I did figure out a steady workflow for new projects. It seems to me that whoever is writing code for DC in this program needs help!

[ryan.moore]

The DC extension was written years ago, and has received zero updates, it probably never will. There is no one writing code for it. Perhaps instead of re inventing the wheel and endless trial and error, take a look at what others have done after years of trail and error, there is a ton of experience here… or re invent the wheel, up to you.

[edgewoodcustom]

Understood

[pcmoor]

Choose your main axis and material orientation. Say XY as flat plane with Z for thickness. These suits the cutting components for holes and cuts. Decide which is the length for grain, X or Y. Then rotate to suit with a buffer level between when required.
As observed, you could employ instance names, that is keep the definition as generic and the instance as specific. Like “Pine” as the definition and “4x2 Stud” or “S1” as instance. “S1” could be linked to a table. For the DC sub parts, you will find it better to use the generic “parent!” term in referencing, so not dependent on loss of the pointer to the instance or dialog header.

Choose the method(s) of reporting.
Say if OpenCutList, then let it take care of material, edges, labels, diagrams… this extension is being rapidly improved and can take on drawing methods beyond DCs. It reports the visible objects including internal DC copies. However it requires more work to report instances and remapping of a table or list.

The inbuilt Report Writer requires a lot more work, but it can achieve most of what is required. Its greatest advantage is you can report based on any attribute as the lead, rather than the component name as in OCL.

There are other reporting extensions, your workflow maybe a combination of two or more, depending on the strengths and results.

One of the MOST important additions to DCs is Enroth’s Deep make unique extension; after copying an instance you can make it and all subs unique before change the formulas or structure to develop further DCs. look in posts on this as you can fix previous DCs that are misbehaving.

With area reporting, use “FaceArea” with a sub DC, this will force the uniqueness and update the calculation.