Tree structures, why first 'non simplified' number ? {0;0} {0;1} {0;2}

Hi,
I don’t have a problem.
I just wonder why I sometime get the first “0” in all paths and sometimes I don’t?
I don’t see the reason or purpose for this number?

image

I guess it is to show the object/item is derived from another object?

That additional zero prefix is there because it might be needed when the input gets more complex.

If the boxes going into this component were not stored in a single list under \{0\}, but in two lists \{0\}, \{1\}, then the output needs those zeroes and ones to keep the various lists separate. Because under some conditions this complexity is needed, it is always there lest the topology of trees suddenly changes when the input changes.

2 Likes

okay, but this input is not complex. I can’t see a reason to have this for simple input. Maybe for consistency? Grafting the box list gives the same result but with a zero suffix. I’m trying to think of an example where these prefixes/suffixes with a constant zero values could be used… This is not usefull :face_with_raised_eyebrow::grin::

a shift list or two simplifies are needed :disappointed_relieved:

quick note: you can always use rightclick > simplify on your output to get rid of the leading 0;
edit: just saw you already mentioned it.

Suirify ?
:slight_smile:

It’s not now. It may be tomorrow. So yes, consistency is key here.

1 Like

Note how all four output paths of the Deconstruct Brep component must be different and cannot be simplified without losing information. The function which decides whether or not to prefix that zero always assumes the worst case scenario, so that when that happens, the file doesn’t suddenly behave differently from before.

I know, but thanks :slight_smile:

What’s not usefull is the constant zero prefixes/suffixes when I want to merge two branches and I need to simplify both to make them merge correctly. They should not be there at all in my opinion. Maybe just because I at this moment can’t find an example where the constant zero prefixes/suffixes could be useful.

In other words, I believe that the zero prefixes/suffixes is an inconvenience 98 percent of the time. Though… I respect the consistency argument.

Just a funny idea: Maybe simplify should work in reverse? Auto simplifying (not showing) and then “complexity”.

Auto simplifying is a bad idea. I struggled forever when splitting a branches and the bake component i was using auto simplifies.

So when i had items of

{4;3;5;7}
{4;2;3;7}
{4;3;5;7}

it would remove the first digit… which happened to represent the floor level, so when reconstituting the branching i would get

{3;5;7}
{2;3;7}
{3;5;7}

{4;3;5;7}
{4;2;3;7}
{4;3;5;7}
= 
{4;2;3;7}
{4;3;5;7}
Simplify:
    {2;3}
    {3;5}

but you are right… Extracting specific branches in seperate listes would create huge problems with auto-simplify…

Consistency is the way to go… But I’m still a bit annoyed by the suffix and prefix zeros… :smile:

My auto simplify suggestion only works with some kind of intelligence suffix/prefix zeros simplify internally in the components before the users sees the path at all

Have you tried the new “Suirify” component ?

Hi, I have created a video tutorial where I explain why you get this path at the beginning of your tree. You can check the video here: https://youtu.be/-DNYJAcoD5E