Painters, isosurfaces and API design

Hi,

I was just thinking about how best to deal with our new isosurfaces within the
painter framework. The IsoGen class could do with access to its painter when
it is initialised and so I was going to replace stepSize with a
PainterDevice. That way it can access the painters quality level and use that
to determine an appropriate step size.

I was also thinking of adding a new drawTriangles function to the painters. I
thought this would take a Triangle list along with a normal list. It possibly
also needs an optional colour list so that people can map on a colours to the
isosurface as Tim already has in the surface engine.

So two new functions taking the forms,

void drawTriangles(QList triangles, QList normals);
void drawTriangles(QList triangles, QList normals,
QList colors);

Would the triangle struct be best placed in painter.h, along with possibly a
triangleColor struct with three colour points? I will be fixing the IsoGen
class to make it a little safer and give it set and get functions so that I
can protect its internal variables. POV-Ray can accept triangle meshes too
and so surfaces should be easy enough to move into that painter too.

I am currently recompiling after todays changes and making a blog post with
screenshots on the new orbital engine and what it can do. I would appreciate
your thoughts on my new API proposals.

Thanks,

Marcus

also needs an optional colour list so that people can map on a
colours to the
isosurface as Tim already has in the surface engine.

I think what we need is a ColorGradient class, which returns a color
given a value, e.g.

class RedGreenBlueGradient: public ColorGradient

void setMinValue(double);
void setMaxValue(double);

QColor valueToColor(double value);

triangleColor struct with three colour points?

I think we’ll want to have more than just three color points. For one,
I like to see different color schemes (red for negative, white for
neutral, blue for positive). For another, some surfaces or properties
may need 2, 3, 4, … color gradients.

It’s much better if we can let people extend this – much like what I
did with the Color classes.

Cheers,
-Geoff

On Tuesday 19 February 2008 20:40:56 Geoffrey Hutchison wrote:

also needs an optional colour list so that people can map on a
colours to the
isosurface as Tim already has in the surface engine.

I think what we need is a ColorGradient class, which returns a color
given a value, e.g.

class RedGreenBlueGradient: public ColorGradient

void setMinValue(double);
void setMaxValue(double);

QColor valueToColor(double value);

That could be useful and added as another function I think. What would value
be though? So you would want to supply a list of values along with the
triangles? The painters are an abstraction but I think that code might belong
in the engine so that the painters can remain a thin abstraction layer on top
of POV-Ray and OpenGL.

triangleColor struct with three colour points?

I think we’ll want to have more than just three color points. For one,
I like to see different color schemes (red for negative, white for
neutral, blue for positive). For another, some surfaces or properties
may need 2, 3, 4, … color gradients.

It’s much better if we can let people extend this – much like what I
did with the Color classes.

A triangle can only have three colour points - one for each vertex. At some
point it will be set in this way and we can obviously make smaller triangles
to give smoother gradients. I was proposing this could be used as a third
argument to give a color for each vertex of each triangle when drawing a
mesh.

I think in general for caching and efficiency it would be nice to have some
kind of colour list to go along with vertices rather than recomputing each
frame. Not sure on the best API for this though and something along the lines
of what you are proposing would also be useful I think.

Thanks,

Marcus