"make component" takes very long, does not complete - too long to be productive


3 hours and 20min to open the house …


for IFC’s, at least, the tags aren’t the real issue…

every item has a common origin, so all the geometry ‘positions’ are different for identically sized/shaped items…

programatically changing the ‘insertion point’ of a component if actually extremely difficult, as there are an innumerable variations of scale and position in 3d space…

even something as simple as a IFC Space [which all could be a single SU comp at different scaling for each variant] requires masses of computations to get right…



I’ve started working on an extension that located similar definitions but with different transformations. and merges them. However it only supports translations and scaling, not rotations. Maybe I should try to get it published.




for comparing geometry separate from transformations ? but unfortunately there’s no equivalent for a component_definition.

An untested idea for a ‘script’…

Inside a model.start_operation(... block…
Add a temporary group into the model.entities [so you can erase it at the end].

There are probably some ‘name’ clues in ‘similar’ definitions which could be used to reduce what needs to be examined ? e.g. door, door#1, door#2 etc…

Add a subgroup into that temp_group.entities = group1

Collect all possible definitions to test…

Add an untransformed instance of our first test definition1 into the subgroup.entities, explode the instance.

Test each remaining ‘candidate’ definition in turn.

Add a second subgroup and an untransformed instance of the candidate definition2 into its entities, explode that instance.

Now use the group1.equal?(candidate) test on these two subgroups.
If the candidate returns true then iterate its defintion2.instances and reset their definition to be definition1…

Record actions for a final report…

If true, then also use definition2.entities.clear! to tidy up.

Then erase ‘candidate’ group.

Repeat testing definitions using new a candidate group against group1.

After all candidates are processed, then make a new group1 using the next available valid definition.
Test this against all remaining candidate groups as above…

Finally delete the temporary group to tidy up, and report the remembered changes.

After all definitions have been processed the number of definitions should have been reduced to just those which are not .equal? to any other definition…


Here’s some working code to consolidate two definitions with equivalent geometry:

# Usage TIG::Consolidator.new(defn1, defn2)
# If geometry of defn1 == geometry of defn2, 
# then all of defn2 instances become defn1's and defn2 is cleared from defns.
module TIG
  module Consolidator
    def self.new(defn1=nil,defn2=nil)
      if ! defn1 || ! defn2
        puts "Must pass two definitions as arguments"
        return nil
      elsif ! defn1.is_a?(Sketchup::ComponentDefinition) || ! defn2.is_a?(Sketchup::ComponentDefinition)
        puts "Must pass two definitions as arguments"
        return nil
      elsif defn1==defn2
        puts "Must pass two different definitions as arguments"
        return nil
      if gp1.equals?(gp2)
        rep<<"#{defn1} == #{defn2}"
        defn2.instances.each{|e| e.definition=defn1; ctr+=1 }
        rep<<"\n#{ctr} instances consolidated"
        rep<<"#{defn1} != #{defn2}"
      puts rep


An extension will only get to work when the model is loaded, an importer might tackle the problems before?
simple example:

an ifc file with the size of 2.3 KB will result in a 37MB SketchUp file.KozijnenOnly.zip (388.2 KB)

and it is just a few frames…


extracted this ifc from a 280 MB file wich would result in a 4.5 GB SketchUp File, theoretically.

SimpleBIM handled that file dead easily… 1 1/2 minutesbim

A subscription is about the value of Sefaira or Studio…



I was successful in getting my work out of the model. Sure it took lt took longer than expected, but never the less it was acomplished.

Here are some stats for the future

  • original JT file size 123mb (yes 123mb)
  • sketch up 2018 pro
  • jt importer ( SIM LAB JT IMPORTER)
  • 1.52gb SU file after imported (took ~15 min to import file) looks like the JT imported could use some tuning. Added alot of extra fat.
  • after importeer did its thing system was unbearably slow!
  • turned off auto save
    – just saving a file this size takes ~7 min
  • adding layers to model to be able to work more effencently
  • tried to create standard box to component (would not work!) several long attempts! when the program did finally do its thing nothing was visable, it was like nothing happened.
  • solution : I say this lightly…
    -open the house icon in Tray… just to open house took 3h 20m!!!.
  • after tray was open and 15k thumbnails were visable (however the scrool button did not function correctly) I was able to pull existing model components into model.
  • create standard box component (took 5m to create 1st small component)
  • create my work component (653mb took ~10min to create)
  • save newley created component to drive (~5m to save to drive)

For all of you who proticipated in this conversation I very much appreciate your thoughts and imput! I look forward to chating with you in the future.

Again, Very much appreciated,
Mike P


I’m reading this thread with great interest- looks like the JT import probably added a bunch of weight to the model, but I don’t enough insight about how SIMLAB did their implementation to know where or how. Where did the original JT data come from? I typically associate that filetype with MCAD applications (like Solidworks) rather than BIM applications (like Revit). What sort of project are you working on?

You definitely win the prize for the largest SketchUp model I’ve ever seen, easily 2x larger than the previous biggest model I had ever seen.


Creating those 13507 thumbnails into the Component Browser might be one of the most important reasons for the long waiting times.


Sketchup also stores all those thumbnails inside the model adding to the large file size.

Sketchup has to under the hood one by one look at each component (essentially hiding all the rest) and create an image for each component.

This is why I mostly use groups and only use components where necessary.


Origional JT file was Solid edge- exported to .jt format for site viewing.
Project is large scale industrial Construction. .jt files like these are becoming more commonplace in my field. SU is in my option a very easy to learn interface… so I expect migration of this nature to continue in the future. Trimble needs to put more efforts into making these cross systems more compatible and more efficient. If Trimble does this I easily see a future here. As for size… lol … I expect to see another 2x larger files next year.

Mike P


Lots of piping?


yes piping, and ironwork as well.


It would be interesting to see what SimpleBIM could do with your .jt file as opposed to SIM LAB.