[Code] material.delete

[TIG]

This adds a new Method to Sketchup's Material Class - 'delete'
Usage: material.delete
It changes any entities use that material to the default-material, and then removes that material from the model and the materials-browser.
It has been streamlined as much as possible but will search potentially thousands of entities to remove that material...
Edit:
v1.1 has simplified defn changing and respond_to? material test - thanks to thomthom.
v1.2 materials made into array to remove self.
v1.3 empty temp groups used without detriment.
v1.4 operation removed as it should be used with another one.

material-delete.rb

[thomthom]

If read the code right, you iterate all the entities of each component instance and group?
A quicker way would be to just run over the entities in the model.definitions collection and then the model.entities.

[TIG]

It has to deal with nested groups and instances etc... It processes every instance as each could have different materials, if it hasn't processed an instance's definition (i.e. it's not in @done) it does that too, otherwise it skips it... Not sure if the other way'd be quicker ?

[thomthom]

You don't need to dig into the nesting.

Simplified example:

Code: Select all

model.entities.each { |e| e.material = nil if e.respond_to? :material }
model.definitions.each { |d|
    d.entities.each { |e| e.material = nil if e.respond_to? :material }
}


This will strip the material of ALL entities that has a material property. Including the materials applied to ComponentInstances and Groups. No need to keep track of which definitions has already been processed. (of course, back_material will have to be accounted for.

Other notes: won't your version choke if it runs into entities that doesn't have material property?

And would it be quicker if the dummy geometry was a single edge instead of a face (four edges and a face)? Or even just empty dummy groups?

[thomthom]

Just to illustrate with some high-tech ASCII art:

If you have a model with a entity tree like this: (Excluding edges)

Code: Select all

+ Model
+ model.entities
| Face1
| Face2
| Face3
| Group1 [Def1]
+--+ Face4
|  | Face5
|  | Instance3 [Def3]
|  +--+ Face7
|     | Face8
|     | Face9
| Group2 [Def1]
+--+ Face4
|  | Face5
|  | Instance3 [Def3]
|  +--+ Face7
|     | Face8
|     | Face9
| Group3 [Def2]
+--| Face6
| Instance1 [Def3]
+--| Face7
|  | Face8
|  | Face9
| Instance2 [Def3]
+--| Face7
   | Face8
   | Face9


The you can see how you get all entities when you loop over model.entities. and model.definitions...entities:

Code: Select all

+ model.entities
| Face1
| Face2
| Face3
| Group1 [Def1]
| Group2 [Def1]
| Group3 [Def2]
| Instance1 [Def3]
| Instance2 [Def3]

+ model.definitions
+--+ Def1.entities
|  | Face4
|  | Face5
|  | Instance3 [Def3]
|
+--+ Def2.entities
|  | Face6
|
+--+ Def3.entities
   | Face7
   | Face8
   | Face9


[thomthom]

Where does the face.copy method derive from? I can't find it in the API docs.


The self_to_nil method, is that embedded in .delete? Local to that method only? Never seen that method nesting before. Didn't even know it was possible. Feels very much like Javascript that way.

[TIG]

Where does the face.copy method derive from? I can't find it in the API docs.
The self_to_nil method, is that embedded in .delete? Local to that method only? Never seen that method nesting before. Didn't even know it was possible. Feels very much like Javascript that way.

The 'face.copy' is simply 'group.copy' - the group was called 'face' !!!
You can embed a def locally within another def - useful if you want to 'loop until' etc.

Having taken on board your comments I have tweaked the method... here's the updated one viewtopic.php?p=166978#p166978

[thomthom]

The 'face.copy' is simply 'group.copy' - the group was called 'face' !!!

Ah. didn't see that. Thought it maybe wes undocumented.

You can embed a def locally within another def - useful if you want to 'loop until' etc.

That sure is. Will have to remember that.

I think this method, and the layer version would fit well into the Skx library. Would you mind if this was included? I can add it to the repository for you if you don't want to bother with setting up Mercurial.

[thomthom]

Just had a though. What happens if this method is called from another method that already has done a model.start_operation?

can operations be nested? Or will it interrupt the previous? Maybe one of the transparency flags (SU7 only) can be used?

[Jim]

That's a good point, Thom. I'm not sure start_operation belongs in specific methods.

I asked somewhere here if nesting start_operations was allowed, or what happens if they are nested. It's possible to write some "guards" for start_operation that prevent nesting - which may be interesting to do just to see what is really happening with all the scripts you have already installed.

[thomthom]

I'm wondering if trans or prev_trans flag can be used to inject these types of methods. But I don't fully understand the difference between the two. And I'm also unsure of the warning for trans apply to prev_trans.

[TIG]

...
I think this method, and the layer version would fit well into the Skx library. Would you mind if this was included? I can add it to the repository for you if you don't want to bother with setting up Mercurial.

Please add them for me...

[TIG]

As Jim says, perhaps best to remove the start/commit_operations unless 'we' can work out how best to 'transparencify' them... Advice welcome...

[thomthom]

Ok. I'll add it to the Skx. Thanks for sharing the snippet.

After this week I'll have some time to do some experiment with start operation. It'd be interesting if we could find a best practice.

[TIG]

Use v1.2: fixed an array bug.
viewtopic.php?p=166978#p166978

[TIG]

v1.3 now uses empty temp groups without detriment and so must be a little quicker too ... viewtopic.php?p=166985#p166985

[TIG]

v1.4 - now has operation properly removed ! ... viewtopic.php?p=166985#p166985