Please look at
http://pleiades.epfl.ch/~rgruber/opengl/open.png
The linear interpolation is done in directions 0Â°, 45Â°, 90Â°, 180Â°, but NOT in 135Â°. This gives a nonsymmetric image. What can I do?
You draw the four quads and do a 1D texture lookup from color ramp?
The four values you have at the vertices of the quads are probably not planar in your flux space and quads are drawn as two triangles and the splitting is implementation dependent.
The simplest solution would be to dynamically refine the geometry where necessary.
A better solution would be to use a 2D texture for the input values instead of specifying them per vertex.
Let me come back to the test example, because I am not the only person to see this problem. There are only two function values at the opposite mid points on the north and the south that are nonzero, thus one nonzero value per quad. I insist in interpreting the resulting graphic as an interpolation problem that should be corrected. I cannot agree to increase resolution. In addition,
I do not know how to get 2D texture. Can you explain me what to do?
But let me give another, more practical example of updown symmetric Moffett coins in a Stokes mode that can be found on
http://pleiades1.epfl.ch/~rgruber/opengl/aa20.png
Here, one sees that around the upper edge, the interpolation is acceptable, whereas at the lower edge, it is definitely wrong. Again, because the interpolation is not done symmetrically as it should.
the quads are 2 triangles your example is like this:
//
//
to get a “correct” result you must define two of your quads in the opposite order:
/
/
but it will work only in the case you are showing…
I think you don’t understand how interpolation works in OpenGL. Everything you draw is split into triangles.
When you see the mesh you posted in your first post as triangle mesh, the interpolation done by OpenGL is actually correct.
I don’t care how you insist on seeing the interpolation problem, or what you think should be fixed, OpenGL sees it the way I described, and that’s not going to change. That’s not a matter of right or wrong, it’s just a matter of perspective.
Linear 2D interpolation inside a quad is not well defined if the vertex data is not planar, it depends on the triangulation algorithm. Go fix your code before telling other people to change the library to match your expectations.
Oh, and I already told you how to fix the problem.
Originally posted by Overmind:
A better solution would be to use a 2D texture for the input values instead of specifying them per vertex.
Could you be a bit more specific? Would you use: (a) a single 2D texture, or (b) a separate 2D texture for each quad? If I am not mistaken, solution (a) will not give you linear interpolation along the quad’s edges, and (b) seems too expensive.
I mean a single 2D texture. Of course this will give you linear interpolation along the u and v axes in texture space.
For the inside of quads, it will give you the kind of interpolation that most people would expect as “the correct interpolation”, that is, a bilinear interpolation in texture coordinate space…
Originally posted by Overmind:
[b] I mean a single 2D texture. Of course this will give you linear interpolation along the u and v axes in texture space.
For the inside of quads, it will give you the kind of interpolation that most people would expect as “the correct interpolation”, that is, a bilinear interpolation in texture coordinate space… [/b]
Thanks for your answer. Maybe I haven’t yet understood this completely. I think  at least in the field of scientific computing  this is not the correct way to interpolate.
Let me explain how I would make use of a 2D texture and why it would not work: Take a perfectly square quad with normalized values at the quad’s vertices of 0.2, 0.2, 0.5, 0.5 (counterclockwise orientation, beginning from lower left):
0.50.5
 
 
 
0.20.2
Bilinear interpolation means for instance, that the values along the edges must vary in linear fashion. Let’s have a look at the midpoint of the edge going from the first vertex (value of 0.2) to vertex 2 (value of 0.2). The interpolated value at the midpoint is of course (0.2 + 0.2) / 2 = 0.2, as all values on this edge are.
The 2D texture, since it must be the same for any quad, would be a pixmap with the following values for the luminance at the corners:
^ ytexture coordinate

10
 
 
 
01> xtexture coordinate
(The luminance values inside the pixmap would be bilinearly interpolated from the corner values, and the values along the pixmap’s edges vary linearly).
With this, one can now determine the 2D texture coordinates at each vertex of the quad by finding the intersection point at the first, the second, the first, and the fourth edge of the pixmap:
^y

1(3)0
 (2)
(4) 
 
0(1)1> x
Vertex 1: (0.2, 0.0)
Vertex 2: (1.0, 0.8)
Vertex 3: (0.5, 1.0)
Vertex 4: (0.0, 0.5)
Going back to the first edge’s midpoint: Its 2D texture coordinates are
x: (0.2 + 1.0) / 2 = 0.6
y: (0.0 + 0.8) / 2 = 0.4
Looking up the luminance value in the 2D texture and using GL_LINEAR, the looked up and interpolated value will be 0.52, which is of course wrong, since it should be 0.2 for all points on that edge. Hence the values along the edges do not vary in linear fashion, but according to a quadratic function. Consequently, also the inside of the quad will not be rendered according to bilinear interpolation.
Maybe my way of setting up the 2D texture and determining the texture coordinates for the quad’s vertices is wrong. Do you know a better way?
cirrus2, what about using a much higher resultion 2D texture, that YOU fill in with whatever interpolation scheme you find suitable ?
The 2D texture, since it must be the same for any quad, would be a pixmap with the following values for the luminance at the corners: …
No. You have a pixmap with the following values at the corner:
0.5  0.5
 
 
 
0.2  0.2
You shouldn’t repeat the texture over every quad, you stretch it over the whole mesh. The minimum required resolution is such that each vertex corresponds to exactly one texel, but of course you can increase the quality by using a higher resolution texture…