NURBS

ild recommend creating the nurbs (or other curves) yourself, (personally i find nurbs hard to work perhaps some other curves suit better?)
and just passing the resulting vertices to gl. i believe the glu (nurbs ) stuff is not accelerated, its also hasnt been mantained in a while.
no doubt there are better libraries on the internet out there.

Hi,

I'm just after doing a NURBS app. I used the GLU NURBS facility, i think it is accelerated, I wouldn't see any reason why it wouldn't be. My NURBS bricks are fairly fast when deformed. U can always increase the rendering threshold to improve performance. The GLU NURBS surfaces seem to have dynamic level of detail when rendered, i.e. their quality improves when closer to the camera.

For OpenGL NURBS, check out the Red book, it has a good example, it's what I started from. There is an online version avaliable for free.

Also Google NURBS to find out what the different parts are used for.


Just as a note, I think your X,Y,Z interpretation is wrong. Its more like
nurbsSuface[nurbsSurfacewidth][nurbsSurfaceHeight][x][y][z] - i.e. a 2D grid of vectors(x,y,z).

gluNurbs is NOT accelerated.

Just out of interest cos I use NURBS with OpenGL. Are evaluators not accelerated? GLU NURBS are are built on top of these. When using

gluBeginSurface(...);
gluNurbsSurface(...);
gluEndSurface(...);

Is that not akin to calling glBegin(..) glEnd(..), the primitives which are drawn to create the NURBS surface, are they not accelerated also?

the triangles drawn are accelerated (the same as glBegin), however the surface calculation is NOT accelerated. No graphics card available has hardware accelerated NURBS calculations. GL evaluators are NOT hardware accelerated on any graphics card currently available. The glu nurbs is possible the least efficient rendering API you coud find for nurbs surfaces. Every frame it evaluates all the blending co-efficients, which is very slow (and not needed since you can cache them, however glu nurbs always re-evaluates them). Hardware acceleration of any parametric curve or surface is always going to be a very bad idea, so don't expect it anytime soon.

When u say: blending co-efficients, do you mean surface normals? Why would evaluation or curves on hardware be bad?

Just out of curiosity.

Thanks.

Quote:

Original post by Cacks When u say: blending co-efficients, do you mean surface normals?

No, look into Nurbs surface generation and you will find the cox-de-boor algorithm that is used to generate the blending co-efficients used to tesselate the surface points. For example, a bezier curve :

P(t) = B0(t)*P0 + B1(t)*P1 + B2(t)*P2 + B3(t)*P3;

where

B0(t) = (1-t)^3
B1(t) = 3*t*(1-t)^2
B2(t) = 3*t^2*(1-t)
B3(t) = t^3

The cox-de-boor calculates these recursivly for a nurbs surface....

Quote:

Why would evaluation or curves on hardware be bad?

the cox de- boor algorithm is extremely slow due to it's recursive and rather intensive nature. gluNurbs does not use this directly, instead it splits all Nurbs surfaces into seperate bezier patches, which are then tesselated into triangles and, as a final step, the normals are calculated. It does this every single frame!

For both bezier patches and nurbs surfaces, you can get extremely good performance (ie, they out perform polygon meshes) if you cache the only expensive part of the computation, the blending co-efficients! This caching only needs to take place when the LOD of the surface changes.

Basically, you will NEVER be able to create a hardware implimentation of Nurbs or any other parametric surface that will ever be faster than a cached software implimentation. You will notice that nvidia realised this which is why the NV evaluator extension got removed from their drivers....

GLU NURBS seem to use:

degree + number of control points + 1 knots.

whereas other sources declare the amount of knots for NURBS to be:

degree + number of control points - 1 knots.


What is the difference? Y the extra 2 knots?

Also, does the maximum multiplicity of a knot in OpenGL = degree+1? As opposed to degree times?

Thanks

Quote:

degree + number of control points + 1 knots.

GL uses this one.

Quote:

whereas other sources declare the amount of knots for NURBS to be: degree + number of control points - 1 knots. What is the difference? Y the extra 2 knots?

Yes, they are just being overly annoying. The theory goes that the first and last knot is not needed to evaluate the curve, since they never have an effect on the curves shape. Maya stores nurbs this way, you just have to duplicate the first and last knot values when passing into openGL.

Quote:

Also, does the maximum multiplicity of a knot in OpenGL = degree+1? As opposed to degree times?

degree+1

When reading some sources I see that each Control point has an associated weight. Is this weight the 3d vector representing the control points position? Or have I misunderstood this?


Thanks for the help!