Differences
This shows you the differences between two versions of the page.
|
labs:explicithistory:datastreammatchingalgorithms [2015/10/28] |
labs:explicithistory:datastreammatchingalgorithms [2020/08/14] (current) |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== Grasshopper Data Stream Matching ====== | ||
| + | |||
| + | | {{: | ||
| + | | [[http:// | ||
| + | |||
| + | ---- | ||
| + | |||
| + | > **Summary: | ||
| + | |||
| + | \\ | ||
| + | |||
| + | ===== Data matching===== | ||
| + | |||
| + | Data matching is a problem without a clean solution. It occurs when a component has access to different sized inputs. Imagine a component which creates line segments between points. It will have two input parameters which both supply point coordinates (Stream A and Stream B). It is irrelevant where these parameters collect their data from. A component cannot //see// beyond its input and output parameters: | ||
| + | |||
| + | \\ | ||
| + | |||
| + | {{: | ||
| + | |||
| + | \\ | ||
| + | |||
| + | As you can see there are different ways to draw lines between these sets of points. The Explicit History plug-in currently supports three matching algorithms, but many more are possible. The simplest way is to connect the inputs one-on-one until one of the streams runs dry. This is called the //Shortest List// algorithm: | ||
| + | |||
| + | \\ | ||
| + | |||
| + | {{: | ||
| + | |||
| + | \\ | ||
| + | \\ | ||
| + | |||
| + | The //Longest List// algorithm keeps connecting inputs until all streams run dry. This is the default behavior for components: | ||
| + | |||
| + | \\ | ||
| + | |||
| + | {{: | ||
| + | |||
| + | \\ | ||
| + | \\ | ||
| + | |||
| + | Finally, the //Cross Reference// method makes all possible connections: | ||
| + | |||
| + | \\ | ||
| + | |||
| + | {{: | ||
| + | |||
| + | \\ | ||
| + | \\ | ||
| + | |||
| + | This is potentially dangerous since the output amount can be humongous. The problem becomes more intricate with more input parameters and when the volatile data inheritance starts to multiply data, but the logic remains the same. | ||
| + | |||
| + | Imagine we have a point component which inherits its x, y, and z values from remote parameters which contain the following data: | ||
| + | |||
| + | \\ | ||
| + | |||
| + | X coordinate: {0.0, 1.0, 2.0, 3.0, 4.0, 5.0, 6.0, 7.0, 8.0, 9.0} | ||
| + | |||
| + | Y coordinate: {0.0, 1.0, 2.0, 3.0, 4.0} | ||
| + | |||
| + | Z coordinate: {0.0, 1.0} | ||
| + | |||
| + | \\ | ||
| + | |||
| + | {{: | ||
| + | |||
| + | \\ | ||
| + | \\ | ||
| + | |||
| + | If we combine this data in the //Shortest List// fashion, we get only two points since the //Z coordinate// | ||
| + | |||
| + | \\ | ||
| + | |||
| + | | {{: | ||
| + | |||
| + | \\ | ||
| + | \\ | ||
| + | |||
| + | The //Longest List// algorithm will create ten points, recycling the highest possible values of the Y and Z streams: | ||
| + | |||
| + | \\ | ||
| + | |||
| + | | {{: | ||
| + | |||
| + | \\ | ||
| + | \\ | ||
| + | |||
| + | //Cross Reference// will connect all values in X with all values in Y and Z, resulting in 10×5×2 = a hundred points: | ||
| + | |||
| + | \\ | ||
| + | |||
| + | | {{: | ||
| + | |||
| + | \\ | ||
| + | \\ | ||
| + | |||
| + | Every component can be set to obey one of these rules. (The setting is available in the menu.) | ||
| + | |||
| + | \\ | ||
| + | |||
| + | Note the one big exception to this behavior: Some components **expect** to get a list of data in one or more of their input fields. The polyline component, for example, creates a polyline curve through an array of input points. More points in the input parameter result in a longer polyline, not in more polylines. Input parameters which are expected to yield more than one value are called List Parameters. They are ignored during data matching. | ||
| + | |||
| + | |||
