All, David,
It may just be me, and pardon me for being frank, but IMHO paths are a
little off. Although in some cases it works very well, and the
behavior is expected. In other cases, I'm getting a lot of
"unexpected" behavior. I know pathing is in its infancy, but there's
a number of issues that I'm running into.
To start off I have some questions...some of these are just to
understand what the potentials of this might be.
1. Are paths considered, or are they planned to be, 1 dimensional, 2
dimensional, or N-dimensional?
2. Could paths be nested within other paths, or a jagged path
structure?
3. Is there any plan to have components output paths in multiple ways?
(ie its not a "this path" or "flat" situation, but a number of
different pathing structures that could be created by a given
component...ie I could think of 4-5 different ways to path the output
of the Divide Surface component)
4. Is there any plan to have alternate data matching schemes that
could honor (in some way) the incoming path structure.
5. Is there a way to acknowledge separate inputs to a given node as
being two separate paths (right now it does not look like this is the
case)?
6. Will there be any means for coding components (VB.NET, C++,
Python?) to take pathing into account when data is outputted?
Ultimately, I have have the following observations about paths
1. The inability to create paths is severely limiting. Right now the
pathing structure is whatever gets kicked out of components, and that
pathing structure may not be what is needed. Even just 1d paths for
now would be a great addition.
2. The output of the paths at this point is somewhat clunky. Right
now I'm getting what looks like 1 dimensional paths from some
components and what look to be two dimensional paths from another
component. I'm even seeing one that looks 3 dimensional now?!
3. I have no idea what the Decompose Branch and the Create Branch
components do. It seams all they do is take in or spit out an integer
or an integer with a Path{n} around it. Again, if I'm missing
something on how they need to be used then let me know.
4. The post it notes need to have some representation of the paths
that a given data is associated with. I use the post it notes all the
time to visualize raw data, and since paths look like they're going to
be the wave of the future, it would be something that would make sense
to have that data in there as opposed to having to bring in a path
viewer component and count items to see exactly with path it falls
under.
5. I think one unified way of getting any data out of trees would be a
nice addition to the ones that are already there. This means that the
extraction of the data would have to be interpreted from the syntax of
what data you want, but I think that the syntax could accommodate
that. I'm not 100% sure about this one, and maybe its the programmer
in me speaking out, but it seams like I could get what I want much
faster by typing some numbers in a special syntax rather than
assembling a bunch of additional components just to get a very
particular piece of data out of a path.
6. I can very much see the need to swap paths (path A for path B),
reverse paths (A,B,C is now C,B,A...but the data within A is the same
order), split paths into separate streams (A,B,C,D -> A,B | C,D),
merge paths via index (A,B,C,D with supplied index of 1,3 would merge
to A, E, C where E is B and C merged together), Append either branches
to a path structure or data to a branch, Weave Branches. A number of
those I could see being achievable with a few additional tools, but at
the expense of taking 2-5 additional components to put together.
I believe there is one bug that I've found relating to pathing. The
Tree Branch component won't accept the "two dimensional" paths, even
though it has a "two-dimensional" structure fed into it. Note: I
didn't have a problem with this in 6.001
I'm sorry if I seam harsh, and again, I'm sorry if I'm just not
getting it. I know this was a lot of work, and required changes
across the board. I also know that this is young at the moment, so it
needs some time to grow. Ideally, this is feature that could make
Grasshopper even more of a powerhouse than it already is, and could
really put things over the top in terms of what's achievable
(...without scripting). Right now, I'm just not seeing that, and I'd
like to get it progressing towards a "better place". I think the sign
as to when pathing is solid is when the Flatten Tree component can be
taken out. If there's enough tools to deal with paths and components
can accommodate different pathing structure, both with inputs and
outputs.
Best,
Damien
