0
$\begingroup$

I'm having this issue with animation nodes where, if I want to change the list of vertex positions of an object based on a boolean condition, then only one vertex gets affected. In this case, only the vertex at (1,1,0) gets moved upwards. In the example I appended, clearly all vertices of my object are at a lesser distance than 10, so they should all move. However, if I delete the "boolean branch" of the tree, and modify the whole list blindly, the whole object moves.

Thanks!

enter image description here

EDIT:

I'll append a screenshot of the actual nodetree where I'm having the issue. As you can see I'm looking for the nearest five particles of the particle system to the point, and then, with a very simple script, i find the velocities of those particles and calculate the resultin vector. Also, I check if the minimum distance of the five is less than some arbitrary number that I choose, and based on that, I decide to do the change or not. Appart from that, I check for the nearest points in the sphere to the current vertex in the iteration (and append the index of said vertex as well to the list of indices). Then I use a script which I will leave here to change all the vertices that are pointed to by those indices in the original list of vertex positions. And based on the boolean mentioned before, I choose what list to connect to the mesh output node.

What I intend this to do is, for every frame in the animation, change the whole list of vertex positions based on everything I just said.

Thanks for the help!

Script:

def mod_vec_list (ind, pos, vec_dist, vec_vel):
    for x in ind:
        cust_dist = (vec_dist - pos[x]).length + 1
        pos[x] += (1/cust_dist) * vec_vel
    return pos

res = mod_vec_list (ind, pos, vec_dist, vec_vel)

enter image description here

$\endgroup$
0
$\begingroup$

There are three reasons why your node tree don't work as you expect it to. The following three sections explain those reasons in details.

Data Copying

First, please read the Data Copying section in the documentation to understand what we are talking about. You expect all the vertices to move one unit upward, your reasoning is that the condition is always True and this is true. However, notice that your If True input is connected to a Set List Element node that, in turn, is connected to a parameter of the loop. Since that parameter is connected to the If False input of the Switch node, enforced data copying is performed, subsequently, the Set List Element doesn't edit the list, but rather a copy of the list that is only available is the scope of each iteration. By the end of the loop, you never moved any vertices, you moved only one vertex in each iteration in its scope. Cut the connection going to the If False input and you will see the loop works as expected, that's because data is no longer being copied, that is why when deleting the condition branch, everything works as expected.

Instant Overwrite

You are outputting the vertices to the mesh at each iteration and each iteration overwrite the vertices location that was written in the previous iteration, so, the only effective data written is that of the last iteration simply because it will not be overwritten. In that last iteration, the If True input is the original vertices except for the last vertex moved upward one unit which you observed as that at the location (1,1,0), the reason for this is what which we described in the foregoing section. In conclusion, never write data inside a loop! Output the data from the loop then write it.

Infinite Offset

You are getting the vertices locations from the Cube and outputting it to the Cube, upon continuous execution of the node tree, the vertices will start to move to infinity, which, I assume, is not something you want. In conclusion, your source shouldn't be your output, either cache the vertices location or output to a new mesh.

$\endgroup$
  • $\begingroup$ Thanks, but that's not the issue. I was evaluating the socket, I just disabled the button when I did the screenshot. Morover, I tried your method, and I run into a different problem which is that my subprogram outputs all the lists resulted from all the iterations, concatenated, thus the vertex count does not match. $\endgroup$ – nachosanchez Jul 27 '18 at 16:50
  • $\begingroup$ I was doing something wrong, your method does give me what I want, but it still confuses me why the first did not work $\endgroup$ – nachosanchez Jul 27 '18 at 17:19
  • $\begingroup$ In my real problem, though, I don't see how this is viable, since I have a custom script that modifies several elements of the list in one iteration, and this is crucial, any help would be appreciated $\endgroup$ – nachosanchez Jul 27 '18 at 17:28
  • $\begingroup$ @nachosanchez Can you add more information regarding the real problem? $\endgroup$ – Omar Emara Jul 27 '18 at 17:40
  • $\begingroup$ Thanks. In my real problem, I have a small sphere, which is a particle emitter, and a big one, which is a collision object. What I'm trying to do is to make the particles sort of deform the outer sphere once they collide with it, but in a very subtle way. So to emulate this I have a boolean condition related to the particles distance to the current vertex in the iteration. Now, I don't want to modify just that vertex since it would be too abrupt. So what I did was create a simple script that modifies some other vertices nearby and makes the deformation smoother. $\endgroup$ – nachosanchez Jul 27 '18 at 17:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.