Grasshopper

algorithmic modeling for Rhino

Hello,

I am trying to write a component that for example takes in a shape (a primitive for now) and outputs the GUID of all the same within Rhino that have the same physical properties (length, width, height, or radius, etc) as that shape.

Intrinsic matching would be the best (the shapes can be rotated and would still be matched).

The closest thing I can find is comparegeometry in Rhinoscript but then the two shapes have to be on top of each other.

Thanks!

Tim

Views: 2431

Replies to This Discussion

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

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?

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.

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:

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.

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?

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service