Any experts with this that can give me some ideas?
I haven't really touched vertex colors until now, but I'm looking at it as a way to set up geometry-based masks for this geo-mixing system we have. It's really cool, we'll be able to blend between models/anims/materials on a per-vertex level, with artists manipulating the masks.
I'm wondering if there's a way to animate the vertex colors such that I could have a gradient move across the mesh. For example... I want to have a character's hand use white vert color, and the arm use black, with a gradient falloff between them across the wrist area. So far so good, I can bake a map into vert colors, no prob.
But then I want to take this falloff and travel it up the arm in an animation, so the falloff would end up at the elbow, with the bicep verts in black and the forearm/hand verts in white. I need to see that gradient travel up the arm.
I tried stuffing the vert colors in a UV channel and moving those UVs around, but all the white/black end-verts are crammed in the corners, no way to smoothly "pull" them out to travel into the falloff zone.
The other way I thought of to control this blending thing was to use soft-selections instead (Vol. Select mod can convert a bitmap into a soft-sel). That lets me move the gradient around just my Xforming the bitmap's UVs. But then I'm kind of stuck with only one mask per mesh.
Anyhow, just fishing for ideas. Maybe somebody knows something...
Replies
so valid source or destinations are: vertex uvw, illum, alpha, color, current unwrap modifier
The weird thing is that I can animate the UV offset of vert colors, because they can be in any UV channel. But I just can't really control it easily, offset isn't enough, because of the way the verts are arranged...
Black is UVW(0,0,0), white is (1,1,1), and the verts getting the gradient values are pinched into a thin diagonal line between the two extremes. But to get the verts to travel through the middle zone, I'd have to be able to pull them out of one corner, send them across the diagonal, then bunch them into the opposite corner.
After sleeping on it, I think I'll have to go with soft-selections instead (unless there's some other vertex-weighting method that might fit the bill).
Thanks again Christoph.
That gets me an even gradient from one end of the mesh to the other, but doesn't let me do a tight grad (on the wrist for example), nor does it seem to solve the scroll-animation issue. I don't see how it's solvable at this point. But maybe I'm just misunderstanding your idea.
I would alter my tool so that you can copy vertex color to unwrap modifer, and it creates proper animation keys in the unwrap modifer.
so you could paint a frame vertex colors, copy to unwrap at frame 0, then paint again, copy at another timepoint... probably below efficiency optimum, but would allow you to have animated uvs that you could set by painting
give me a "go" or "no go" and I will change the script
We have a couple basic requirements...
First off, the masks have to be baked into vertex-weight values. Requirement of current hdwr.
Second, the masks have to be complimentary. In the end the masks are summed together, so every vertex's weights must sum to 1 (otherwise we get over- or under-contribution).
To control the summing, I'm trying to keep the masks bitmap-based, since Photoshop (and its ilk) are the kings of mask control. Then I can use some method in Max to convert the bitmaps into vert weights.
If using vertex color, I can bake diffuse into it using the Vertex Paint mod. So I could animate the diffuse's UVs to scroll the gradient, then bake each "frame" as a new UV set, then combine those with your tool into a single animated UV set. Sounds slow, and unforgiving, if I later want to change the gradient somehow.
But maybe there's a way there...
like sampling the texturedata at given timesteps, like every n key. and store that in animated uvw.
Thanks both of you for swinging around with me on this one.
you could enter how many frames you want and it will divide time accordingly and process in timesteps doing the above... of course it would be much faster in c++, but could work as maxscript solution, too.