i don't think you quite understand(or we don't quite understand what you want to accomplish?)
how well is that plane subdivided?, the problem is that you can't get the output you want if your using 2 triangles per quad(and it looks like 9 quads), since the pixel shader linearly interpolates the uv values being passed in from the vertex's, this means you need to at least have the number of vertices equal to the number of data points, and then it has to be arranged to look like the quad, which could be very complex.
it might be better to actually take your pallete and build a 2D texture surface from your data points(and interpolate those data points yourself), then simply render that onto a quad.
edit: this might be possible in a compute or geometry shader though, but i don't believe you could achieve this easily with just vertex/pixel shader(although i'd love to see if someone does have a good solution).
You are right, here is 9 quads = 18 triangles = 16 points (data points). Each point has a texture coordinate. Number of vertices are equal to the number of data points since vertice IS a data point. Sorry, if I confused you. Each vertice contain coordinate and texture coordinate.
About 2D texture, not sure how it would help since my palette consists of vertical lines and V (y) coordinate is no needed (at the moment).
To my mind the problem is that textures are imposing on the separate element, not on all surface. But I may be wrong.
I don't think you quite understand how the vertex->pixel shader works, yes you have 16 data/vertex points, and could even pass in the data that your trying to interpolate across those vertices, however the problem is how the vertex shader get's translated to the pixel shader. it is always going to be done in a perfectly linear system, your sample image does not move across the triangle perfectly linearly, if you could control the pixel shader translation's across the surface you could apply w/e formula you use to do this, but at the moment, with strictly vertex/pixel shader, and as far as i know(and i may be wrong, which would be pretty cool to learn), you can't control how the pixel shader translates that data.
this is why we suggest you construct a 2D pallete of those data points translated across your 2D surface, and then render this, which can be done on initialization, or even when their's a change in data points. with modern computer's you probably won't even notice a slow-down when doing this in real-time(but not every frame, just on every change, although you might still get smooth results with every frame, i would not recommend doing that at all.)
for example, let's forget about it as a triangle, and think of it as just a straight line, looking at your image, let's take the bottom 2 vertice's on the left side, now then for simplicity sake let's look at this as if it's only along a single axis(let's say x):
the first vertex has a position at: 0 x, the uv is set to 0 as well.
the second vertex has a position at: 1 x, and the uv is set to 1.
so, the pixel shader sees their are 50 pixels between those 2 points, so each pixel get's this for it's input:
position = v0.x+(v1.x-v0.x)/50
uv = v0.u + (v1.u-v0.u)/50
see how their's no room for creating a system which isn't perfectly linear(and as you can see in your sample image, the color's along that bottom left line are not equal parts from each other).
I hope this explanation helps you better understand your problem.
Edited by slicer4ever, 15 January 2013 - 02:34 AM.