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

nothing imported from warehouse…

How does the model operate in monochrome view?

This is very common when importing ifc files.
Because every part (to the level of mullion) has to be a unique component, so not making use of the fact that they are the same geometry.

If (named) instances were created in the ifc-importer, you would take advantage of the component-handling in SketchUp

7 min to open such a file is relatively quick, since every component is a ‘mini SketchUp File’, thus opening about 30 files per second🤔 in the component browser

Just moving around it works fine. Creating new geometry is similar to empty model (fine). Exploding original model took 15min. After model is on many different layers (the work of almost a week) the model works fine. Mostly moving around in wire frame. But model works great! Very useful.

. I just cant get my work out of the model and the only way I see to do that is to create a Component and save the component to drive.

ya… were at 3 hours just waiting for the house tab to open and the model and not responded yet. Don’t think this is working.

This sort of model size and complexity - especially the number of unique groups - is not uncommon when an architectural or detailed engineering plan is imported as an IFC . BIM files create lots of “unique” components - while the geometry is the same between each, they are tagged with info like “Chair F1-09”.

Youll probably also see that the components/groups are not ordered in a tidy family tree heirarchy very efficiently - i thing this may also affect things. Eg all furniture will be grouped/layered togther rathe than placing furniture within a “room” component.
And theres possibly a lot of hidden ■■■■ that doenst get purged either on import or on Sketchup’s purge .
Closing the component browser, entity info, outliner and model info windows while doing this may speed things up a bit.

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…

john

1 Like

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.

There’s

group1.equals?(group2)

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
      end
      model=Sketchup.active_model
      defns=model.definitions
      ents=model.entities
      model.start_operation('consolidator',true)
      rep=""
      tgp=ents.add_group()
      gp1=tgp.entities.add_group()
      int1=gp1.entities.add_instance(defn1,ORIGIN)
      int1.explode
      gp2=tgp.entities.add_group()
      int2=gp2.entities.add_instance(defn2,ORIGIN)
      int2.explode
      if gp1.equals?(gp2)
        rep<<"#{defn1} == #{defn2}"
        ctr=0
        defn2.instances.each{|e| e.definition=defn1; ctr+=1 }
        defn2.entities.clear!
        rep<<"\n#{ctr} instances consolidated"
      else
        rep<<"#{defn1} != #{defn2}"
      end
      tgp.erase!
      model.commit_operation
      puts rep
      return
    end
  end
end

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…

Notes

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…

STATUS UPDATE:

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

2 Likes

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.

2 Likes

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

3 Likes

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.

2 Likes

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.