Feature Suggestion: List Sorting

[LeonCheung]

According to my BA thread discussion here, I think this feature would be very worth to have. Filed it here. FYI. Thanks.

[JacquesLucke]

what list types do you want to sort?

[LeonCheung]

Mostly for objects. (and elements?) Similar to such thing:

This is very very useful to control the building order.

[JacquesLucke]

ok yes. That should be possible. Will see when I have time for it. I just finished my big project for 'today'

[LeonCheung]

Haha, I saw, and it was a big one. Congratulations!

OK, Some of the possible "sort by" options I can think of:

1. For objects:

Transforms (mostly by Axis) Distance to Cursor (or target object) Selecting order Randomize (or Shuffle, already supported) Name (works for objects like xxx.001, xxx.002.... etc.)

1. For elements:

Input the current element sorting order. Vertex Weight. Edge Length Edge Weight (sum the weight values of both end vertices on edge) Face Weight (sum the weight values of all corner vertices on face) Face Area (or other possible properties such as material index, too many possibilities)

[JacquesLucke]

Until we have a good node for that you can sort lists like here:

[og76]

could we have a moment in the future dedicated to a more general lists area? instead of having 10 issues on various parts.

I think there are some other list stuff to be added, or existing but to be put in order. And some more may emerge from that. (this being one of them..)

[LeonCheung]

@JacquesLucke Cool, it works indeed, for now. Thanks for that. :)

[og76]

Indeed it works great. I just gave an example on the forum using it for custom property (set with Obj Att out on all objects etc).

But I did not manage to made that work also in script node. I used: -obj attrib node: ["MyProp"], +some float value there -expression node: sorted(list, key=lambda e: e[x], reverse=y), with x= MyProp (from string socket)

In the script node I use the same but I cannot figure the right way to format x, it always gives me x is not defined error. it works for manual ["MyProp"] but no way to say [x], [str(x)] etc to have it from a socket (x is defined, works for any other formula )

[JacquesLucke]

can you please try this again with the current version? I just made a small fix to the script node. Maybe this is related to it

[og76]

yes it works in the script node now, either as [x] or as [str(x)]. (should that be in master? is only fixed in socket branch ... so I cannot put it on forum..)

[JacquesLucke]

yes it should... Wait. I will revert the change and do it in the master branch again.

I hope to merge the curve branch into master soon..

[og76]

it should be in both, as I still use the socket for tests. but that is less important ...

[JacquesLucke]

its in both now

[LeonCheung]

Just wanna file more for ref here:

For numbers: Ascend / Descend

For strings: Alphabically / Length, etc.

[JacquesLucke]

The basic setup for the Sort List node is done:

Basicly it supports two sorting types for all list data types. "Custom" gives you a small text field where you can insert an expression which will be used as key. Additionally (thanks o.g. for this idea) there is "Key List". The normal List and Key List have to have the same length. Normally you should create the key list using a simple loop with a generator output. Supported Key List types are Float and String.

These two sorting mechanisms are generic, so they can be used with all list types. Furthermore I implemented a system that allows us to implement specific Sorting-Presets for individual list types. for example it allows us to easily sort objects by a given direction. This can be extended after the release without breaking the node. hopefully.....

[og76]

Ha, I've just finished (for now) workin on another version. :) @ J: I'm not posting this to spoil your birthday / version :) but cause I see it like this.

sort_list_og.py (The file name is Sort List OG (also internally) so that you can test in parallel with no issues)

Please do download and test to see better what I try to do here. At least cause I worked my a.. like hell to make it like this. Also cause the sorted index out and precision are at least 2 of the critical parts here

Now, as design / concept goes:

1. All lists have the same default variants, using another float, integer or text list as sorter rule Default to Float (+int) as that is very easy to generate by any loop, any rule (see examples) Text is a convenience, where names etc may not be that easy to transform to a float list..

   These key lists can be of any length, it will apply the sorting only to corresponding part, if shorter, ignored rest if longer.

2. All lists have the alternative "Custom Sorted index" variant. Unlike the above this reorders by index, not by key list. (maybe not a true sorter, but rearranging by index) See below for examples. As above can have any length, sorted index list may even be chaotic, repetitive, or indices outside range/len . It works anyway, and kinda doin the right job.

   Basically ignores, what is not right, reorders what is right, and only uses indices once.

3. There is always Sorted List and Sorted Index as output. The Index does the other half of the job here for:
   • knowing where an element was originally (as index)
   • propagating the same rule for more than one list, for example sort by polygon Normal, then reuse the same order for poly indices ( like in the examples below) by use of Custom Sorted index
   • Custom Sorted index also works as a "selector" for some elements, so that you can pick some el by index and move them to the front
   • Some cases, may only use the Sorted Index out as you only have to point to an element, not necessarily use the sorted one. For example, you may resort objects by grid distance to point, but sometimes, may wanna leave the objects in place and only change a prop (color?) according to this rule.

4. precision / tolerance. This is a very important part, as otherwise you'll be surprised how float error/precision can mess with your sorting. The very basic Cube poly areas will give you a weird reorder if not rounded or grid vectors may not go as expected .

   This is even more important if u cascade several sorting nodes, as in the examples below . For example distance to, then radar will give you a nice cone/disc arrangement of verts, only if the rounding is in place (very important for using the sort to further have a grid poly indices list on top ov those verts)

   This is always present in Advanced panel, with the value of 4. Should leave it like this, but if u wanna see the difference with no rounding, take it above 5 and is useless.

5. Some lists have special extra variants (vector and mesh data) like distance to etc. i have not included Object here, as it is very tricky and confusing if u don't have id keys, initial transforms etc before for location or so.

   So far:

   • All Vector, Vertex, Polygon: Distance to, Direction, Radar
   • Vertex, Polygon: also Normal (like direction)
   • Polygon has more variants for distance to: Center, Closest vert etc (may go for other cases too)
   • poly index/edge index have sort by smallest index

   Please propose more, or different.

   I made a separate node for reordering the inner indexes of the poly/edge, (if u sorted the vectors, may need to do that) so that it does not mess with the Sorted index already here. And it's not a sorter really.

6. I have not implemented expression, as I consider
   • we already have the expression node (and others)
   • this can be generated in loops with expressions, attr .. , and this is more nodal
   • precision is a big issue to pose into an expression
   • I've already complicated my life enough :)
7. As code goes:

It may not be the most elegant or efficient (as node) but it works and covers for most of the (ui) cases:

• having change the enum prop with the type of socket/data
• preserving that if u come back to another type (remembers the last values)
• it allows extra checks/options like the matrix one in radar
• it goes with is linked optimization (partially, I can further format the code lines to eliminate the enums in the sort also)

Examples / Pics:

The Common case in the left, the special ones in the right

Generate custom (poly area) float list and Propagating the same rule to another list

Cascading sorters to get:

• circular clean spiral, on the disc here, you need to first sort by distance (not the original sort) and only then by radar. See also the radar rot/matrix, referring to x of the empty
• grid by distance, then arbitrary float list only affecting first elements (short list) > first elem ordered
• grid then arbitrary chaotic index (integer) that is "selecting"/picking some elements by index (thus the gaps in the grid)

hope we'll get something good out of all this. thank you and waiting for comments, suggestions etc :)

[og76]

also hoping for severe judgement form the "master of all sorting" , so I hereby "Invoke" @LeonCheung :)

now seriously, I'd really like to know your thoughts on these ..

[LeonCheung]

Ah, Okay. Here I am. ;) I'm currently out of the city and can't experience og's version. Seems cool though, just one certain on a highly possible usage: Cocurrency (there may be another word better than this?)

Basically I'm thinking about a possibility to directly generate kinda order list that supports dupli IDs, which can be used, e.g, to replace the loop index. I've tried achieving it with a few extra nodes in my Archimator case on BA.

I think we can have a new output to support that or have a separate node, with options such as threshold (just like what I did in the same case ) fyi

(btw, tying on smartphone is very painful....)

[og76]

@LeonCheung have a nice holiday :) not sure what concurency means, like this? you can use only the index..

[LeonCheung]

Oh acturally I mean something like this.

Also see the video in this post around 06:40.

Hmm, now I feel it is little related with sorting (or not?), more of an independent function.

[LeonCheung]

No, I'll change my mind. It does relate to sorting function.

[LeonCheung]

It seems things get solved by the ID Key sorting feature implemented lately, closing for now.