Groups, Components, and Tags: A Clean Model Organization Strategy

Why organization matters (and what “sticky geometry” really means)

In SketchUp, edges and faces “stick” to each other when they are in the same editing context. That is useful for drawing, but it becomes destructive when you are iterating: moving a wall pulls a floor edge, a window cut tears a façade, or a massing option accidentally merges with another. A clean organization strategy is simply a set of rules that controls where edges/faces are allowed to exist, and what gets visibility control. The goal is predictable edits, fast optioning, and models that stay lightweight and readable.

Part 1 — Rules for raw geometry: keep edges/faces inside groups/components

Rule 1: Never leave raw edges/faces at the model root

Raw geometry should live only inside a group or component. The model root (the default context when nothing is being edited) should contain only containers: groups, components, and a few helper objects (e.g., section planes) if needed.

• Good: A building mass is a group; its faces are inside that group.
• Bad: A building mass is drawn directly in the root; its faces can merge with site edges, neighboring options, or later edits.

Rule 2: One “thing” = one container

Decide what counts as a “thing” in your project and wrap it immediately. Examples: site topo, each building option, each core, each floor plate, each façade system, each unit module. This keeps edits local and makes it easy to isolate, hide, and swap.

Rule 3: Create containers early, not after the fact

Best practice is to draw a piece of geometry, select it, and immediately make it a group/component before continuing. Waiting until later increases the chance that edges have already merged across boundaries.

Step-by-step: a safe “draw → contain → continue” micro-workflow

1. Draw the minimum geometry needed (e.g., a rectangle and Push/Pull for a mass).
2. Select the new faces/edges (triple-click is often fastest).
3. Make Group (or Component if it will repeat).
4. Name it immediately (see naming conventions below).
5. Only then continue modeling adjacent elements.

Rule 4: Edit only in the correct context

If you need to modify a mass, double-click to enter that group/component and edit inside it. If you find yourself selecting edges/faces without entering a container, stop and check your context.

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

Rule 5: Avoid “accidental nesting” unless it serves a purpose

Nesting (groups inside groups) is powerful, but uncontrolled nesting makes selection and tagging confusing. Use nesting intentionally: e.g., A-Massing_OptionA contains A-Core_Typical and A-FloorPlate_L02. Avoid nesting random fragments created during edits.

Naming conventions for containers (practical and sortable)

Use a prefix system so items sort logically in the Outliner and are easy to search. Keep names short, consistent, and descriptive.

Tip: Add a second descriptor for status or optioning: A-Massing_OptionA, A-Massing_OptionB, A-Core_Typical_v02.

Part 2 — Groups vs Components: choosing the right container for iteration

The core difference

Groups are unique instances: editing one does not affect others. Components are linked instances: editing one updates all instances of that component definition.

Use a Group when… (unique, one-off, or intentionally independent)

• Massing options: Each option should be independent so you can distort, cut, or replace without affecting others (e.g., A-Massing_OptionA as a group).
• Site topo: Often unique to the project (S-Site_Topo).
• One-off cores: If each core is different, keep them as groups.
• Presentation-only geometry: Elements you expect to “break” for visuals.

Use a Component when… (repeatability, consistency, and fast global edits)

• Doors/windows: Repeating openings benefit from one edit updating all. Even in early studies, a consistent window module speeds iteration.
• Typical core: If the project uses a repeated core layout across towers or options, make A-Core_Typical a component and place instances.
• Unit modules: Apartment/room modules are ideal components; you can test unit mix by swapping instances.
• Repeated façade bays: A bay component lets you iterate mullion spacing or depth once.

Step-by-step: converting a “typical” element into a component library

1. Select the grouped element you want to repeat (e.g., a core block).
2. Right-click → Make Component (or create a component directly).
3. Name it with a clear, reusable name: A-Core_Typical, A-Window_1200x1500.
4. Set axes logically (e.g., lower-left corner at floor level) so placement and rotation are predictable.
5. Place instances where needed; avoid copying raw geometry.
6. Edit one instance to confirm all update; if not, you likely created unique copies (check “Make Unique” usage).

When to “Make Unique” (and how to avoid accidental divergence)

Use Make Unique only when an instance must diverge from the typical definition (e.g., one corner unit variant). Immediately rename the new definition so it doesn’t remain an anonymous offshoot.

• Example: A-Unit_1BR_Typical → Make Unique → rename to A-Unit_1BR_Corner.

Practical decision table

Part 3 — Tagging strategy: tags on containers only (never on loose edges/faces)

The rule that prevents most visibility chaos

Apply tags only to groups/components, not to raw edges/faces. Raw geometry should remain on Untagged (the default). This ensures that hiding a tag never partially hides the “skin” of an object while leaving stray edges behind, and it prevents geometry from interacting across hidden/visible states.

Why tagging raw geometry breaks models

• Partial visibility: Faces disappear but edges remain (or vice versa), creating confusing selection and export issues.
• Editing surprises: You enter a group and find some internal edges on a different tag, so they vanish when you toggle visibility.
• Inconsistent scenes: Scenes rely on tag visibility; mixed-tag raw geometry leads to unpredictable results.

Recommended tag structure (simple, scalable)

Keep tags aligned with how you want to show/hide the model in iterations and presentations. Avoid making a tag for every object; use tags for categories and major systems.

• A-Massing
• A-Core
• A-Floors
• A-Facade
• S-Site
• C-Context
• X-Helpers

Then name the containers themselves with the more specific names: tag = category, name = identity.

Step-by-step: tagging an object correctly

1. Select the group/component (single click).
2. In Entity Info, set the Tag (e.g., A-Massing).
3. Enter the group/component and confirm internal raw geometry remains Untagged.
4. If you need sub-visibility inside a container, prefer nesting (sub-groups/components) over tagging raw edges/faces.

Nested tag misuse: what it is and how to avoid it

Nested tag misuse happens when a parent group is on one tag (e.g., A-Massing) but child objects inside are tagged differently (e.g., A-Core), causing visibility conflicts. The clean approach is:

• Either keep the parent container as an untagged “folder” and tag only the children,
• Or tag the parent and keep children untagged (or consistently aligned),
• But avoid mixing tags arbitrarily across nested levels.

Example strategy for a building option:

• A-Massing_OptionA (group) on tag A-Massing
• Inside it: A-Core_Typical (component) on tag A-Core
• Inside core: raw geometry stays Untagged

This is acceptable because the child’s tag is intentional and the parent is acting as an option container. The misuse occurs when internal edges/faces (not containers) are tagged, or when visibility intent is unclear (e.g., random child groups tagged inconsistently).

Audit routine: find stray geometry, untagged objects, and tag nesting problems

Audit goal

Run a quick audit whenever you import context, copy/paste between files, or finish a major iteration. You are checking three things: (1) stray raw geometry at the root, (2) containers that are untagged when they should be categorized, (3) tag misuse inside containers (especially raw geometry tagged or inconsistent nesting).

Step-by-step audit (5–10 minutes)

1. Outliner scan (structure check): Open Outliner and look for unnamed items like “Group#123” or “Component#45”. Rename key items using your convention (e.g., A-Massing_OptionA, S-Site_Topo).
2. Root stray geometry check: Click in empty space to ensure you are at the model root. Drag a selection window across the model. If you can select individual edges/faces without entering a group/component, you have stray geometry. Immediately group it or delete it if it’s accidental.
3. Tag sanity check (top level): Select major containers one by one and confirm their tag in Entity Info matches your category system (e.g., massing on A-Massing, site on S-Site).
4. Untagged review: In the Tags panel, toggle visibility of category tags off one at a time. If important objects remain visible, they may be untagged containers that should be categorized, or stray raw geometry at the root.
5. Inside-container tag check: Enter a few representative groups/components (massing, core, façade). Select internal edges/faces and confirm they are Untagged. If not, retag them to Untagged and use nested containers for visibility control instead.
6. Nested tag intent check: For any parent container used as an “option wrapper” (e.g., A-Massing_OptionA), verify that child tags are intentional and consistent (e.g., all core instances on A-Core, all façade modules on A-Facade), not random leftovers from copy/paste.

Common fixes during audit

• Fix stray geometry: Select stray edges/faces → Make Group → name it → tag the group appropriately.
• Fix untagged containers: Select the group/component → assign the correct tag in Entity Info.
• Fix tagged raw geometry: Enter the container → select the raw edges/faces → set tag to Untagged. If you need separate visibility, wrap that subset into a sub-group/component and tag the sub-container.
• Fix messy nesting: If a container has many mixed-tag children with no clear intent, consider reorganizing: create a small set of sub-groups (Core/Floors/Facade) and move items into them, then tag those sub-groups consistently.

A compact checklist you can keep next to your model

• Root contains only groups/components (no loose edges/faces).
• All raw geometry is Untagged.
• Tags are applied only to groups/components.
• Names follow the prefix convention (A-, S-, C-, X-).
• Components are used for repeatable elements (doors/windows, typical cores, unit modules).
• Nesting is intentional; tag relationships are consistent and purposeful.