sponsors gamedev.net search:

Speed and Quality Figure 4 shows a frame-rate comparison using a 64 megabyte Radeon 9000 mobile card.  As you can see, the speed of the painter is highly-dependant on the number of triangles in the scene.  In the worst case, its speed is 67% of the speed of rendering the same polygons normally.  The initial rendering of the inker is similar in speed to painter, but there is a consistent speed loss for each quad that is overlaid on the screen.  This loss is about 4 ms per frame at 800x600 and about 17 ms per frame at 1280x1024.  The results from this card are completely acceptable at 800x600 with the shading, outlining, and dilation turned on, and the results are passable at 1280x1024. 800 x 600   40,000 poly model 26,000 poly model 1200 poly model Untextured Polygons 187 fps 232 640 Painter 137 173 555 Inker 91 104 150 Inker + Dilation 67 72 94 Painter + Inker 56 68 140 Painter + Inker + Dilation 46 53 89 1280 x 1024   40,000 poly model 26,000 poly model 1200 poly model Untextured Polygons 128 fps 134 250 Painter 87 91 220 Inker 35 36 43 Inker + Dilation 22 22 25 Painter + Inker 27 28 41 Painter + Inker + Dilation 19 19 24 Figure 4:  The above results were obtained using a 64 megabyte Radeon 9000 Mobile graphics card in a laptop with a 3.06 GHz processor and 512 Megabytes of RAM Figure 5 shows a couple of screenshots from the cartoon renderer we have developed.  As you can see, the results are quite satisfactory. There are only two potential problems with the quality of our renderer.  First, lines will occasionally disappear or reappear as we move around a model.  This is due to new pixels coming into view and therefore new edges appearing that were not visible in the previous frame.  Second, the shadow-boundaries generated by our painter can appear a bit fuzzy.  It is a matter of preference as to whether these soft edges improve or worsen the look of the renderer. Figure 5: Screenshots from the demo program illustrating the high-quality achieved by the Cartoon Renderer. As a whole, the results are far better than the results I have seen from other methods.  In my opinion, the renderer is powerful enough to be used in a commercial game in its current incarnation, and any improvements that are made to it would simply be icing on the cake. Future Refinements While quite powerful in its own right, there is no doubt that further additions could be made to the cartoon renderer we have developed in this article.  One possible modification would be to change our painter to use point lights instead of directional lights.  To accomplish this it would be necessary to implement light-falloff and brightness calculations inside the vertex program.  The light direction vector would need to be scaled inside the vertex program as well. Another fascinating addition would be to create varied line-styles for the inker.  This could be accomplished by rendering the lines onto something other than a simple quad.  For example, one could use a 16x16 mesh of quads that could be perturbed according to some semi-random calculations in a vertex program.  This could give a sketchy look to the lines, as they would move slightly each frame.  Other interesting line-styles are made possible by replacing the "dilation" pixel program.  We have only used this second pixel program to thicken the line, but one could also change look of the ink lines by offsetting individual pixels or changing their colors. Conclusion Our cartoon renderer gives us freedom in the look of our painting, even allowing us to use different highlighting depending on light brightness. It also has the flexibility to completely change highlighting schemes by switching out a single texture.  It supports two, colored, per-pixel lights that can have varying brightness. Our outlining algorithm supports depth-based lines, automatic edge and crease lines, as well as artist-specified lines.  All of these lines are rendered with a consistent style and can be drawn in varying widths and even smoothed. This all adds up to possibly the most robust cartoon renderer developed to date, and it runs on all Direct-X 8.0 compatible hardware.  It will even work on an X-Box!  I would love to see the techniques described in this article implemented in a commercial game.  We need to break the monotony of run-of-the-mill "realistic" graphics that are so prevalent in today's entertainment software.  If anyone has questions regarding the cartoon renderer or any improvements that they wish to share, please contact me at vishvananda@yahoo.com. For Further Information Most of the papers referenced below can be found at the Citeseer website at http://citeseer.nj.nec.com. You can also find more information included with the demo program here. [1] J. Claes, F. Di Fiore, G. Vansichem, F. Van Reeth. Fast 3D Cartoon Rendering with Improved Quality by Exploiting Graphics Hardware. 2001 [2] A. Lake, C. Marshall, M. Harris, M. Blackstein. Stylized Rendering Techniques for Scalable Real-Time 3D Animation. 2000. [3] J. Buchanan, M. Sousa. The edge buffer: A data structure for easy silhouette rendering. 2000 [4] R. Raskar. Hardware Support for Non-Photorealistic Rendering. 2001. [5] NVIDIA's Vertex Toon Shader  http://developer.nvidia.com/object/Toon_Shading.html [6] J. Mitchell, C. Brennan, D. Card. Real-Time Image-Space Outlining for Non-Photorealistic Rendering. 2002. http://mirror.ati.com/developer/SIGGRAPH02/NPROutlining_Mitchell.pdf

Contents   Introduction   The Evolution of a Cartoon Renderer   Speed and Quality   Source code   Printable version   Discuss this article