Index of not working


I am trying to get the index locations of a list of lists. The lacing seems correct. But its still not working. What am I doing wrong?

How to find idexes of points in nested list

Despite the planes you’ve created have the same origin point and normal, since they were created in different places, they are seen as different planes by the software, so they aren’t the same item. For this you may have to use nodes for comparing those planes and check if they are similar.


Try using == instead.

What are you trying to do here? There may be a better solution for your workflow.


I am trying to isolating certain segments along a list of poly curves. Then extract their index numbers in each of the parent lists. i need to do this because in need to use those number to project things onto from members in the Index#-1 elements from a different list.


You should be able to do that by using == and masking the keys for each sublist.


I cant get == to work :frowning:


How do you “mask the keys for each sublist”?

btw I dont understand keys at all. The descriptions and definition in the dictionary are very poor…


I cant even find them if I flatten both lists??


Keys are just items you use to manage lists by. If you have a list of elements that you want sorted by elevation, you would use SortByKey to sort the elements by their elevation and keep your lists in the same (matching) order. In this case we’re using GetKeys to get a generic key item for each element in a list. They just happen to be 0-based digits which are perfect for matching indices.

You’ll have to convert the planes to strings in order to check them.


Ok, well I think I am starting to follow you on the Keys, but why did you make the level selections you did? I dont understand your reasoning. Or perhaps I dont understand levels. For the y value in the == nod I think I follow why you used L1 since that was the level that had the actual data in it But if that is so, then why didnt you use the L1 in the x list? Then You use L2 in the Get keys node, which I dont understand at all, because the data was in in L1 column, AND it somehow magically placed the “keys” in the L1 column of the Get Keys node? Why did it do that? Then you used L3 for the bool mask node?? I dont get this one at all…Plus it made the List 5 Levels deep?? Why? is that right for some reason? Then the out put is really crazy, we have a bunch of empty lists mixed in with a bunch of 0’s and 1’s at different levels that the parent lists? How does that help me retrieve the index numbers of the planes? Im totally lost…


List levels can be a little tricky at first. It’s definitely worth digging into and playing around with. Sometimes you just have to try it and see what happens and hopefully you can understand what it’s doing once you get an output. The important thing to understand is that it’s all about list structure.

We want to check each item from y that’s why we use L1, but we want to check it against the entire input x so we leave that one as is. This also preserves our list structure, so our outputs match our input.

L2 is like using Longest Lacing. We want the keys for each sublist (ie, the indices).

Again, this is all about list structure. Our list input has to have the same structure as our mask. The L3 lists from our == output are the same list structure as our keys. This is why we used the levels that we did in the first place - so that our output is in the correct format.

We have to check each individual item from our initial smaller list with every item in our initial larger list. Both list have 3 levels. Checking a single item against 3 levels would obviously return 3 levels in the output… so 2 levels would return 4 and 3 levels would return 5. (The total number of levels minus 1.)

The output is the index of each sublist where that item appears. The first list in the final output represents the first item in your initial smaller list. It’s not in the first two sublists we checked (hence the Empty Lists) and is found at index 0 of sublist 2.

Now I am realizing now that I forgot to use Keep List Structure on two of the nodes, but that’s just for grouping.

This example might be easier to follow since it’s just a list of numbers matching each index, so it’s easy to see where each item should be. This method also lends itself to using a Boolean Mask instead of GetItemAtIndex because you already have your masks.


Shouldn’t this find the index of the 2 in list 1, index 0? And 3 in list 1, index 1? The only one that it is returning true is the location of the 5…are you sure your lacing is correct? Also can you show what to do with your last nodes on the right? I have NO idea how to use the data in this format structure. Lol


Well, I still dont understand at all what the keys are, or are supposed to be doing. Because all I can get out of them is non-sense answers. See below. Why is it returning random 8 planes? The filter by bool mask in conjunction with the == node seems to work as a get item at index node. Which is what I was after. Which means I think I can make this work. I have no idea what is going on with all of the nodes downstream of the get keys node or how to use that data. What is your intention there? what are you trying to do? and how can you possibly use the data that is produced here?
My last question is why does the filter by bool mask node return 68 planes when there are only 18 in the original list? If I filter by unique items, I can see that there are only 18 planes, but then why does it return all 18 and not 18-4=14 planes like it should? Thanks!


It has to check each value (5, 2, 9, and 3) separately. That’s why the final output of indices is 4 separate lists. The first is only showing the index of 5, which is list[2] item[1].

I agree that the list structure of the indices is not helpful. Unfortunately that’s just due to the complexity and structure of the lists you’re checking. That’s why I suggested using a FilterByBoolMask instead of GetItemAtIndex. If the list(s) you are trying to pull data from have the same structure (they would have to be to use GetItemAtIndex) then a boolean mask will do the same thing.


Think of GetKeys as mapping a dictionary. If you have 10 items GetKeys will return a list 0-9; in the most simplest of terms its saying that that item[0] is the first item in the list. In our list of sublists, each with 2 items, we’re getting an output of [0,1] for each sublist. Each sublist has an item[0] and an item[1]. These are the indices of those items.

Your missing the Keep List Structure option on a few nodes (the blue list levels). This is why you’re not getting the right output.

I realize this is all very confusing at first, so I highly suggest you go through the Dynamo Primer and try to familiarize yourself with this stuff. It’s very important when you start getting into complex graphs and list management.


You should write a python script that compares the planes, so if they have the same origin and the same normal vector it returns the index.


There are many options here. Python is probably the “cleanest” way to do it for sure.


Definitely! In this case, I think that he should do it this way because both nodes “==” or “indexOf” check if the objects are the same and since those planes were created by different ways they are not the same, even though they have same properties. That is why those nodes are not recognising them as equal. Comparing the plane’s properties and then managing the results will work. Am I wrong? I was thinking about something like (using “for” to go throught all items in the list):

originOne = planeOnFirstList.Origin
normalOne = planeOnFirstList.Normal

originTwo = planeOnSecondList.Origin
normalTwo = planeOnSecondList.Normal

if originOne.DistanceTo(originTwo) == 0 and Vector.Dot(normalOne, normalTwo) == 1: True

or maybe, instead of equals zero and equals one, use less than or bigger than something, so you have a precision to play with:
if originOne.DistanceTo(originTwo) < 5 and Vector.Dot(normalOne, normalTwo) > 0.9: True

does it make sense for you?


The “==” and “IndexOf” nodes can easily be fixed by converting the objects to strings and comparing string values. I wanted to avoid Python because not everyone uses it, but I probably would have coded something in Python if I’d ran into this issue myself. The other thing that makes Python a little more complicated is that the list structure is very specific in this case. Nodes allow you to change list levels on the fly more intuitively than reworking a Python block.


I understand now. Managing them as strings is really a great idea! Thanks for this discussion, lots of learning here