Is there a way to get vertex velocity?
Interactively? Or is the vertrex animation pre-defined?
Object-space or world? If it’s object-space, is it modifier animation or base object?
And is the topology constant?
I would say that it would be very nice to be able to do temporal sampling, but I’m not sure how practical that will be in the short term, just as we’ve discussed for Krakatoa.
It was originally on the wishlist, but for now we would suggest using the Velocity calculated by our other tools, like XMesh and Frost.
Both have an option to copy the Velocity to a map channel, so you can read that into Genome and do something with it.
For now we don’t intend to provide a “native” Velocity channel as an Input since 1) Max does not have a concept for such a channel in the mesh; 2) It would require the evaluation of the object at two different times and would make things slower, and 3) It would not work with changing topology anyway.
And most importantly, 3ds Max modifiers are only executed for a single time instant and have no knowledge of the base object and modifier stack below itself at any other time.
But except for the topology issue, there’s probably a lot of easy workaround for. Like you could use 2 Meshers with different time offsets, or you could use 2 PointCaches with different time offsets and use 2 Genomes to store and compare the results.
Tried the Mesher approach, but it does not work because the Mesher has a dependency on the original object and Genome drops the reference to avoid Circular Dependency. PointCache would work, and XMesh has the data stored and ready to go to a mapping channel anyway.
mmm…I figured the answer would not be that is was easy or it would probably already be there 
I dont have xmesh at home, but I have done similar things in krakatoa already and that would probably be the most efficient approach. I will try using point cache tonight to find a one tool solution so to speak. Thanks guys.
I was thinking 2 Meshers. One would have the offset time, and the other one would hold the actual Genome modifier. It would compare the positions of the offset time Mesher and the original object. With 3 Meshers, you could sample forward and backward velocity.
That might work too…and wouldn’t require pre-caching…
You guys have any desire to make a velocity to UV mapping modifier for inclusion with Genome 
Here is a sample of what Chad was talking about:
GenomeVelocityExample.max (200 KB)
This scene has a teapot with an animated bend modifier on it. I made two mesher objects pointing at the teapot and gave one of them a -0.5 offset (That seems to mean it will have the mesh from a half frame in the future). The mesher object with offset 0.0 is what we will consider the final result I’m going to call it the output object.
On the output object, I added a genome modifier that looks like this:
As you can see it is filling in the color channel using the magnitude (clamped to 0,1) of the velocity I calculate using forward finite differences. The velocity of a point is the change in position divided by the change in time. So subtract the position from the original mesh from the position in the time offset mesher and divide by the time offset. That gives me the velocity in units per frame.
Since I’m iterating over the color channel, I don’t have a simple way of determining which vertex I’m looking at so I use the index [0,3) of the face vertex to pick the barycentric coordinate for using the FaceQuery operator.
This method will work for any mesh that isn’t changing topology. For kicks I added VolSelect and MeshDelete modifiers so that the vertex count would change as some enter the volume. The velocity becomes garbage after that occurs.
EDIT: It occurred to me that its kind of a waste to use Teapot001 & the FaceQuery to get the position, when I could have just used InputChannel -> “Position” to accomplish the same thing. Oh well.
As an aside: Given that the channel is called VertexIndex I suppose it might make more sense to have it return the index of the actual geometric vertex index in the current iteration instead of having it return the [0,3) index of the current corner of the triangle. What do you guys think?
Right, that seems to work nicely. I added it to the new Vertex Velocity tutorial:
thinkboxsoftware.com/gnm-cal … x-velocity
Both would be very useful, the question is what do we call the 0-2 iteration index channel? “FaceVertex”? “FaceCorner”?
Oh very nice… 
Thanks Darcy