[Code] material.delete

thomthom

You don't need to dig into the nesting.

Simplified example:


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)


+ 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:


+ 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

@thomthom said:

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 http://forums.sketchucation.com/viewtopic.php?p=166978#p166978

thomthom

@tig said:

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

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

@tig said:

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

@unknownuser said:

...
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

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

TIG

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

TIG

Use v1.2: fixed an array bug.
http://forums.sketchucation.com/viewtopic.php?p=166978#p166978