REQUEST: Simplify behaviour change

Replies to This Discussion

Permalink Reply by David Rutten on October 9, 2012 at 4:56pm

What needs to happen when you have a single path that's like {0;1;4}?

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Marc Syp on October 9, 2012 at 4:59pm

Hm.  Yes, I could see this being an issue in some situations.

Perhaps it could be a context menu option to "Flatten single paths"?  Ideally you'd be able to set the behavior on a right click input or output, but perhaps it's only available in the component version.  Much like the "Limit to front" option. 

Marc

Permalink Reply by Marc Syp on October 9, 2012 at 5:23pm

After some more thinking...  you know, keeping the path structure intact for a single path is rarely going to be useful, in my estimation. There might be some cases where it does make sense, but typically you are using a Simplify operation because of a path matching problem downstream.  Often it is to match the data from the same source that has undergone a different number of operations.

If you have similar path structures (single paths on both streams of components being simplified), then both simplify operations will fail to condense the path structure, and you will continue to have a mismatch.  If you have a larger path structure trying to work with a smaller subset of paths, you have the same problem.  For instance:

Stream 1:

{0;0;0;0}

{0;0;1;0}

{0;1;0;0}

{0;1;1;0}

Stream 2:

{0;1;0}

The goal is to match the third branch with the single branch.  If you simplify both streams, you get:

{0;0}

{0;1}

{1;0}

{1;1}

and 

{0;1;0}

This is still a data matching problem, no?

Flattening is not always going to work either... so I don't really know what the answer is.  I just know that more often than not, I end up needing those longer paths to just flatten to {0} for everything to work.  Why not use flatten in the first place?  Because the same structures need to be able to deal with multiple paths where a simplify is necessary for data matching.

Sorry for all the thinking out loud here...

Permalink Reply by David Rutten on October 10, 2012 at 6:18am

So there's a number of options for simplifying trees with only a single path. These are the ones that I can imagine making sense:

1. Simplify to {0}, always.
2. Simplify to {x}, where x is the lowest of all numbers in the original path
3. Simplify to {x}, where x is the first of all numbers in the original path
4. Simplify to {x}, where x is the last of all numbers in the original path
5. Simplify to {x}, where x is the rounded average of all numbers in the original path
6. Simplify to {x}, where x is the median of all numbers in the original path, with preference given to lower numbers in case of collision.

Personally I think [1] and [4] are the best ones, mostly because they are completely predictable. 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Marc Syp on October 10, 2012 at 10:44am

I would vote for #1.  

Additionally, how about this idea:

In the simplify component, you could provide an input for "Reference Paths".  This would give the simplify operation the context it needs to make the decision.  For instance, in my previous example, I might have extracted a single branch {0;1;0} from a larger subset of branches.  

I can go back to the source, connect a parameter viewer to the source, and connect the output to the reference path input.  So the inputs would look like this:

Data: Path {0;1;0}

Reference Paths: {0;0;0}, {0;0;1}, {0;1;0}, {0;1;1}

This tells the simplify component to simplify to {1;0}, thereby matching the original third path in the parallel stream.

I don't think the reference paths would solve all of the workarounds, but in addition to the "flatten single paths" (if no reference paths are present), I think you could cover almost everything.

Marc

Permalink Reply by Andrew Heumann on October 10, 2012 at 11:05am

A slight variation on this might be a simplify component with a ZUI to accept N sets of paths - the simplify logic would look at all the paths at once, but simplify them as separate streams. 

Permalink Reply by Marc Syp on October 10, 2012 at 11:22am

I like the idea... but in the previous example I gave... how does the component handle trees with different length branches?  I.e., how does it know that 0;1;0 aligns with 0;0;1;0 and not 0;1;0;0?  Is there a hard and fast rule that works every time?

Permalink Reply by Andrew Heumann on October 10, 2012 at 11:37am

The above would work well for situations in which all the input paths have the same number of indices. It might be nice to also provide a component which could attempt to reconcile paths of different lengths, with a set of possible algorithms to perform the matching. 

Stream 1: {0;0;0} {0;0;1} {0;1;0} {0;1;1} {0;1;2}

Stream 2: {0;0} {0;1}

"trim end" and "trim start" matching could be applied between the paths - applying either an {A;B;C} -> {A;B} mapping to stream one, or {A;B;C} -> {A;B}.

In a more complex situation:

Stream 1: {0;0;0} {0;0;1} {0;1;0} {0;1;1} {0;2;0} {0;2;1}{0;2;2}{0;2;3}

Stream 2: {0} {1} {2}

Stream 3: {0;0;0;0} {0;0;1;0}{0;0;1;1} {0;0;1;2} {0;0;2;0}

This could conceivably include all kinds of ambiguous cases, but here's a stab at an algorithm that might sort them appropriately most of the time:

Find the highest value for each path index in each stream - so 1 has {0;2;3}, 2 has {2} and 3 has {0;0;2;2}

Find the shortest path length N across all paths - in this case N=1

find the highest (leftmost) shared pattern of N sequential values across all paths (here just {2})

Simplify all streams to the matching set of indices. (Stream 1: {A;B;C} -> {B}, Stream 2 {A} -> {A}, Stream 3: {A;B;C;D} -> {C})

Not sure if this makes sense - (either because I've explained it poorly or because the idea itself is bad.) But hopefully at least the goal is clear - to find a most-of-the-time routine to reconcile paths of different lengths according to their overlap. 

Permalink Reply by Andrew Heumann on October 10, 2012 at 11:44am

the second algorithm, in hindsight, doesn't work in cases where you've extracted a branch from a tree and want to fold it back in, as in your example, but "trim start" would work. 

Permalink Reply by Marc Syp on October 10, 2012 at 5:15pm

Actually, I think this is genius but beyond the scope of the simplify component.  This would actually accomplish a combination of Simplify and Path Shift operations, and I could see it being useful all the time.  

I would, however, request an entirely new component for this, in addition to the Simplify + Path Shift components, at least until they're proven redundant.

Incidentally, what happens if there is no common denominator?  I.e., Stream 2 is {5} {6} {7}?

Permalink Reply by Andrew Heumann on October 10, 2012 at 11:29pm

then you're SOL!