> My (x,y,z) set of observations is a 30 x 40 matrix which must go into a

> roughly 500 x 500 bitmap. The matrix is updated once every 5 seconds.

That's comfortably far on the feasible side of things... ;-)

A regular matrix is triangulated trivially: choose on of the two

diagonal directions, and cut each rectangular cell of the matrix in

half along that diagonal. Done.

For the actual rendering, using a 3D renderer to do a top-down view of

the vertex mesh, gouraud-shaded, may be the most obvious choice.

Quote:> PC, so efficient code will have its benefits. I was wondering if there was

> a way to avoid the interpolation calculation for some pixels.

Probably, but that won't gain enough to make much sense. Note that on

average, every changed z value will affect about 5 triangles that

share this vertex. I.e. if you change 10 percent of the vertices, you

should expect roughly half the triangles to need a redraw. May just

as well redraw them all as try to find out which those are.

Quote:> From what you suggest, I could do the triangulation once and only

> repeat the color interpolation, but for each pixel.

You wouldn't actually interpolate the colour itself if you do it in

software. Interpolation would be in terms of the z coordinate. Then

you look up or compute the colour's three components based on the

interpolated z.

Very roughly, for a strictly regular mesh with data at integer

positions, and shedding triangulation in favour of bi-linear

interpolation, the per-pixel code could look like this.

x_g = x_pixel / 500 * 40);

y_g = y_pixel / 500 * 30);

dx = x_g - integer(x_g);

dy = y_g - integer(y_g);

z = (1-dx)*(1-dy) * in_z[x_g] [y_g]

+ dx *(1-dy) * in_z[x_g+1][y_g]

+(1-dx)* dy * in_z[x_g] [y_g+1]

+ dx * dy * in_z[x_g+1][y_g+1]

R = find_R(z);

G = find_G(z);

B = find_B(z);

Adapt and micro-optimize to your heart's content.

Quote:> I was not too concerned about the color interpolation in my case. I hope I

> am not underestimating this, but I must admit I was going for the "obvious".

> With the endpoints and breakpoint being pure red, yellow and green I assume

> that I can make a linear interpolation between (255,0,0) and (255,255,0) to

> move from red to yellow.

I'll assume you meant you'll keep R and B fixed, and just raise the G

proportional to the interval fraction.

Yes, you can do that. But that's not necessarily the most visually

pleasing or even the most useful path to interpolate along. To give

just one hint: is that linearized or direct-to-hardware RGB values

you're talking of? "Perceptionally linear" may be quite different

from both, to boot.

Quote:> linear interpolation could show discontinuities in the gradient that do not

> exist, isn't it? In addition, the observation error is not negligible. This

> warrants smoothing of the data to a certain extent.

You can still do that as a post-processing step after generating a

linearly interpolated image, if need be.

--

Even if all the snow were burnt, ashes would remain.