Make SU 2018 the "organised" update

As I have grown to use SketchUp for all of my architectural production needs, my models have grown to be complex. Hundreds of components, dozens of layers, materials and scenes. SketchUp’s interface that dealt with these, while simple and effective for, say furniture, doesn’t scale very well for big buildings and the production drawings that I need to take from my models. For taking reports (using the “Generate Reports” tool), I expect you would need an even higher degree of organisation.

So my wish is for SketchUp 2018 to be the big ORGANISATION update, so that advanced and beginner users alike can happily organise complex models. I think a complete revamp on all these fronts would be a good start:

1. Material Palette (at least for Mac)

  • the ability to see materials and their names next to each other (for Mac). I find that material names are becoming more important in my workflow.
  • search bar to filter the list of materials

2. Scenes tabs

  • when you have more than say, 12 scenes, the scenes tab gets awfully cluttered, to the point where you can’t actually read the name of the scenes, as it gets truncated (I resorted to shortening each scene name to a few characters to work around the problem, but it is not elegant). I have a suggestion for prefixing Scene names to sort them like this:

    more discussion on this here: Managing scenes in SU - #7 by TommyK

3. Layers panel

  • Again, with the number of Layers I have to deal with, the panel is getting too cluttered. Other CAD programs have layers that are grouped according to its prefix (separated with “-” or “_”, and can be hidden and expanded. This would be a nice simple touch. Prefixed layer names are standard practice in the construction industry’s CAD.
    Vectorworks does this:

    …which works perfectly well for simple and complex layer systems.

4. Components Browser Panel

  • This hasn’t changed for ages, and has become quite unintuitive.
  • get rid of the “search 3D warehouse” - it is obsolete
  • search bar should filter components in model, and search the local library.
  • have the ability to show the selected component in the view in the Component Browser panel.

Not too much to ask, is it?


Hey Tom… long time…

The scene tabs thing is a great idea! Though they might implement something in the scenes pallet instead.

I’m glad you also have an issue with materials. I always deride myself for being unorganized in this department, but when you’re trying to get a job out fast it’s hard to keep control of it!

Hi Jason! Has been a while indeed!

Yes, I agree that the scenes palette needs similar attention. You can’t beat the scene tabs system for really quick switching of views though. Good when modelling and in presentation situations.

Indeed! The problem I have is, for example, if I have a grey material, I don’t know if it is lead, or flat roof, drain pipe etc. With increased use of Skalp too, it’s important to get the materials organised.

1 Like

Indeed! The problem I have is, for example, if I have a grey material, I don’t know if it is lead, or flat roof, drain pipe etc. With increased use of Skalp too, it’s important to get the materials organised.

I think SketchUp/LayOut workflow maniacs like us need more organisation. With Skalp and Thea all in one master model it gets pretty busy in there. Makes me wonder; is there a nesting or folder plugin that you know of for the materials manager?

We are just getting around to launching Layers Organizer, which you can find now on

It allows you to group, expand, collapse, sort and a bunch of other stuff.
Give it a try, it may be what you need until SU do something similar natively.


Scene tabs is something I’d like not to see since it would just have one level of grouping. However grouping in the Scene inspector would be very useful. Otherwise I agree!


I’d have to disagree. It is possible.

In the OP’s proposed implementation the “grouped” scenes are appearing on a menu when a drop arrow button is clicked. At least on Windows, a menu may have any number of nested menus below it.

I am not against allowing the user to suppress the display of levels 3+ on the tab droplists. If this happened, clicking a group name on the droplist, would need to activate the SceneManager and select and expand that that group. (Otherwise there’d be no reason to display sub-groups on a tab droplist.)

Now, if the tab droplists were limited to only groups and sub-groups showing only scenes (as choosable items,) then the SceneManager would need checkboxes for each scene group/sub-group to denote which ones the user wanted to have displayed in the row of scene-group tabs. Or perhaps a dedicated sub-panel for managing the order and display of groups. (If say the main Scenes panel was just getting too darned busy and confusing.)

As Dan says, I think any level of nesting will be possible with this system - just as a context menu can have nested items. Like:

I’m still a bit skeptical about the scene tab menus.

It can’t look and feel too much like the programs own menu or new users will look for scenes in the top menu or top menu entries among scenes. I don’t even know if its technically possible to use the system menu system on like this or if it would have to be re-created from scratch. More importantly, the scene tabs serves the important role to show what scene is currently selected. If that scene is hidden within a dropdown users can’t see it right away without looking for it. I think the easiest implementation would be to simply flatten the scene list and show all scenes above the viewport.

Just to clarify, I’ve been in favor of scene grouping in the scene inspector the whole time, just not dropdown menus as an interface.

This is true,… however you may not realize that the (Windows edition’s) dropdown toolbar buttons on the “Getting Started” toolbar, are actually dropdown menus, whose text has been switched off, and command icon switched on.
If the “Toolbars…” edit dialog is open, you can right-click these menu buttons and change appearance properties. The normal behavior of these buttons is to display the command that is active on it’s menu.

So these buttons could show what the current scene selection is, … but they could only be one level deep. So this brings us back to what I said above, about having a sub-panel on the Scenes inspector to control what scene groups (and their order) appear upon the scene tab row.

User should be able to choose to show:

  • all scenes as tabs (the current implementation,)
  • or group tabs by prefix,
  • or (perhaps a Pro only feature,) scene tabs by a grouping panel
1 Like

I agree with you, but that don’t mean other members are wrong, all of us need a quick access to the scenes tab, but I think that the workflow of going to a scene through a drop menu from the scene tabs maybe could be quick for a one time access, but if we study our steps and clicks if we do that frequently it would be inconvenient,
-Also the workflow to create the first scene in SketchUp is not intuitive at all “view>animation>Add Scene”,

So to have a quick access to Big List for the scenes by one click, I suggest to add the Scenes window in a separate Tray as default to all Templates, I advice you to try it, create a Tray only for the Scenes, just click on the scene Tray and then we could see a big list of scenes displaying as “List” by default (not a thumbnail) !, it could display up to 56 Scene on 1920* 1080 screen without any worry if the scenes names are too long, imagine if we have scenes with long names in the Scenes tab !, I think the interface wouldn’t look professional at all .

-I think a one click to access a big list for Scenes Window is very inventive,easy to navigate,add and organize scenes.

The GUI window setup and positions are not linked to a specific model, so are not saved within the SKP file (template or not.)

Secondly if you start forcing options upon users, they will fight back.

Thirdly, the “Default Tray” is not intended to ever be the way that users use the GUI. It is expected that they’ll customize their GUI layout, by making more trays, etc.

I myself have already set up the trays the way I like them, with a tabbed array and the Layers and Scenes panels on a “Organize” tray.

This thread is about giving users more options, not forcing your choice upon them !

1 Like

I think of the scene tabs much as fast shortcuts. While the idea of making it more intuitive is tempting, e.g. by adding a + button that is also shown in it, I think it’s wise to keep it as light weight as possible so it doesn’t just become a copy the scene inspector. This is yet another reason why I don’t like the idea of scene groups among the tabs. If you have to click multiple times to activate a scene you could just have the scene inspector open from the start and click it directly in the tree view.

Regarding Trays I have to agree with Dan. The default Trays shouldn’t be designed to be the most optimal for a specific use case but to in the simplest possible way give users an overview of what they are and how they work. Then it’s up to each user to customize it to their liking.

This is in my view one of the best aspects of SketchUp and one of the keys to make it 3D for everyone; you can gradually explore and learn more and more features without having everything thrown right at you when first launching the application.

This Thread is about making SketchUp more Organized.

I think my suggestion above can satisfy both of us. I have situations where there are so many scenes that I can’t even discern what each tab is called (the text gets truncated), so the current situation of tabs become useless in these cases; the scene tabs are not quick at all.

My proposal allows the user not to group their scenes (by not using a hyphen in the scene name), in which case the current behaviour is retained. I think it is a solution that can work for both of us.

The nesting character should be customizable by the user.
And there should be definite setting control to nest (group) or not to group.

The reason is that there have been users already using hypen (dash) characters in layer and scene names who are not expecting that to cause grouping.

1 Like