Work Item Indices

   211   4   1
User Avatar
Member
29 posts
Joined: Feb. 2017
Offline
Please do not set all work item indices to one, and introduce redundant items like csv_rowindex. This just makes life harder. You can't use “sort by work item index” in wait for all, because it is renamed. You have to add a separate sort node, that does nothing but restores the work item index to what it was supposed to be. And the sort node can't do much else, like reverse the order etc. like SOP sort can.

Remember, each dot on the node is supposed to represent one work item. The index of an item should of course be zero for the upper left item, one for the next etc. This is totally inconsistent now. Some nodes index the nodes in this way, other start with one, other set all items to one.

If you argue that a CSV file is just one item, then there should be only one dot on the node. If you argue that it is a partition, then make it real partition, and display it as a rectangle. But whatever you, please be consistent, and don't introduce strange exceptions where there are several items, but they all have index one.
Edited by gyltefors - April 15, 2019 05:12:01
User Avatar
Staff
270 posts
Joined: Sept. 2016
Offline
gyltefors
Please do not set all work item indices to one, and introduce redundant items like csv_rowindex.

If your upstream item has an index of 1, then each downstream item will also have index 1, which I think is what you are seeing. If not please let us know how to repro.

The reasoning for the csvinput index change is that it should match the convention of all the other processors, which by default calculate workitem indexes to be derived from the index of their upstream item. However it should not have changed the csvinput default behavior, so that will be fixed in the next build. (Index = csv row index by default)
User Avatar
Member
29 posts
Joined: Feb. 2017
Offline
I have used TOPs for a few different use cases, and I have to disagree regarding the reasoning of trying to match the upstream work item index. When I need to do matching, I always create my own attribute for clarity. Let's say I have a point cloud in SOP. I want to know the index of each point, which is $PT or @ptnum. If I need to match two different point clouds, I'll create explicit indices like @my_point_id = @ptnum+1. This clear, and leaves no room for misunderstanding. Just imagine if the point indices were unpredictable, sometimes @ptnum was 1 for each point in the cloud, just because that would somehow match the upstream node, for some particular use case, for some particular user. It would just be horrible. It is the same work item indices. If a node has 10 work items, just index them 0-9, and if some user wants some particular matching, let them create an attribute @my_work_item_id = 1, or whatever. Clarity is always better in the end.
Edited by gyltefors - April 16, 2019 00:04:41
User Avatar
Member
29 posts
Joined: Feb. 2017
Offline
Btw, talking about the csv input node, it does not support unicode. That is a big issue if you are not living in the US. And csv output splits a string attribute containing commas into several columns, but only when specifying tab as delimiter. (Please also check this tread: https://www.sidefx.com/forum/topic/56964/?page=1#post-277657)
Edited by gyltefors - April 17, 2019 07:06:28
User Avatar
Member
29 posts
Joined: Feb. 2017
Offline
Again, another issue with CSV output. Handle multiple values Add Columns with a 2D position attribute gives:

position position1 position1 position1 and so on

The JSON/CSV related nodes are, honestly speaking, totally utterly broken. They have been for weeks. And it have kept me frustrated with TOPs for weeks. And it has prevented any kind of progress in my project for… WEEKS. Please, please, do something about these nodes. I can't believe how they can have been shipped with so many bugs! Did anyone ever use these for anything even resembling a real project???
Edited by gyltefors - yesterday 01:02:31
  • Quick Links