Cross Reference Organizer



New Plugin on the scene!

Cross Reference Organizer is designed to bring SU closer to being a design environment in which team members can collaborate simultaneously.
The plugin facilitates team members breaking a project into parts and and cross referencing each others’ models in their own workspace.
It has a clean and simple UI that allows you to visually understand what in your model is cross referenced and how up to date it is.

It solves a key problem we found when using the File/Import/Reload process native to SU, namely the superimposition of multiple copies of content when many people in a team Import eachothers’ work. It also addresses a problem we found using Trimble connect in our workflow - including the need to publish over a slow connection, and not having a visually orientating understanding of one’s cross references.

The impetus for commissioning it for our own use came from a desire in our mid-sized Architecture office to avoid the large up-front and productivity-ramp expense of moving to Revit or Archicad, further equipping SU /LO to be an end to end solution for teams.

5 FREE licence keys available to the first five people to road test it and privately give me just one item of feedback.

Find it here:

George Theodoridis
Business Manager
Law Architects
Melbourne Australia

Observer for recognize object moved
Forum Guidelines and Categorization Gray Area

I am very interested. Thank you for posting and let me know.


Would also v much like to try it.


Guys, this plugin is very cool. Basically it is Autocad’s Xref manager for Sketchup - allowing you to separate out large models into smaller parts for multiple people to work on separately and then bring them together at the end. Keeps track if referenced files have been changed and allows you to reload/update them easily.

Every architecture firm should get this plugin!


Hi Taintedangel, you can try it now if you like, just go to and dowload the trial.


Hey John, give it a spin, it’s over at


Looks v good, if I can persuade my collaborator to use it - he’s impatient, and wants to charge ahead in one big model.


Well, my collaborator has taken against a new plugin in the middle of building a large and complex model, and doesn’t like the way it prefixes cross referenced component names with XRC- and layers with XR-. It means that components and layers that come from Cross References appear out of sequence with native layers in the main model

I think that is a small price to pay for the convenience it offers. And if, as recommended, you start with a completely empty main model, and Cross Reference in all the major sub-models, that problem also disappears if you use it from the start.

But I think it’s great, and intend to use it myself to keep track of sub components edited separately in sub model files, even when working solo.

It is cleverer than the existing Xref Manager plugin, which I have also used, in that it avoids duplicating definitions of subcomponents that may already appear in others’ sub models you have imported. And it has a more elegant interface

I had a little difficulty getting started with it, as it puts its main menu entry on the Windows menu and I took some time to find it. It doesn’t go on Tools, or Extensions, where I first looked for it, which is unusual but not unprecedented.

I was also having problems initially in a very large model, which completely went away after restarting SU. Even though it was my problem, the authors were quick and helpful to respond to my tribulations.

Haven’t used it long enough myself to vouch for its stability, but it has been in production use in the developer’s own architectural practice for some time, without reported problems, and (he says) has saved his practice much money by avoiding having to migrate to much more expensive software for team development.

Highly recommended.

So is Layers Organizer from the same source. It’s a significant development from the former Layers Panel plugin (I think that was the one), whose author had to abandon further development.


Thanks for the feedback John.

(Just to say, in case it is helpful, the XRC and XR prefixing is only done for layers that have names unique to the source model being Cross Referenced, as it arrives in the destination / working model. This aligns with the intention that Cross References are locked in the destination model and are not edited there - they are just for reference. The prefixing therefore allows for Cross Referenced layers to be quarantined away from the working model’s layers, thus avoiding visual clutter with layers that are not ‘operational’, so to speak, in the working model. When CRO is used with Layers Organizer, these prefixed layers are automatically grouped per Cross Reference for the same purpose.
Additionally, these prefixes have the practical function for the programming logic to avoid re-importing and duplicating/triplicating/quadrupling etc. content into your destination file that is already Cross Referenced in other source files the project team are commonly Cross Referencing.
Sorry to be verbose.)


@Yorg There was a notice on your website last week that you’re attending to some issues with the extensions and that you intend to have it sorted by 19/06/2017 (today). Further notice / advice was not to use any of your extensions until such time.

I wanted to confirm if this is the case as I don’t see the notice any longer. The extensions there (which seem to download as ZIP files from Google Drive now, but that isn’t a problem if you know what to do) are later/updated versions now?

Also, seeing I bought the extensions and am subscribed to a mailing list (if memory serves), it would have been nice to get an e-mail in this regard…


Hi Julian. My apologies, you are quite correct in your expectation - I’m just getting used to being a software vendor and the support protocols expected.
Also pease feel free to email the support address any time too.
No there are no issues - John in this thread was experiencing behaviour we had not seen and I wanted to be cautious. It went away after he rebooted his machine, so I felt confident in restoring the site.
Since you are using it, I would be very grateful for any feedback you might have.
I made the downloads a zip to avoid confusion. The only difference otherwise is that the plugins previously checked the internet on startup to check the licence. This is no longer the case - they connect only when first activating the licence key or de-activating. You can download and reinstall if this is useful to you. Otherwise functionality is the same.


I have since experienced one odd behaviour. If I try to add a new cross reference to a submodel that is currently open in SU, the plugin appears to hang. No error message, but Wait spinning ball (Mac).

Closing the submodel and trying again usually works, though sometimes I have to close and reopen SU first.

I will check tomorrow if my description is accurate by trying again deliberately. It’s been accidental before.


@Yorg thank you for the feedback, it is appreciated.


Hi John,
In our testing we were at first dis-heartened by what we thought was poor performance of the plugin when working with models that had many scenes and layers. It took a long time for importing or updating Cross References.
So we tested by comparing with the plain vanilla File/Import functionality of native SU - using the same files.
It turns out that File/Import for these files takes the great majority of the time, so we see it as essentially a behaviour of native SU.
So, if it looks like it is hung and you wait it out - even if you see a dialog box saying it has finished - our testing shows it finishes reliably.
If you see a dialog telling you a script is taking a long time - don’t stop the script.
Your having source models open should not affect it, as it is working off the saved file - and in any case, its main purpose is to work with source models open and being used by other team members.

All that said, if you can replicate the behaviour and it doesn’t fit my understanding above - please let me know.


In my workflow I think of layers as global, not local to any component. If I would draw a whole neighborhood and link in the individual houses I would typically want to hide the furniture and perhaps also slabs, internal walls and a whole bunch of other layers to increase performance. I do not think of that as editing the linked model but as globally changing the viewing options for the model as a whole. I still understand your thinking though. Perhaps there could be an option to toggle this behavior of creating new layers on and off.

Also, if these prefixed layers are not “in operation”, perhaps it’s better to not have them being layers at all but just apply the visibility state directly to each entity and purge the layer to avoid confusion and clutter. This way the visibility state would be controlled from the linked in model and the linked in model alone.


I’m going to try the plugin but have some questions to adress before I do it.

I use to model the whole building alone for a while and then split it into smaller references using context menu “save as” on components.

This goes on as the detail increases. My references will, at some point become parts of the building like whole rooms, or stairwells, windows, doors and cabinets or kitchens.


  • How does the plugin handle creating a reference from an existing component by exporting it and turning it into a xref?
  • What happens if a xref is nested in another xref? (A window in the envelope component, for instance)
  • What happens if my workflow implies importing xrefs working on them and saving out into external files. Can I work on several of my components and export them to external files in one go?

Thanks in advance,



Hi Julia,
Interesting thoughts.

Re layers as global not local -if I read you correctly:
Let’s use the example of 2 buildings sitting next to eachother on a site connected with an overpass on the 2nd floor. The overpass is being worked on by another team member, but you want to reference it into your model so you can articulate your design with it.
Applying your point to this example, you may only need to see the overpass as visible, not the rest of the building in the Cross Reference.
Yes you can do this with the integration feature between Cross Reference Organizer and Layers Organizer.
In Layers Organizer the individual layers in the referenced building can be made visible or invisible. This assumes the geometry of the overpass is associated with a layer/s so that the overpass can be visibly isolated - which is a usage/convention/workflow issue.
A point to note: upon update, all layers in the Cross Reference are made visible, regardless of how the source layers are configured at that time (according to the source user’s needs at that time). A way of managing this is to use the Layer States panel that comes with Layers Organizer to save a layer configuration /state and invoke that state to suit the destination user’s needs at that time.

Re Purging layers to ‘flatten’ the Cross Reference:
The sense in which layers are not ‘in operation’ is that the content is not intended to be edited in the destination model - it is there for reference purposes. However, the layers are available in Layers Organizer, as mentioned above, to manipulate visibility. This sits comfortably for us with the SU convention that Layers are a good way to manipulate visibility. I may still want to understand what my team members are doing and have the full power of manipulating the layers as they are using them. I would not want to throw away that power.
Using entities - do you mean hiding and unhiding them? - is not something we thought of but it is possible now by unlocking the Cross Referencing and hiding/unhiding, but my immediate concern is that it is not easy to see what is hidden at any one time in a complex environment, and easy to forget hiding stuff. I would not use entities as the primary approach to manipulating visibility in my working model, so I would not prefer to do so for cross referenced content either, especially as I can use Layers Organizer to manipulate layers.

Thank you for your thoughts - I welcome them, and if enough people find the plugin useful to them I may have enough funds to incorporate more features that come out of feedback just like yours.


Hi João
We tried using a ‘save out’ workflow, but found it so clunky in a team environment that it was part of the impetus for developing the plugin.
Response in line below:

- How does the plugin handle creating a reference from an existing component by exporting it and turning it into a xref?
If you are starting in one file and then deciding to split parts out - which would be common - then the general principle is that you don’t try and Import as a Cross Reference the content that is already in your destination file.
Please have a look at the 2nd video:
The pdf of that video is available on the site under the Instruction & Info link.

So to establish the correct state of your files there are 2 methods:
Method 1 - Save out the component. (SU will not preserve the location in the model space - it will locate it at the origin.)
1/Make the content you wish to turn into a Cross Reference into a unique Component.
2/ Save out the Component into your desired location.
3/ Delete the Component in the original file - right click on the Component in the Components Tray and ‘Delete’, choose to delete the definition and all instances.
4/ Cross Reference it, using Cross Reference Organizer.

Method 2 - Preserve location of content
1/ Make a copy of the original file, renaming it as desired
2/ Purge this copy of all content and un-needed / unused Component Definitions, except the content you wish to make a Cross Reference.
3/ Go back to original file and delete the content and Component Definitions that will be brought in as a Cross Reference
4/ Establish the Cross Reference, using Cross Reference Organizer

- What happens if a xref is nested in another xref? (A window in the envelope component, for instance)
You might already understand this from the above video, but the core function of this plugin is to exclude content from importation into your destination that is already Cross Referenced in the source - in order to avoid multiple instances of content. So the workflow includes an upstream to downstream concept, as you can see in that video.

- What happens if my workflow implies importing xrefs working on them and saving out into external files. Can I work on several of my components and export them to external files in one go?
The plugin is designed so that you can avoid having to do exactly this. You work on them in place. Again, the video should explain this.

Kind regards



Not the best workflow for exporting xrefs. It’s my standard procedure and we work like that here. It seems a complex method to export, delete, import 30+ windows, cabinets, gates and whatever components I want to work on individually and group in a new file.

Would you consider changing/adressing this issue?

I cannot understand what you mean exactly. The way I see it, what you have only allows us to work on a single component per file, while we reference other components in that same file that are only there for reference.

The way I work with xrefs in Sketchup is different as I have 2 methods:

  1. I work as you do, where I have components at the same level (two houses for instance) and your plugin seems to adress that perfectly.
  2. But I also have a bunch of xrefs inside my working file. I work on them all inside that file, and export them so they can be referenced in other files. For instance, windows. I have them in the building, of course, but then I export them to a file where they sit side by side and I can manipulate them all easily and send to layout from there. For instance, if all of them have the same handle I work on the handles on this file, place them correctly, save the components, have my layout file for windows updated and then reload them in the main file already updated.

2 is not a workflow your plugin handles, right?

That seems to be what you say here:


Thanks for that clarification, and your explanation of how the naming and layering works - as it happens, the model I’m including by CRO only has unique layer names, I think, so I didn’t spot the subtleties.

I’m just trying to update Scott’s (@NewThinking2) main model from an existing source model, which imported quickly last night in around a minute or maybe two - I wasn’t timing exactly. The main model now has more layers on, and they have complex geometry visible, and the import it taking MUCH longer - the beach ball WAIT icon is still spinning nearly a quarter of an hour after I click Update in CRO.

I think I’m going to Force Quit, reopen the main model, turn off the ‘busy’ layers, and start over.

But I’ll wait another 10-15mins. If it isn’t done after half an hour, something has gone wrong.