Testing and Optimization

These steps go hand in hand with implementation. They are actually weaved into a loop where you code, test, and optimize over and over until you get the results you are looking for. This stage might take a long time while you find out whether your code actually works and while you constantly ask yourself how to make things faster or simpler. It is very beneficial to have a formal beta testing stage in which you provide the shader to a limited number of users so that they can use it in a production environment. Be sure to let them know that the shader is still in beta stage and not to use it for final objects.

Having input from users will usually reveal bugs, misbehaviors, and sometimes design deficiencies. As the shader writer, you might have done something that makes perfect sense to you because you know the “insides” of the shader quite well, but when a user tries to use a feature you implemented, it behaves in a way that is not expected. At that point you might have to reconsider your implementation. Talk to other users and ask if they also get the results the first user did. If they do, then you will have to do some recoding.

At this stage you will also receive a lot of “it would be really cool if the shader could do...” requests. Take your time looking at these requests because many of them might create problems down the line or send you into a complete recode of your shader. Make a list and prioritize the requests, discuss them with your direct supervisor, and implement only those that are absolutely necessary. This level of selectiveness is not so that we have less work to do, it is simply because the larger the amount of code, the higher the probability for bugs to show up. Once all the changes are made to the code, release the shader to the same limited number of users and let them use it once more as a beta version. Repeat these steps until you are sure that your code is working and optimal for production work, at which point you should get it ready for release.