Similar Group Finder - Script beginning needs testing

Chris Fullmer

Hey, after a quick back and forth about this with Thom, I decided to sit and try to write this script. As the name implies, this script looks at all groups (not components) in a model (or at the selection if entities are selected). It finds all groups, and then compares them to eachother to determine if any are identical, and should therefore be turned into a simgle component. It labels all similar groups with numbers. So all groups labeled with a 0 are all found to be similar, 1's are then all similar to eachother, etc.

This is JUST A START at the script. It only finds similar groups. It does not take them and turn them all into a single component and instances - yet!

It is still farily easy to trick the script, but I'll let you figure out how.

This is what it compares:

Total amount of entities within the groups
Total amount of Edges within the groups
Total amount of Faces within the groups
Combined length of all edges within the group
Lengths of each edge, one by one in the groups

It ignores any sub groups/components inside the groups being compared. It does not take materials into account yet. It could also compare face areas, but SU does not compare faces areas very well (thanks to Thom for pointing that out!). It also does not attempt to account for component scaling, and I think I can get it to test for similar groups that are merely scaled differently.

The next phase is to figure out how to orient the groups so they are comparable in rotation. Then I could do more testing on geometry location, which will be inevitabely nececssary I think.

Enough already, if anyone wants to test it out, please do. I'll try to update things as we find them. And eventually I'll need to work out the group orientation issues.

Chris

v0.1 - TEST code

thomthom

Regarding comparing Face.area - it works fine as long as you give it a little tolerance. (Should be done when comparing all float values.)


# Compare two floats with some tolerance. (Thanks jeff99)
def self.floats_equal?(float1, float2, epsilon = 0.00000001)
  return ((float1 - float2).abs < epsilon) ? true ; false
end

I'll have a look at this script later. It's interesting. I often get Revit models where identical windows are present, just with different names. Some times the axis points the opposite direction, some times they are identical.

Chris Fullmer

Thom, when you import a revit file, do the SU group bounding boxes align to the orientation of group? Or do they align to the SU world axes?

For example, if you import a box, regular flat on the ground box. And a copy of it in revit, but in revit it was rotated in all direction so it is sitting on a single point. In SU, do the boxes axes align to the box or to the model? I had assumed it would align to the model, meaning that I would have to figure out how to re-align their axes on my own.

But if the axes come in aligned to the box, then that might help immensely.

Chris

BTW, anyone have a real life model I could test? Some times simple-ish. Not too simple, but no Taj Mahal

thomthom

The Revit import only contains Components. Not blocks. And the axis fit the object.

Chris Fullmer

That's fascinating. They are already components. Do they come in as components and instances where possible then?

I know autocad brings in blocks as components and instances. So if CAD and Revit do this already, what is the main sue for this script? Groups makers who realize later they want all their groups to be a single component and instance?

Chris

thomthom

@chris fullmer said:

That's fascinating. They are already components. Do they come in as components and instances where possible then?

I know autocad brings in blocks as components and instances. So if CAD and Revit do this already, what is the main sue for this script? Groups makers who realize later they want all their groups to be a single component and instance?

Chris

Yea, some come in as instances of each other. But there seem to be some time when they don't. Like when a window is mirrored in Revit, those windows doesn't come in mirrored in SU - but as a component type of their own. Small changes like that.
That's if you go Revit->DWG->SU

If you go Revit->FBX->3DS->SU I think all objects comes in a unique objects - all with origin in the model origin.

Chris Fullmer

Ahh, I see. I'll poke around at the .3ds format and see if it is supporting import of components and instances at all. I kind of doubt that it is.

Chris

thomthom

@chris fullmer said:

Ahh, I see. I'll poke around at the .3ds format and see if it is supporting import of components and instances at all. I kind of doubt that it is.

Chris

It does.

thomthom

Though, it has had issues - not sure if they have been fixed. http://forums.sketchucation.com/viewtopic.php?f=11&t=12272

RunnerPack

This is a very cool idea for a plug-in! I've thought of it myself, of course (most people who've worked with SU for very long probably have) but then thought of how hard it would be to write (and how slow it would probably run on my ancient PC ).

But, I'm very glad to see the gauntlet has been taken up - especially by someone as talented at plug-in writing as Chris F.

I have been studying the transformations of Groups and the geometry inside for a plug-in I'm making, so I may have something to add to this in later stages (though I'm terrible at math).

Thom:

Not to criticize your coding style or Ruby skills (or those of "jeff99"), but I thought I'd point out that, in Ruby, both the "return" statement and the trinary conditional are technically superfluous, in this case.

Since the condition itself evaluates to either 'true' or 'false', and since Ruby returns the value of the last statement as the method's value, the entire contents of the method could be simply:

# Compare two floats with some tolerance. (Thanks jeff99 and thomthom)
def self.floats_equal?(float1, float2, epsilon = 0.00000001)
  ((float1 - float2).abs < epsilon)
end

(One could also make it easier to use by overriding the === [triple equals] method for floats, but I don't know what the consequences of this would be. Maybe a '====' method, instead?)

I don't know what impact, if any, this would have on the speed of a plug-in, but one like Chris' would be doing a lot of these...

Also, is that a loose enough tolerance for this usage? I suppose it would depend on the scale and level-of-detail of each model.

Well, I'll stop wasting everyone's time now

thomthom

@runnerpack said:

Not to criticize your coding style or Ruby skills (or those of "jeff99"), but I thought I'd point out that, in Ruby, both the "return" statement and the trinary conditional are technically superfluous, in this case.

hm.. good point about the trinary - not sure why it's even there.

As for the return keyword - I prefer to use them as I read my code better when I see an explicit return statement. All though for such a short method it could be skipped, but you know old habits and all.
But thanks for mentioning it. Since I picked up Ruby I've changed my coding style a few times as I've learned more about the language.

thomthom

@runnerpack said:

(One could also make it easier to use by overriding the === [triple equals] method for floats, but I don't know what the consequences of this would be. Maybe a '====' method, instead?)

Seeing how there's so many that develop plugin for Sketchup, I'm avoiding extending base classes to avoid potential conflicts. Had it been in a isolated environment where only I coded I'd extend them. (I often want to, but I play it safe.)

TIG

I use...

class Float
	def =~(num2,tol=10000)
		num1=(self*tol).to_i
		num2=(num2*tol).to_i
		return true if num1==num2
		return nil
	end
end #class Float