NURBS and it's Performance

[ganesh]

:confused: hi,

i use opengl from last 3 months in VC++, i have one problem regarding NURBS, i created NURBS of 3000 x 3000 wide. and i want display a result on the area of 3000 x 3000, 2000 x 2000,
1000 x 1000.... but result must be same object it just look like a zooming effect of object.

so for that i keep the ortho of the all area same that is 3000 x 3000 it gives me expected result but problem is speed of rendering object
I thought that if area is small to draw then exection time may fast but it does not work. it take approxmitly same time to rendering in the areas i want fast speed if area is small what can i do ?

i also try by using display list

[jide]

Nurbs are generally not accelerated by the hardware. Also, you seem to consume quiete a lot of fillrate. That's why everything is slow.

What can you do ? Maybe simply by drawing the faces of the surfaces directly (so you precompute the nurbs once, then get the faces, then draw them).

Try to use display lists or vertex arrays.

[tamlin]

Another idea (even that it could waste serious amounts of memory) could be to u/l the 3k*3x vertex data and use a 3x stride for the 1k versions.

However, as has been experienced by many, current hardware seemingly is optimized only to access 64K vertices/VBO, and going int-sized indices can take a serious perfomance hit (even in h/w).

If you have integer-based zoom-levels, and the data is indeed in a "grid" form, I think something to test could be:

If you have f.ex. the zoom-levels 1-10; check first the primes making up 10 (and the smaller ones). You end up with 1*2*3*5*7 = 210. You then need a buffer where one "side" is an exact multiple of 210. As we "know" the "limit" of a fast VBO is 64K (256^2), you use 210^2 as VBO size.

Then tile and store data as needed.

(note: I don't know what hardware has the effective 64K vertex limit, and until vendors start telling us what the hardware limits are of their respective implementations...)