Grasshopper

algorithmic modeling for Rhino

Data Structure - Adapting definitions to varied branch structure:

I am configuring a definition that has variable data tree structure.

Is there a way of inserting dummy branches so that the structure will stay the same?

Is there a way of pulling the path mapping down to one branch without simplifying? 

I have tried a definition that does map down to one branch, however if there is only one type of element it will separate elements into branches, and will not mark the branch as {0}, rather split the group (branch into constituent parts). {0}{1}{2} etc will be parts of the whole addressed as if one parent branch.

It seems that grasshopper is'nt really built to do automation that has to go below one object or that might have one object that is unique to others and coding does better, due to the function addressing?

Is there an over riding definition that simplifies and grafts to the original branch structure.

I cant post the definition as it is in a state of flux between updating using many variable path mappers to map in different situations.

Jo

Views: 235

Reply to This

Replies to This Discussion

Andrew's Laws of Adaptable Definitions That Work For All Input Tree Structures:

1. Always operate on your trees *relatively* rather than absolutely. This is the most important rule and the reason for all the other rules.

2. No Flattening! use path shift / trim tree instead of flattening. 

3. No Path Mapper! I have never met a data operation with the path mapper that could not be achieved through relative means. 

4. No Simplify! It makes things *look* nicer but believe it or not those zeros are meaningful and shouldn't just be eliminated. If you are OCD about the way your paths look, then Path shift after every operation that introduces a new branch level (a new "0" at the end) IF AND ONLY IF you are sure that in the case of your definition the component will always function "1 to 1" - that is, for every single input there is only one output.

5. If you absolutely must flatten (to take a global bounds, or generate random values for every item, or whatever) be sure to Unflatten before continuing. 

6. Design for the worst case - start with primary inputs in the most complex data structure your definition is likely to need to be able to handle (a tree for instance) rather than a single item. 

If you follow the above rules, 99% of the time your definitions will respond appropriately to any change in upstream data structure. If you want an example of how this works in practice, post your definition and I can help find "relative" approaches to the "absolute" things you are currently doing. 

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2019   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service