I think that opengl should start putting more importance on these because they offer a simple solution to the bottleneck problem of the computer systems these days. A few control points and voila, you have a superb looking surface.
Obviously, vendors must incorporate this stuff on the GPU otherwise whats the point of having things done in software mode and have primitives sent over the bus as usual.
One suggestion I could make is to have the ability to transform a single control point, have vertex blending (control point blending) matrices and all the rest.
V–Man, imo opengl is putting enough importance on it. If you want you can draw everything yourself. But I guess trading die space for a function that is quite inflexible and has many problems (texture coordinates, surface connectivity, connected surface edges) isnt that good.
When you say higher order surfaces, do you mean a shape such as a sphere rendered w/polygons that are tessalted, or a sphere that is entirely based on its equation? If you mean the latter, I think its about time! I mean, why not–isn’t the technology here?
I’ve been working on a function that would do this. For example, a call to construct a sphere might look somthing like this: glDrawVolume(2, 2, 2), where the twos stand for x squared, y squared, and z squared respectively–with no xy, xz, or yz terms in the equation. And glLimitVolume(xlower, xupper, ylower, yupper, zlower, zupper) would limit the primitive being rendered (How else would OpenGL know when to stop rendering a hyperbaloid?). Using error accumulation, along with the derivative would prevent “holes” from appearing in places. The function would only draw functions around the origin, and not rotated–as matrices could adjust for this!
As far as lighting goes, all that would be nessecary is to compute the the normal to the equation, and voila! All that’s needed are the derivatives!
Originally posted by Olive: The question of texture coordinates is probably the trickiest thing to solve. How do you send them?
You don’t send anything. You have opengl generate them in tangent space (basic need) and also manipulate the texture with the texture matrix or use TexGen.
Connectivity is a problem that you solve your self using the control points. If the same texture must flow over several HOS, then again, you have to deal with it.
Also, it doesn’t mean we cant have a low level method of doing things for example if you wanted to compute the tex coordinates yourself, you fill in a array and you pass it with a call
glTexCoordPointerHOS(component, type, stride, pointer)
glEnableClient(GL_TEX_COORD_HOS);
but that would be against the idea of minimum traffic over the buses.
