The evaluators in OpenGL are completely insane, and highly in-efficient. Use maths, and the problem is substantially easier....



template<typename T>
T lerp(const T& a, const T& b, float t)
{
return a + (b-a)*t;
}
template<typename T>
T evalCubicBezier(const T& a, const T& b, const T& c, const T& d, float t)
{
const T AB = lerp(a, b, t);
const T BC = lerp(b, c, t);
const T CD = lerp(c, d, t);
const T ABBC = lerp(AB, BC, t);
const T BCCD = lerp(BC, CD, t);
return lerp(ABBC, BCCD, t);
}

Interesting, but why do you think the evaluators in OpenGL are bad?

On the SGi machines back in the mid 90's they were seen as pretty radical, and SGi optimised the hell out of their implementation (a 200Mhz SGi could wipe the floor with a 1Ghz PC + Geforce 1 when using evaluators). There has never been a Geforce/Quadro/Ati card that has ever provided hardware support for the functionality, and there never will be. On the geforce3, Nvidia added nvEvaluators in hardware, but they were had the same failings as glEvaluators, and support was quietly dropped from the drivers.

glEvaluators forces you into a complete re-evaluation of the curve/surface at every possible opportunity. As soon as your scene progresses to something relatively complex, the CPU overhead really starts hurting! It's just insane that you can draw exactly the same curve, with the same tessellation each frame, and still be forced to re-evaluate the data. Re-evaluating only when the LOD changes makes much more sense these days (and upload the data into a VBO).

Basically my distaste for glEvaluators can be summed up with this:


struct CubicBezier
{
public:

void setLod(int lod)
{
m_lod = lod;
m_blends.resize( (lod+1) * 4 );
m_outPoints.resize( lod + 1 );

float increment = 1.0f / lod;
for(int i=0, j=0; i<=lod; ++i, j+=4)
{
float t = increment * i;
float invt = 1.0f - t;

float B0 = invt*invt*invt;
float B1 = 3.0f*invt*invt*t;
float B2 = 3.0f*invt*t*t;
float B3 = t*t*t;

m_blends[j ] = B0;?
m_blends[j + 1] = B1;?
m_blends[j + 2] = B2;?
m_blends[j + 3] = B3;?
}
}

void tesselate()
{
for(int i=0, j=0; i<=m_lod; ++i, j+=4)
{
m_outPoints =
m_points[0]*m_blends[j ] +
m_points[1]*m_blends[j+1] +
m_points[2]*m_blends[j+2] +
m_points[3]*m_blends[j+3];
}
}

private:

Vector3 m_points[4];
std::vector<float> m_blends;
std::vector<Vector3> m_outPoints;
int m_lod;
};


This separation of blending function calculation, and tessellation, doesn't make too much sense for a cubic bezier curve (because it's not an overly complicated process). However if you switch to a more complex curve type (i.e. the cox-de-boor evaluation of a NURBS curve is a massive killer!), or if you transition to using bezier patches (tri strip indices, uv coords, colours, etc, can all be calculated in the setLod method), you can get some seriously insane speed improvements for animated curves and surfaces....

Basically there are tonnes and tonnes and tonnes of optimisations possible in C++/OpenGL, but they all vanish as soon as you use glEvaluators. Some of the tricks I've used in the past have involved creating 'lod change' queues which tries to schedule changes in lod for the curves over a number of frames (i.e. If 500 curves need to have their lods changed, you can do 50 per frame. 10 frames later it'll all be done, but the frame rate stays constant).

Will I have to draw curves 9000, do you think will be very slow?
[/quote]
It depends on what form of tessellation you want to use. If it's as done here and in your code, then it will be fine (you could generate blending function values for specific lod values and share them between curves if it gets too hairy). If it's based upon viewing distance, and the 't' values use non linear increments, then it may get a bit interesting. Using a geometry shader may help*.

* with a caveat... most GPUs have an upper limit of the amount of vertices you can generate in a geometry shader. IIRC it's about 128 verts for vertex+colour.