I'm trying to set up a Genome flow for this and I am stumped. I'm hoping this one will be a breeze for you though.

I attached a sample scene with my non-working setup. I will apply this effect to another scene but a modified Geosphere works just fine for this example in order to get the concept to work.

I have a Geosphere with a morpher modifier that morphs the geosphere's verticies to the position of a cloned geosphere with noise displacement applied. I want to be able to assign vertex colors that change based off of their distance from the original sphere's vertex positions. I'd like for these vertex colors to change over time to correspond with the surface animation.

I'm not sure why but I couldn't attach my scene file in my last post. It looks like there may be an error here so I'll try emailing it to you too. I also attached a screen grab of my non-working flow. You'll see the logic I'm trying to apply to this setup though - if the vertices positions are equal to the non-deformed sphere they get selected.

You need to ZIP the scene, the forum does not allow .MAX files to be uploaded. Got your email, will check it out.

Just looking at your flow, what you need is the Absolute value of the Distance output in the NearestPoint operator. Assuming you want to use that operator at all, if you are using Morphing, the vertex count is identical, so all you need to do is query the vertex position in the other mesh by the same index as the current InputChannel:Index, subtract the two positions, do Vector Mangitude, and divide by the Max. distance to normalize between 0.0 and 1.0. Then you can output as VertexColor or Selection.

If you prefer to only color the vertices if they are ABOVE the reference mesh, and stay black when pushed inside (below the surface), you only need to remove the Absolute operator, and add a Clamp after the Divide operator:

Any negative values will be clamped to 0.0 and remain black if the vertex is pushed in the negative direction.

In the next version, I removed the top Genome modifier that converted selection to Color, and changed the bottom Genome to Face Corners iteration mode. Here I used VertexQuery to grab the world space position of the reference geosphere's vertex with the same VertexIndex as the current iteration's vertex index. The rest is the same, plus the conversion of the normalized value to a Vector going directly to the Color channel.

I expect this to be a lot faster with very dense meshes, because it does not have to stuff the mesh into a kd-tree acceleration structure to perform any nearest point queries, it simply reads by index the respective vertex from the mesh. However, it performs a few more queries (3x the face count instead of the vertex count). So with your Geosphere instead of 10242 NearestPoint calls, it will perform 3x20480 = 61440 vertex reads. Chances are it will still be faster, esp. since we avoid the second Genome on top of the stack...

Bobo, thank you so much!!! I tried each of your flows and they work exactly how I need them to. I am going to use this same setup in another scene with more complex meshes so I'll try using your last example that iterates over face corners. This should work great but I'll let you know if I have any other questions.

Ooops! In the first modified flow, the NearestPoint Position should NOT pass through a ToWorld operator, because it is already in World Space.If the Geosphere is at the origin, it won't matter, but if it is not, you would get double-transform by the world transform matrix, and it would skew your results. Sorry about that, but it was you who added it

Haha, no worries Bobo! I actually showed this to my coworker Tyler (he has a programming background so he's better at this stuff then I am) and he helped create an alternate flow that adjusts colors differently depending on whether the vertices are displaced inward or outward, which actually should work better for what we're looking to do. Here's a screen grab of the flow and a render. I attached my updated scene file if you want to take a look.

InVolume is rather expensive - it still has to perform the kd-tree initialization, and then it has to perform several surface tests to ensure the point is inside or outside. And because we are doing the Face Corners test, it is actually doing a lot more lookups than if you were using a vertex iteration mode (6x more as we saw previously!)

So if you are going to use a mesh lookup, then the alternative approach with a NearestPoint and Distance would give you the same result, but might be faster since it would perform only one lookup for each vertex, and the Distance will return a negative value if inside, and a positive value if outside. Write that into the Selection without clamping it.Your logical Switch will go into another Genome on top and would just need a Greater operator to check if Distance is greater or less than 0, and then the absolute value of Distance can go into the respective blend operator! To make things even cleaner, the green color input can be reused for both blends, so if you expose it and change it, it would affect both sides...

Of course, if you feel your current solution is fast enough for your actual production scene, then having a single Genome modifier might be a good thing...

Thanks Bobo! That's good to know, I'll give your suggested approach a shot and see how that works. In any case it's good for me to try different approaches to get more practice creating flows. Cheers!!