Application Development Exploding Component Instances

[NoahT]

I'm trying to use code similar to the bomb program that explodes all the visible component instances in the model. It seems to take much longer than exploding manually and I was wondering why or if there were any tricks to speed it up.
My code basically applies every filter I could find or think of and makes a list of instances to explode from the purged definitions list. Then it eaches through the instances and uses .explode on each.

This is my code:

page_tab = mod.pages.selected_page
layers = page_tab.layers
entz = page_tab.hidden_entities

#Go through definitions to find component instances that need to be exploded
purg_defin.each_with_index{|defn, d|
unless defn == mod
unless defn.image?
if (defn.count_used_instances > 0)
unless defn.instances[0].nil?
if (defn.entities.length > 0)
defn.instances.each{|inst|
unless inst == mod
if inst.layer.visible?
unless layers.include? inst.layer
unless entz.include? inst
if inst.visible?
unless instances_to_explode.include? inst																																					#puts "checking #{defn.name}"
instances_to_explode.push(inst)
#inst.explode
puts "making arrays #{d} of #{purg_defin.length}"
end
end
end
end
end
}
end
end
end
end
end
end
}

#explode compiled list
instances_to_explode.each_with_index{|inst, i|
puts "exploding instance #{inst} #{i} of #{instances_to_explode.length}"
inst.explode
}

The list compilation doesn't seam to be the problem, just the line where I use inst.explode on each entity in the list. Is this normal? Why? Is there any thing I can try to speed it up? Thank you and sorry for any poor formatting or if I posted in the wrong spot, this is my first post.

[slbaumgartner]

My suspicion is that each explode causes SketchUp to process intersections between the newly released Entities and all other Entities in the context and to update the view accordingly. You might try wrapping the block that does the explodes in a start_operation /commit_operation pair with disable_ui set to true.

Also, don't have the outliner window open while you run your script. It is known to cause major slowdown.

SInce you said it seems to work, I didn't give much thought to the part of your code that picks what to delete, beyond noticing that it seems far more complicated than my gut feels it needs to be.

[NoahT]

@slbaumgartner said:

You might try wrapping the block that does the explodes in a start_operation /commit_operation pair with disable_ui set to true.

The code is wrapped in a start_operation/abort_operation, sorry for not including but the code is pretty long. Would you recommend a nested start_operation /commit_operation inside my other operation?

@slbaumgartner said:

Also, don't have the outliner window open while you run your script. It is known to cause major slowdown.

I never do but it would be nice if I could close it with my code. I see there is windows specific code but nothing for mac. I also see some suggestions that setting disable_ui to true in the operation command does this as well. Any insight on if disable_ui does this or how to close the window on mac?

@slbaumgartner said:

SInce you said it seems to work, I didn't give much thought to the part of your code that picks what to delete, beyond noticing that it seems far more complicated than my gut feels it needs to be.

Haha, yes it is. I kept getting the "causing visible geometry to merge with hidden" messagebox I have to ok through as well as trying to filter out everything i can to avoid slow explosions so it has gotten kind of ridiculous in my attempt. Any tips on avoiding this messagebox?

Thank you for the feed back and insight into what's going on I think the ouliner window tip may be very helpful.

[TIG]

Sadly your code example is poorly formatted, making it hard to read...

However, here are a few observations that might be related.
With v2017, when you explode a container all of the references you might have had to entities within that container are lost - all IDs are refreshed.
The ents=container.explode will return an array of exploded entities [and often more besides] - all with new references - so therefore you will need to re-search that array to get the needed references to any resultant 'containers' etc...

[NoahT]

@tig said:

Sadly your code example is poorly formatted, making it hard to read...

Sorry, first time testing out code posting on here. I tried to fix it a bit but it's formatting oddly. Basically, the first part is a ton of filters to select certain component instances, then there is a loop to just explode these.

@tig said:

However, here are a few observations that might be related.
With v2017, when you explode a container all of the references you might have had to entities within that container are lost - all IDs are refreshed.
The ents=container.explode will return an array of exploded entities [and often more besides] - all with new references - so therefore you will need to re-search that array to get the needed references to any resultant 'containers' etc...

I'm not sure I follow you here. Are you saying that I will need to re-search the entities after exploding? I am having trouble with the speed of exploding/freezing during exploding, not finding the entities after. Am i stuck with a slow exploding process or are there some tricks to speed it up?

Thanks, for feedback and further clarification.

[TIG]

If you want to explode all instances in the current entities context - either the model or during an edit of a group etc, do something like the following...

def exploder()
  model=Sketchup.active_model
  ents=model.active_entities
  es = ents.grep(Sketchup;;ComponentInstance)
  while es[0]
    es.each{|e| e.explode }
    es = ents.grep(Sketchup;;ComponentInstance)
    ### add this to re-explode any instances resulting from the explosion...
  end
end

Note the optional extra 'es = ' in the while loop - to exploded previously nested instances, but if that is NOT needed change it to 'es = []' at the end of the exploding... OR remove the whole 'while...end' and add the explode block immediately after setting 'es' the first time.

[TNTDAVID]

Hello,

I want to explode a list of nested components inside groups or components through their definitions.

m=Sketchup.active_model
s=m.selection
sel=m.definitions.each{|d|s.add d.instances if d.name=~/#{"Sophie"}/}
sophie=ents.grep(Sketchup;;ComponentInstance)
sophie.each{|e| e.explode }

With this code I select all "Sophie" in my SketchUp models and explode all the "Parents" components of "Sophie".

How to explode "Shophie" without modifying the parent components?

And how to explode the definition "Chris" at the same time as "Shophie"?

Thank you in advance for your help.

David

[TIG]

As usual you are making it more complicated that it needs to be - and the reference 'ents' appears from nowhere too !
Try this approach...

name="Sophie" # or ="Chris" etc to make it reusable...
model=Sketchup.active_model
matches=model.definitions.each.find_all{|d| d.name =~ /#{name}/ }
matches.each{|match| match.instances.each{|i| i.explode } }

This matches "Sophie", "Sophie#1", "Sophie#2" etc
But it'll also match "My_Sophie" !
If you want just the start "Sophie" etc use d.name =~ /^#{name}/
or d.name =~ /^#{name}$/ for exactly "Sophie".
Although if you want an exact match use d.name == name
or even simpler ?
match=model.definitions[name] ### then use match.instances... if match

It does not remove the now unused "Sophie" definition[s] from the model's definitions list !
If you want to do this, then run your code inside a model.start_operation(... model.commit_operation block, and after exploding the instances of ' match' use
use match.entities.clear! - this will 'empty' the definition and when thr operation is committed SketchUp's Garbage-Collection removes the empty definition from the model's list...

[TNTDAVID]

Bonjour TIG,

Avec votre code:

name="Sophie"
model=Sketchup.active_model
matches=model.definitions.each.find_all{|d| d.name =~ /#{name}/ }
matches.each{|match| match.instances.each{|i| i.explode } }

j’obtiens le message d'erreur suivant dans la console ruby:

Error; #<LocalJumpError; no block given>
<main>;2;in `each'
<main>;2;in `<main>'
-e;1;in `eval'
nil

Comment corriger cette erreur ?

Merci

[TIG]

Sorry, I hadn't tested it.
Here is the corrected code:

name="Sophie" # or ="Chris" etc to make it reusable...
model=Sketchup.active_model
matches=model.definitions.find_all{|d| d.name =~ /#{name}/ }
matches.each{|match| match.instances.each{|i| i.explode } }

I had an errant '.each' in it, when the '.find_all' was all that is needed...

[TNTDAVID]

Wonderful it works very well!

To explode several definitions, I simply did this:

name=['Sophie','CUBE']
model=Sketchup.active_model
matches=model.definitions.find_all{|d| d.name =~ /#{name}/ }
matches.each{|match| match.instances.each{|i| i.explode } }

[driven]

sometime it's worth writing 'visual code' to see how the ruby works...

click to see gif...

this is based on Tigs example

def explode_named(*args)       
	model = Sketchup.active_model
	defs = model.definitions
	sel    = model.selection
	view = model.active_view 
	names = Regexp.union(args)
	matches = defs.find_all{|d| d.name =~ names }
	model.start_operation('Explode Inards')
	matches.each{|match| 
     match.instances.each{|i|
		sel.add(i)
		view.refresh
		sleep 0.2
		i.explode
		}
	}
  defs.purge_unused
  model.commit_operation #
end

to run

explode_named("Sophie","Chris")

john

[TNTDAVID]

Really perfect your solution driven!

Thank you

[TNTDAVID]

**Dirven, I chose to use your method that works well.

When components are exploded with dynamic materials, the textures will apply to the basic geometry.

Thus the rendering engines can easily manage the maping coordinates to make beautiful 3D renderings.

In the case of Click-Cuisine 2:

Each piece of furniture can contain between 10 and 50 components to explode, so for a kitchen with 25 modules it takes 2 minutes of loading.

I set the value "sleep", to "0" to go faster but that is insufficient.

Is it possible to execute code faster or activate the SketchUp progress bar?

Thank you**

[driven]

it's basically TIG's code + a couple of tweaks, I made it 'visualised' to help you 'see' what's happening because I find it useful myself...

none of these are needed at all and the code will run faster...

      sel.add(i)
      view.refresh
      sleep 0.2

so either comment them out or delete them for 'production code'...

any 'progress bar' will add even more overhead and can only slow the progress more...

john

[TNTDAVID]

The loading time decreased from 2 minutes to 4 seconds.

Thanks Driven