Data Trees and Nulls / Wish

Replies to This Discussion

Permalink Reply by Danny Boyes on April 25, 2012 at 6:17am

I think you have a good point. I too have wondered the same. Especially when Clean Tree will do the same job when you need to get rid of nulls and empty branches.

Permalink Reply by David Rutten on April 26, 2012 at 10:27am

The fact that nulls and results end up in different path lengths is a bug. It's a biggie and I'm trying to fix it for 0.9

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Andrew Heumann on April 26, 2012 at 8:33pm

while we're on the topic of weird path behavior... offset puts curves with an offset of 0 in {A} and all others in {A;B}

Permalink Reply by Richard Schaffranek on May 22, 2012 at 11:32am

Will Datatree behaviour be reworked in general?

There are other inconsistencies:

transforming  a empoty list will produce a null item

crafting a datatree with empty lists will erase the list with the path

or:

Datatree a: {0;0}, {1;0}, {1;1}, ....

Datatree b: {1;0}, {1;1}, ....

Components will match 

a:{0;0} with b:{1;0}

a:{1;0} with b:{1;1}

?

Permalink Reply by David Rutten on May 22, 2012 at 1:00pm

Hi Richard,

I'm trying to rework the logic that invents new tree paths when a component operates on input that does not have identical data tree layout. It sounds like "transforming a[n] [empty] list will produce a null item" is a bug that may or may not already have been solved. Please post a file for me to test this.

There will be no change in 0.9.0001 concerning the order in which paths are combined. This is in fact not part of the work I've been doing, which focuses solely on how to label outputs, rather than how to decide which inputs belong together. This is something that needs a lot (and I do mean a lot) of thought because it's a wildly complex issue which nevertheless needs a relatively easy to use interface.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Richard Schaffranek on May 22, 2012 at 3:15pm

Hallo David,

I can see that the matching needs a lot of thought, but at the moment it's simply not consistant throught Grasshopper which makes it especially hard to teach to students.

It would be nice to come up with some guidlines, how plugin developers should deal with this topic.

I made a little sample file demonstrating the issues that I am reffering to.

The idea is that a set of points gets sorted according to another set of predefined hights -> this might generate empty lists for certain hights...

thx

Richard

Attachments:

• inconsistency sample.gh, 6 KB

Permalink Reply by Andrew Heumann on May 22, 2012 at 5:02pm

Hopefully this is something that's already addressed by David's work on 0.9 - but in the meantime, here's a workaround that I've used successfully in the past. It works by forcing the addition of a null to the empty list, using a simple empty scripting component to generate a null item. 

Attachments:

• inconsistency_workaround.gh, 12 KB

Permalink Reply by David Rutten on May 23, 2012 at 12:53am

Hi Richard,

what do you think should be the default behaviour in this case then:

DataTree a: {0;0}, {1;0}, {1;1}

DataTree b: {1;0}, {1;1}, {1;2}

Should I ignore all data inside a{0;0} and b{1;2} because they don't have a matching sibling in the opposite tree? What happens when no paths match up, for example when you have this:

DataTree a: {0;0}, {1;0}, {1;1}

DataTree b: {1;0}, {1;1}, {1;2}

DataTree c: {0}

We need to keep the number of times people have to use Simplify, Graft, Flatten or PathMapper to an absolute minimum and if I start discarding data because it is not formatted exactly right I fear that people will need to 'fix' their data more often than now.

--

David Rutten

david@mcneel.com

Poprad, Slovakia 

Permalink Reply by Richard Schaffranek on May 23, 2012 at 1:22am

Hallo David,

As you said this is not so easy to answer.

One possability could be, to only match pathes with with same indicies. This would make the matching more logic, at least to me.

The question is how often the second example occurs? But here again:

a:{1;0},b:{1;0},c{0}

a:{1;1},b:{1;1},c{0}

This would also have some logic since c is a simple list, again at least for me.

But the problem only occurs because the different components handle datatrees differently as demonstrated in the provided sample. When there is an empty list in a datatree and I craft this datatree the empty list disappears. This is a problem because it makes it hard to keep two lists synchrone over many components. 

Permalink Reply by David Rutten on May 23, 2012 at 2:10am

When there is an empty list in a datatree and I craft this datatree the empty list disappears.

I'm fixing this as we speak. 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Danny Boyes on May 23, 2012 at 2:17am

[Thinking out loud (oh the pain)]

Data Structure should have precedents over Path Structure if there is a match.

For example:

10 Curves on 2 Branches {0;0;0;1;0}(N=5) {0;0;0;2;0}(N=5)

should match with

10 Curves on 2 Branches {9;0;0;0}(N=5) {10;0;0;0}(N=5)

.....

Failing Data match Path Matching should be employed

 

 

Permalink Reply by phillip on May 23, 2012 at 2:37am

I´d rather pre-use a replace branch in this case and have strict consistency in PathStructure. This way you could also match

DataTree a: {0;1} , {1;1}

with

DataTree b: {0;1;0}, {0;1;1},{1;1;5},{1;1;9}

and still get

DataTree c: {0;1;0}, {0;1;1},{1;1;5},{1;1;9}

because it would recognise b is a subbranch of a

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page