Set positions of neighbor vertices, is it possible?

[wesserbro]

I want to try an idea for smoothing algorithm which, unlike standard ice smoothing, does not move vertex to its neighbors average but moves the neighbors opposite direction instead

Untitled.gif (2.08 KiB) Viewed 8870 times

[jonmoore]

This is your basic construct. The points below the torus are the original point position before the simple Add operation, and the tags on each point on the torus show that the add operation is applied to each of the the four neighbouring points. You then set those new point positions based on the custom attribute you created for those point positions. Obviously you'll be applying your clever smoothing algorithm in place of my simple add (+2 in Y) operation; but the basic construct is the same.

[wesserbro]

hmm, so anything you put in self.tmp will be an array of per point data you can use on next iteration... nice
Somehow i thought port1 executes per one point, then port2 on the same point and then cycle goes to the next point, so this simple trick never crossed my mind

[wesserbro]

but wait...
No-no-no
What your tree does is just adding 2 in Y for regular points
Notice how self.tmp attribute of each point just contains the position of that same point

[wesserbro]

and even if we put neighbors positions in there (which is doable) the 'set point position' in port2 let us change the position of a current point we iterating through, not its neighbors.

[jonmoore]

My bad. Apologies for any wasted efforts.

[jonmoore]

This thread from the Softimage Mailing list might help with a possible route. The major hurdle to overcome when attempting a solution like my naive suggestion is that ICE doesn't allow you to work with arrays of arrays. However, Raffaele Fragapane's suggested approach (last post) hints at a possible way of approaching the challenge.

https://groups.google.com/g/xsi_list/c/j7tPlL54HIM

[jonmoore]

Apologies for the brain fade yesterday. This compound from Julian Johnson is far more the droid you're looking for.



You'll still have work to do in terms of taking the array of locations and making it fit with your requirement - a dynamic ICE driven weight map would seem to be a reasonable route to explore on that front. The other thing you'll want to consider is how you iterate over the points (I'm assuming your algorithm will be less optimum if you're iterating over every point on your geo).

http://julianjohnsonsblog.blogspot.com/ ... us-13.html

Anyway, hope this is a little more helpful.

[wesserbro]

Well, selecting neighbors of neighbors is not a problem, it can be done pretty easily
still, setting neighbors positions would be some next level trickery, involving getting per object array of arrays in first iteration and then on the next iteration reading from that array to check if current point was a neighbor to a certain point and how its position should be altered based on that.... Too complicated
Anyway, i've already tested my algorithm with python script in blender, it kinda works, but not as good as i expected Missed all the debugging visuals ICE provides though

[jonmoore]

If you dive into Julian's compound you'll see that there's a lot of logic that you could expose in terms of tracking effected points per iteration. It's far more than a jazzed up 'get point neighbours'. But it sounds like you've already done your dev research in Blender.

When I come back to Soft after spending a lot of time in Houdini, I despair a little about the constant juggle between sets and arrays. It adds a layer of complexity that's missing in Houdini - and Houdini has the reputation of being the more complex beast! Bifrost Graph in Maya is very similar to ICE with regards to it's treatment of arrays and sets. In Houdini, everything is basically points (whether it's a point in a point cloud or a point the makes up poly on geo), so mixing and matching data sets is far less cumbersome.