|
TechnicalQuake
A Project for COMP-767 - Non-Photorealistic Rendering
|
Winter 2005
|
Final Presentation
Rebuilding edge information
After many hours of hard work building a complex data structure with information regarding the neighbouring surfaces of edges in the models, we discovered that the information was virtually useless. The models in Quake often contain degenerate triangles, edges with only on surface, and triangles with their three vertices speficied as the same point. Because of this our neighbouring information is garbage and we could not use it as we had hoped. The (tiny amount of) good news in all of this is that we no longer loose the 5 to 8 frames per second in performance since we no longer build the edge table.
Take home message: Quake's Models are Garbage!
Time Demo
|
demo1 |
demo2 |
demo3 |
bigass1 |
Edge
|
78.2 | 83.2 | 72.4 | 71.0 |
No edge
|
98.7 | 96.3 | 90.9 | 87.5 |
The results were obtained in 800x600 window mode NPRQuake, on a Pentium 4 2.66GHz with 512MB RAM and a GeForce4 Ti 420, running gentoo GNU/Linux.
Gooch Shading
We implemented Gooch shading on the models, which linearly interpolates between a cool (receding) and warm (advancing) color based on the light direction and the surface normals, according to the equation:
This reserves high and low luminance ranges for silhouettes and creases, thereby increasing shape comprehension.
This image illustrates the cool-to-warm tonal transition that keeps luminance constant.
Here we can clearly see that depth and shape cues are conveyed nicely from the shading.
The shape cues are retained in different lighting conditions.
Splashback
Splashback is an adaptation of the cool-to-warm Gooch shading that simulates the more dramatic effects sometimes used by artists. The effect is acheived when the reflected light from the left of the object produces a back-splash of light opposite the direct lighting source. We acheive this effect simply by adding the following multiplier to the Gooch shading color equation:
We see that the model shading appears more dramatic than in the earlier examples.
Silhouettes and creases - nice try
Silhouettes and creases are where we had the most problems. As mentioned above, we were unable to properly compute neighbouring information and we were also never able to find a proper camera vector. Every possible idea was exhausted in trying to find the eye position yet none proved fruitful. The point (0,0,0) was translated from world coordinates to model coordinates using the inverse MODELVIEW matrix from OpenGL to no avail. Vertices in the model were translated to world coordinates and we attempted to draw a line from them to the camera yet the result was diverging lines, not converging lines. In short, we were unable to properly compute silhouettes and creases in the manner in which we desired.
How a good idea can go wrong.
Compromise
Silhouettes
We implemented a silhouette algorithm that simply drew back-facing polygons with thick lines of the desired silhouette color. This is an improvement on the approach found in literature [1][2] where back-facing triangles are extended with GL_QUADS of a certain thickness because we do not have to draw an extra polygon consisting of 4 extra vertices for every polygon edge in the list of back-facing surfaces. These results are very good.
Silhouettes(black) are drawn here with a thickness of 4.
Creases
We implemented creases - all creases - by just drawing them for every edge. This is not particularly interesting, nor does it look very good so we made some observations about the idea of technical illustrations - especially within the realm of Quake:
- 1. White is sometimes too jarring (see screenshot above "How a good idea can go wrong") despite what Gooch tells us.
- 2. In fact, any color might be too jarring as the models shade/texture color varies over it's surface.
- 3. Models that are far away become a big jumbled mess of creases and we gain nothing in shape comprehension from this - in fact we might loose the ability to discern detail (see screenshot below "Creases Far Away).
Creases Far Away.
Having made these observations we implemented a two-pronged approach:
- shade creases the same color as the underlying model but with an added amount of white value, and
- fade this crease color into the underlying model color the farther away from the model the viewer gets.
This gave much more pleasing results that can be easily modified with user parameters to specify the white level to add and the distance at which the crease completely fade away. This same approach can be taken with silhouettes, which can also be jarring from long distances.
Creases That Fade with Distance.
Shadows
We draw soft drop shadows from the models by extending the very simple approach of projecting the model polygons onto a plane roughly at ground level. Our extension, aiming to implement the 'soft' shadows described in [1], involves three of these scaled model projections slightly offset from each other.
Simple shadows already implemented in NPRQuake.
Our soft drop shadows with a hard umbra and a hard penumbra.
Shadows help imply shape that is not visible.
We can clearly see the pole in hand just by looking at the shadow.
The entire left side of the monster model is implied by its shadow.
The user-configurable offset is set large here.
A large alpha value here.
A large offset value looks like two lights are casting shadow here.
A large scale value creates this gloomy, dramatic effect.
First, two projections are drawn, one offset in the positive y direction, and the other offset in the negative y direction, with an alpha value that is a fraction of the set shadow alpha value, roughly approximating a hard penumbra. If the offset is large, the model looks like it has shadows from two separate light sources. Then, the umbra is drawn in the full alpha value, scaled down so that it is smaller than the 'penumbra' shadows. Each projection is drawn with a slightly different depth so as to reduce flicker, as opengl becomes confused when several polygons with alpha values are drawn on top of each other at the same depth.
The shadow alpha and color are configurable parameters, as is the scale factor of the shadow and the offset for the penumbra projections.
The approach is not exactly accurate, and will result in shadows that look rather unnatural in some circumstances: the shadows will 'float', for example when the model is on a step and the shadow is cast off the step, and the shadows will disappear into a wall instead of being cast onto the wall. However, we feel that the approach yeilds fairly realistic-looking soft shadows.
User Definable Parameters
To facilitate the exploration of various technical effects such as fading creases, cool-to-warm shading, and silhouette width, we added many user definable parameters to the system that change the look and feel of the 3D rendering system in realtime.
- tech_shade_model - allows turning shading on or off. Default to on (1)
- tech_shade_model_mode - Set to '1'(default) for regular cool-to-warm shading, and '2' for splashback, or '0' to turn shading off, rendering models in solid color.
- tech_antialias - turns antialiasing of creases/silhouettes on or off.
- tech_sil_width - controls the line width of silhouettes.
- tech_sil_mode - controls whether silhouettes are drawn or not.
- tech_sil_color - allows the user to set the silhouette color.
- tech_sil_depth - specifies the distance at which silhouettes fade out completely. If zero, no fading.
- tech_crease_mode - allows turning creases on or off.
- tech_crease_depth - specifies the distance at which creases fade out completely. If zero, no fading.
- tech_crease_color - allows the user to set the crease color.
- tech_crease_width - controls the line width of creases.
- tech_color_thresh - sets a color amount to be added to crease lines (for fading)
- r_shadows - set to '1' to turn on shadows (not on by default)
- tech_shadows - If set to '1' (default), draw soft 'tech' shadows (hard umbra and hard penumbra). If set to '2', draws a single hard shadow. If set to '0', draws boring shadows.
- tech_shadow_offset - the offset of the attenuated shadow from the baseline shadow
- tech_shadow_scale - This factor determines how much the size of the shadow differs from the size of the model
- tech_shadow_color - the color of the tech shadow, specified in hex rgb
- tech_shadow_alpha - From 0.0 (invisible shadow) to 1.0 (hard shadow), controls the alpha value of the shadow color
- tech_wall_color - Set the wall color as an RGB hex (ie 0xFF0000 = red)
- tech_wall_line_color - Set the wall line color as an RGB hex (ie 0x0000FF = blue)
- tech_water_color - Set the water wall color as an RGB hex (ie 0x00FF00 = green)
Project References:
[1] Bruce Gooch, Peter-Pike J. Sloan, Amy Gooch, Peter Shirley and Richard Riesenfeld. Interactive Technical Illustration. Symp on Interactive 3D Graphics, 1999
[2] Ramesh Raskar. Hardware Support for Non-photorealistic Rendering. In Graphics Hardware, 2001
[3] Amy Gooch and Bruce Gooch and Peter Shirley and Elaine Cohen. A Non-photorealistic Lighting Model for Automatic Technical Illustration. ACM Siggraph '98 Conference Proceedings, 1998
[4] Alex Mohr, Erik Bakke, Andrew Gardner, Christopher Hennman, and Steve Dutcher. NPRQuake at http://www.cs.wisc.edu/graphics/Gallery/NPRQuake/whoWeAre.html
[5] ID Software. Quake 1 Source Code. At http://www.idsoftware.com/business/techdownloads/
[6] Adrian Ilie. COMP 238 Final Project: Non-Photorealistic Rendering Techniques for a Game Engine. At http://www.cs.unc.edu/~adyilie/comp238/Final/Final.htm
[7] Adam Lake, Carl Marshall, Mark Harris, and Marc Blackstein. Stylized rendering techniques for scalable real-time 3d animation. Proceedings of NPAR 2000, 13--20
[8] Olivier Montanuy. Unofficial Quake Specifications version 3.3 at http://www.gamers.org/dEngine/quake/spec/quake-spec33/qkmenu.htm. 1995, 1996
COMP-767 - Advanced Topics in Graphics: Non-Photorealistic Rendering