Grasshopper

algorithmic modeling for Rhino

What is the strategy towards baking geometry in Gh 2?

Will we still rely on Giulio, will there be a native component, or will there be a more advanced implementation in the FriedEgg? How about the role of object attributes and things like auto-naming of layers in this?

Views: 400

Replies to This Discussion

The idea now is that baking (and previewing) options will be handled by custom data. All data items have the ability to carry a dictionary of key-value pairs along with them, which allows users to associate certain values with each datum.

So let's say you have two breps and you assign "Building='A'" to one and "Building='B'" to another. The "Building" key is something you make up and nobody except you knows what it means. You then contour these breps giving you floor outlines. All the contours that result from the first brep will also receive the "Building='A'" custom data, and the contour curves that result from the second brep will be marked 'B'.

You can add additional custom data entries to all the contour curves, say "Preview.Thickness=3" and "Preview.Colour=Maroon". When these curves are previewed, they will be drawn with a thickness of 3 pixels and (if unselected) in maroon.

You will also be able to add entries that look like "Bake.Layer='Floors_A'", or maybe even "Bake.Layer='Floor_{Building}'" (the curly brackets indicate a placeholder, or lookup in the custom data dictionary).

When a bake operation starts, it will look in the custom data dictionary (if one is associated with a piece of geometry) and try to harvest property overrides from it. Layer, colour, print width, name, dash-pattern, ... the list goes on.

Custom data is basically a vehicle for adding functionality to all sorts of operations. Previewing and baking are two, but sectioning, exporting, analysis, bill-of-material population, scheduling are others that sound useful. Grasshopper will define a bunch of keys that have a preset meaning, but anyone can use any key they want.

Major benefits of this approach are that there can be a single unified UI for assigning, validating and removing custom data, that large amounts of custom data can be added without the need to reserve memory for when that data is not needed, and that it's always possible to invent more keys later without breaking the SDK.

Interesting. Sounds like an ocean of possibilities.

How would I keep track of the assigned custom data? Can I access this dictionary and e.g. find spelling mistakes or display the affected components?

I haven't gotten to the UI part yet, so far I've only finished the bookkeeping classes that keep custom data and grasshopper data synchronous. But it will have to be very easy to inspect custom data, both as a textual document and maybe even in the viewport. Perhaps I can add display filter so only those items that match a specific key-value are previewed. It really is an ocean of possibilities and I suspect the hard part will be to not go overboard...

Looking forward to swim. Thanks! p

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