Find and replace geometry in GH

Replies to This Discussion

Permalink Reply by David Rutten on October 1, 2014 at 1:18am

You're going to have to write the comparer yourself. I assume you're working only with breps? It will be diffucult to get an exact match, but you can probably get close by testing volumes, edge lengths, face counts, face types (flat, trimmed, closed, etc).

Permalink Reply by Tim Chen on October 1, 2014 at 1:41am

Hey, thanks for replying. Yeah only with closed breps. Is there a method that outputs all breps within the opened file?

And for the replacing part of the code. Is there local reference point for each brep that I can use?

Permalink Reply by David Rutten on October 1, 2014 at 7:25am

You can use the Geometry Pipeline to import all breps (there are also layer and name filters if you want).

Rhino objects (with the exception of block instances) do not contain local reference planes. However if the breps are geometrically the same you should be able to construct such a plane from brep vertices, or maybe brepface frames.

Permalink Reply by Tim Chen on October 1, 2014 at 8:38am

The Geometry Pipeline works great, thanks! Sorry about all these basic questions, but from what you suggested above, I could only get the volumes of closed polysurfaces. I can't find the functions to extract the other information anywhere (within Rhino Python anyway). I suppose I could get the face counts if I unroll the object and count the length of the list, but is there functions that extract all those information?

My eventual goal is to create a 3-D spatial grammar interpreter in GH, which basically follows the procedure below.
So the old and the new geometries may be completely different, so I need some sort of an anchor to know where to place the new shape inrelation to the old shape.

Dont know if I should create a new post on this, but just wondering if anyone has ideas on how to implement those two components basically (should I script it, or learn how to use the SDK as well, when I couldn't even understand this : http://www.grasshopper3d.com/forum/topics/difference-between-gh-pyt...)

Attachments:

• c.png, 749 KB

Permalink Reply by David Rutten on October 1, 2014 at 11:28am

If you're going to work with Rhino objects instead of Grasshopper geometry, why not just create a Rhino plugin instead? It seems like going the long way around to modify geometry in the Rhino document using Grasshopper components.

You're still going to have to solve the problem of a frame. I think each of your core grammar types needs to have consistent frame associated with it, but you're going to have to define these and then figure out how to interpret that from any given brep. Note that the faces, edges and vertices in a brep can come in any order, so you cannot rely on a fixed index.

Things become somewhat easier if you can assume that shapes are always oriented in a specific way. Are boxes always upright, or can they be tilted as well?

Either way this sounds like a very complicated programmatic issue, I think your best approach is to create a dll in Visual Studio which references RhinoCommon and which does all the heavy lifting. You can then import this dll in either Rhino plugins or Grasshopper components. This approach divorces your core logic from the GHA and RHP plugin frameworks, which probably makes it easier to talk about specific problems.

Permalink Reply by Tim Chen on October 2, 2014 at 3:11am

Hey David, thanks for the advice.

Actually if I could, I would like to keep everything in GH. My intention is to use the generated shape as a starting geometry for analysis (again within GH).

Yeah, you are right. It would be a lot easier if Rhino is a primitive modeller (like Solidworks), then I can just get the attributes like height, width, length.

The shapes are not always upright, the intention is to make the orientation (and size) parametric, and have the search to be parametric too...

Like it would be really cool to see your search results change as you adjust the slider (of height for example) in a row of prisms of different heights.

To complicate the matter further, the search algorithm maybe extended to account for the emergence of shapes too. So if two cubes are adjacent to one another, the search shape could be two cubes, or one larger prism that has the same overall size as the two cubes.

That's why, I thought, to simplify the search, I may just search for the id instead of matching the actual shape.

This is so that automated design generation becomes rule based and not procedural (like hoopsnake, though to loop through the different rules, hoopsnake is probably gonna be used).

Do you think the pay-off is worth the effort? or is it feasible to implement this in GH?