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} |
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 |
|
|
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 |
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 |
|
|
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} |