/[gzz]/manuscripts/AniFont/anifont.tex
ViewVC logotype

Diff of /manuscripts/AniFont/anifont.tex

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.8 by tjl, Fri Oct 10 14:05:37 2003 UTC revision 1.9 by tjl, Tue Oct 14 13:01:26 2003 UTC
# Line 9  Line 9 
9  \maketitle  \maketitle
10    
11  \begin{abstract}  \begin{abstract}
12      We show...  We demonstrate a counterintuitive hardware-accelerated
13    rendering trick:
14    when rendering an isotropically textured 2 1/2D scene,
15    stretching an image when putting it into a texture
16    and squishing it with texture coordinates when rendering yields
17    a slightly but significantly better
18    image quality than simple trilinear filtering when hardware
19    anisotropic filtering is enabled.
20    We show a simple way to understand why this trick works, and discuss
21    various generalizations. We show examples of text rendered both ways.
22    
23    As background for the trick, we discuss harware anisotropic
24    texture filtering and show
25    how to probe the filters to understand their function, paying
26    attention to what assumptions have to be made for such probing to work.
27    
28    
29  \end{abstract}  \end{abstract}
30    
31  \section{Introduction}  \section{Introduction}
# Line 28  Recently, ... Line 44  Recently, ...
44  - basic anisotropic solution: more samples from the mipmaps than the 8 used for  - basic anisotropic solution: more samples from the mipmaps than the 8 used for
45    trilinear - better approximation of EWA. Modern graphics cards support up to XXX samples    trilinear - better approximation of EWA. Modern graphics cards support up to XXX samples
46    
47    - Unextended OpenGL aniso: article on using lod bias etc to get it
48    
49    - supersampling: FSAA / as above; however, most cards focus on multisampling, not supersampling -
50      no help for textures
51    
52  - Graphics companies unfortunately do not provide ...  - Graphics companies unfortunately do not provide ...
53    
# Line 41  Recently, ... Line 61  Recently, ...
61    
62  The rest of the article is organized as follows.  The rest of the article is organized as follows.
63    
 \section{Probing hardware anisotropic filters}  
 \label{secprobing}  
   
 In this Section, we  
   
 This seems to be a well-known technique that has not so far been published  
 anywhere  
   
 Digit-life XXX NVIDIA, ATI patterns  
   
 - for careful work, you'll want to know what your driver is doing  
   
 \begin{figure*}  
 a) \includegraphics[width=5cm]{probe.2}  
 b) \includegraphics[width=10cm]{probe.1}  
 c)  
 \caption{  
 \label{figanisoprobe}  
 a) Example probe textures for the three smallest mipmap levels.  
 Each texture has a single white texel at a single mipmap level, the rest of the texels  
 and mipmap levels being gray.  
 b) The pixel-sized quads using textures such as the ones in a) to give  
 the contributions of each texel to a particular quad. All quads are rendered  
 with the exactly same texture coordinates and vertex coordinates relative  
 to the pixel.  
 c) An example image produced by such quads: how the XXX card  
 samples the mipmap levels in XXX aniso XXX  
 }  
 \end{figure*}  
   
 - difficulty in probing hardware: each free variable grows number of probes to make  
   exponentially - have to make as strict assumptions as possible  
   
 - ASSUMPTIONS:  
   driver not detecting software and applying different rules, driver  
   not changing algorithm for screenshot images / moving images,  
   driver not looking at texture images and deciding filtering  
   algorithms based on that (image-sensitive filters).  
   (can use linear algebra to do this then).  
   Filters are linear (nonlinearities in the filters - to our knowledge none yet; gamma correction?).  
   
 - SEMI-ASSUMPTIONS (trivial to adjust algorithm): all texture units produce  
   the same results (in some drivers, this is not the case - 3dcenter about nv 51.XX series  
   DirectX),  
   Driver isn't using a different set of samples for large and small triangles,  
   e.g. NV patent describing using lower mipmap level!  
   pixel translation invariance, in screen space.  
   
 - define separate texture $T_{(k),x,y}$ for each texel of each  
   mipmap level, with exactly one light  
   texel at the point $(x,y)$ of that mipmap level, all other texels and mipmap levels middle gray  
   (we define level $(n)$ to be the 1x1 texture, ${n-1}$ to be the 2x2 texture etc.  
   Non-square mipmap hierarchies are a simple generalization)  
       
     - gray so we see also if there are negative weights in the filter!  
   
 - select the texture coordinates for a single-pixel quad for which you want  
   to see contributions.  
   In reality, only a triangle gets used so these should be linearly obtained  
   from three coordinates but it's still easier for a human to understand these  
   as quads...  
   
 - For each mipmap level texel, render a one-pixel quad,  
   with the same texture coordinates and  
   
 - Resulting image gives contribution from each texel on a mipmap level  
   to the final image, PROVIDED ASSUMPTIONS HOLD.  
   
 - the single-texture quads (or values read from screen) can then be used  
   in other visualizations  
   
 - utility in our free software OpenGL libvob system  
   
   
   
 A similar technique appears to be used more commonly used for probing hardware  
 antialiasing patterns, (XXX should we?).  
   
 - assumptions about the contents of the mipmap levels  
   
     - aniso filter might compute trilinear samples using only one level, etc.  
       
     - for analysis, the contribution of one texel could be represented  
       as the contribution of four texels on a higher mimap level as per  
       the assumption of generating the mipmap levels in the usual way  
   
   
64  \section{Surprise: stretch-squish can yield better images in orthogonal transformations}  \section{Surprise: stretch-squish can yield better images in orthogonal transformations}
65    
66  - case we consider: sharp edges, orthogonal (or nearly so) transformations, e.g. text  - case we consider: sharp edges, orthogonal (or nearly so) transformations, e.g. text
# Line 196  Magnified examples of text filtered usin Line 129  Magnified examples of text filtered usin
129    the result significantly    the result significantly
130    
131    
132    
133  \section{Conclusion}  \section{Conclusion}
134    
135  - described how hardware implementations of anisotropic filtering can be probed  - described how hardware implementations of anisotropic filtering can be probed
136    for better understanding    for better understanding
137    
138    - NV's fragment program TXD really useful
139    
140  - showed how, when orthogonal transformations, anisotropic filtering in the hardware  - showed how, when orthogonal transformations, anisotropic filtering in the hardware
141    can still be useful - a trick we haven't seen used elsewhere    can still be useful - a trick we haven't seen used elsewhere
142    
# Line 223  Seveeral aspects we did not touch Line 159  Seveeral aspects we did not touch
159    
160  \section{Acknowledgments}  \section{Acknowledgments}
161    
162    \appendix
163    \section*{Appendix}
164    
165    \section{Probing hardware anisotropic filters}
166    \label{secprobing}
167    
168    In this Section, we
169    
170    This seems to be a well-known technique that has not so far been published
171    anywhere
172    
173    Digit-life XXX NVIDIA, ATI patterns
174    
175    - for careful work, you'll want to know what your driver is doing
176    
177    \begin{figure*}
178    a) \includegraphics[width=5cm]{probe.2}
179    b) \includegraphics[width=10cm]{probe.1}
180    c)
181    \caption{
182    \label{figanisoprobe}
183    a) Example probe textures for the three smallest mipmap levels.
184    Each texture has a single white texel at a single mipmap level, the rest of the texels
185    and mipmap levels being gray.
186    b) The pixel-sized quads using textures such as the ones in a) to give
187    the contributions of each texel to a particular quad. All quads are rendered
188    with the exactly same texture coordinates and vertex coordinates relative
189    to the pixel.
190    c) An example image produced by such quads: how the XXX card
191    samples the mipmap levels in XXX aniso XXX
192    }
193    \end{figure*}
194    
195    - difficulty in probing hardware: each free variable grows number of probes to make
196      exponentially - have to make as strict assumptions as possible
197    
198    - ASSUMPTIONS:
199      driver not detecting software and applying different rules, driver
200      not changing algorithm for screenshot images / moving images,
201      driver not looking at texture images and deciding filtering
202      algorithms based on that (image-sensitive filters).
203      (can use linear algebra to do this then).
204      Filters are linear (nonlinearities in the filters - to our knowledge none yet; gamma correction?).
205    
206    - SEMI-ASSUMPTIONS (trivial to adjust algorithm): all texture units produce
207      the same results (in some drivers, this is not the case - 3dcenter about nv 51.XX series
208      DirectX),
209      Driver isn't using a different set of samples for large and small triangles,
210      e.g. NV patent describing using lower mipmap level!
211      pixel translation invariance, in screen space.
212    
213    - define separate texture $T_{(k),x,y}$ for each texel of each
214      mipmap level, with exactly one light
215      texel at the point $(x,y)$ of that mipmap level, all other texels and mipmap levels middle gray
216      (we define level $(n)$ to be the 1x1 texture, ${n-1}$ to be the 2x2 texture etc.
217      Non-square mipmap hierarchies are a simple generalization)
218        
219        - gray so we see also if there are negative weights in the filter!
220    
221    - select the texture coordinates for a single-pixel quad for which you want
222      to see contributions.
223      In reality, only a triangle gets used so these should be linearly obtained
224      from three coordinates but it's still easier for a human to understand these
225      as quads...
226    
227    - For each mipmap level texel, render a one-pixel quad,
228      with the same texture coordinates and
229    
230    - Resulting image gives contribution from each texel on a mipmap level
231      to the final image, PROVIDED ASSUMPTIONS HOLD.
232    
233    - the single-texture quads (or values read from screen) can then be used
234      in other visualizations
235    
236    - utility in our free software OpenGL libvob system
237    
238    
239    
240    A similar technique appears to be used more commonly used for probing hardware
241    antialiasing patterns, (XXX should we?).
242    
243    - assumptions about the contents of the mipmap levels
244    
245        - aniso filter might compute trilinear samples using only one level, etc.
246        
247        - for analysis, the contribution of one texel could be represented
248          as the contribution of four texels on a higher mimap level as per
249          the assumption of generating the mipmap levels in the usual way
250    
251    
252  \end{document}  \end{document}

Legend:
Removed from v.1.8  
changed lines
  Added in v.1.9

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26