Hey milliams,
This is pretty much where vertex colors should come into play - my reply to you about copying vertex color info in the main Procedural Mesh thread was a result of work along very similar lines to what you’re describing.
Apologies if you already know the following, but I wanted to clear up what appeared to be a misunderstanding from that thread: the most important thing to remember is that vertex colors are an intrinsic property of the vertices - they don’t directly affect the rendered color of an object by default. Traditionally they’re used for passing per-vertex lighting information or for driving lifetime-varying variables in particle fragment shader (ie R channel 0->1.0 lerping the color of the fire/smoke particles in a rocket’s trail from (1.0, 0.8, 0.3, 1.0) to (0.1, 0.1, 0.1, 0.0) or something like that).
At any rate, you can setup a simple lerp between textures based on vertex color like so (ignore the stuff outside the red box unless you’re using a texture atlasing system like Minecraft’s):
Which in practice can look something like this (top row intentionally omits blending for comparison):
Just so it’s clear, the above isn’t strictly Minecraft-style cubes but rather 5x5 heightmaps with sides, which in addition to slopes/half-height blocks allows you to blend textures with neighboring tiles, since there’s intermediary vertices between the top-center and the top-edges.
This is a super-naive 10-minute implementation with straight lerps and in practice you wouldn’t really want to do it this way - rather you’d want vertex colors to be weighting content-aware blending masks so that sand fills in the cracks between rocks, grass blades don’t suddenly “fade out” into the dirt texture, etc.
Hopefully this helps get you where you’re going.
–Ryvar