In Conclusion

DirectX versus Doing It Yourself

At this point, you might be getting a sinking feeling as you begin to realize that much of the math you have just learned is actually rolled into a simple, easy to use API. This is mostly true, although I'd like to explain up front why it is still very useful to understand the math. It is true that DirectX has a higher-order surface API and it is supported by some pieces of hardware. However, there are downsides associated with having too much work done for you.

Note 

Although I don't cover it explicitly, OpenGL also has hardware and software support for higher-order surfaces. If you work with OpenGL, I would strongly recommend looking into the NURBS features.

There is a school of thought that says that you should understand everything that an API is doing before you use it. That is less true in some circumstances than in others and sometimes it becomes a religious debate that I don't really want to address. Looking at NURBS specifically , a deeper understanding of the mathematics can lead to much more effective usage of the API. For instance, many NURBS APIs take the surface order as a parameter. You need to understand how the order affects the surface before you can intelligently set the parameter. At the simplest level, most APIs allow you to set the control points. You can do that easily, but a deeper understanding helps you consider the effects of things like collocated control points and other nuances . In short, the parameters themselves are usually fairly low level. The more you know, the more effectively you can use a NURBS API.

One feature of some API calls is that they let the hardware do most of the work. You set an array of control points and the hardware creates the actual vertices. This can be very advantageous because you limit the amount of data that lives on the CPU. There is a downside to this. Imagine you have a NURBS object and you want to do collision detection. If you have the vertices, you can work with them in the collision detection calculations. Many classes could cause the "hidden" vertices to suffer. A few examples are shadow generation, picking, and collision detection.

If you needed the vertex data, but really wanted to take advantage of hardware surfaces, there is at least one way that you could have your cake and eat it too. You could send one set of control points to the card for hardware acceleration and use a second set for your calculations. This would require you to perform redundant calculations, but you could optimize the CPU calculations by remembering the fact that you don't need lighting values and other visible attributes.

Note 

Each of the samples in earlier chapters recomputed the vertex buffer with every frame because of the animation. Remember, you do not need to recompute the vertices if the geometry is static.

Of course, hardware acceleration has a downside in that some people might not have the hardware. In some cases, you might want to use DirectX patches, but fall back to your own methods if the hardware isn't present.

Finally, one difference between the DirectX API and your own code is the amount of control you have over the final shape. For instance, DirectX doesn't give you low-level control over knot values and other tweaks. In some cases, you might need to render a model as a set of patches rather than one complete object.

Remember, there are pros and cons to using any tool. Depending on your needs, you might find that you can easily get by with the DirectX surface API. Hopefully, a deeper understanding of the math lets you use it better. You might also find that you absolutely need the lower level of control or some of the other features of a do-it-yourself solution. It's not my place to try to push you in either direction. I just try to give you enough information to make good decisions.