程序代写代做代考 10: The OpenGL Pipeline

10: The OpenGL Pipeline

10: Texture Storage

COMP5822M: High Performance Graphics
Spatial Anti-Aliasing

COMP5822M: High Performance Graphics
What Is Happening?
Perspective increases background frequency
No longer band-limited
Result: Moire patterns / aliasing

COMP5822M: High Performance Graphics
Point Sampling

Point sampling is best if it’s dense
Perspective causes frequency to decrease

COMP5822M: High Performance Graphics
Correct Solution
Integrate the light over patches
But this wastes samples on background

COMP5822M: High Performance Graphics
Approximation
Compute patches at half resolution
Repeat recursively
Mipmaps = multum in parvum maps

COMP5822M: High Performance Graphics
Improvement
Choosing transition range is important
And you never quite get it right
So how to make it less abrupt?

COMP5822M: High Performance Graphics
Trilinear Mipmapping
Identify two ranges (distances) near, far

Parametrise pixel distance as:

Use bilinear interpolation twice
Then interpolate between the two colours
Result: trilinear interpolation

COMP5822M: High Performance Graphics
Trilinear Interpolation

Same idea as before, but repeated three times
Development is similar

COMP5822M: High Performance Graphics
Trilinear Equation

COMP5822M: High Performance Graphics
Solution

Bilinear Mipmapping
Trilinear Mipmapping

COMP5822M: High Performance Graphics
Mipmap Generation
Stored as a pyramid
Each level ¼ the size
Downsampled from previous one
Until size 1×1

COMP5822M: High Performance Graphics
Mipmap Storage

Conceptual
Actual
OpenGL would generate this for you
Vulkan won’t – so generate them offline

COMP5822M: High Performance Graphics
Accessing Mipmaps
Vulkan will read from a mipmap
Using a VkSampler object
I: Compute r = log(texel size/pixel size)
II: Sample texels at levels
III: Let be the parameter
IV: Interpolate linearly between the levels

COMP5822M: High Performance Graphics
Mipmap Flaws

COMP5822M: High Performance Graphics
Isotropy
Bilinear / Trilinear are isotropic
Equal measures along axes
Do not take perspective into account
Cause aliasing at shallow angles

COMP5822M: High Performance Graphics
Isotropic Overblurring
Longer edge L dominates level
Adds extra samples in u

COMP5822M: High Performance Graphics
Anisotropic Filtering
Back project cell to quad
Sample multiple points in quad
Use separate square per sample
Shortest quad size determines level

COMP5822M: High Performance Graphics
Anisotropic Filtering
Slope of the polygon determines # of texels
Steep slope => more texels

COMP5822M: High Performance Graphics
Net Result

COMP5822M: High Performance Graphics
Volume(tric) Textures
Textures with (u,v,w) coordinates
Stored as a block of data
Mipmapping, &c still apply
Bilinear -> trilinear
Trilinear -> quadrilinear
We’ll come back to them

COMP5822M: High Performance Graphics
Cube Maps
6 Square textures for the faces of a cube

In Vulkan, use 6 array layers of 2D images

COMP5822M: High Performance Graphics

Texture Compression
Textures burn bandwidth
One texture is often > 4 MB
For each pixel, we read 8 texels (trilinear)
So texture compression is necessary

COMP5822M: High Performance Graphics
Fixed-Rate Compression
Built into hardware
Efficient decoders for particular formats
In particular S3TC
Tradeoffs are speed vs. quality (as always)
Decoding more important than encoding

COMP5822M: High Performance Graphics
Block Compression
Block Truncation Coding is standard
Based on 4×4 blocks called tiles
Each one encoded separately

COMP5822M: High Performance Graphics
S3TC Encoding
Tiles store two colours
Interpolate 2 more

COMP5822M: High Performance Graphics
S3TC Encoded Image

COMP5822M: High Performance Graphics
DXTC/BC Variants
DXT1 / BC1
DXT3 / BC2
DXT5 / BC 3
ATI1 / BC4
ATI2 / BC5

COMP5822M: High Performance Graphics
Ericsson Texture Compression (ETC)
Used by OpenGL ES
Same basic features as S3TC
Encodes colour, then modifies luminance

COMP5822M: High Performance Graphics
Normal Maps
Colour is RGB
Each channel in range [0..1]
Normals are XYZ
Each channel in range [-1..1]
So we can store normals in the texture
And access them using texture lookup
Of course, we need to generate the map …

COMP5822M: High Performance Graphics
Normal Map RGB Issues
RGB Colour compression is bad of XYZ
Example from DXT1: note banding artifacts

COMP5822M: High Performance Graphics
Normal Map Compression
Normals are unit length
Assume z component +ve
Store x & y only
Compute z on the fly
Modest compression
Often in DXT5 in green, alpha
Renormalise in frag shader

COMP5822M: High Performance Graphics

HandBrake 0.9.8 2012071800

(s, t, u)(0, t, u) (1, t, u)
(0, 0, u) (1, 0, u)

(0, 1, u) (1, 1, u)

(0, 0, 0) (1, 0, 0)

(0, 1, 0) (1, 1, 0)

(0, 0, 1) (1, 1, 1)

(0, 1, 1) (1, 1, 1)

(s, t, u)(0, t, u) (1, t, u)
(0, 0, u) (1, 0, u)
(0, 1, u)
(1, 1, u)
(0, 0, 0) (1, 0, 0)
(0, 1, 0) (1, 1, 0)
(0, 0, 1) (1, 1, 1)
(0, 1, 1)
(1, 1, 1)

f x, y, z( ) = a xyz + b yz + c xz + d  xy + ex + fy + gz + h
a = b111 − b110 − b101 − b011 + b100 + b010 + b001 + b000
b = b011 − b010 − b001 + b000
c = b101 − b100 − b001 + b000
d = b110 − b100 − b010 + b000
e = b100 − b000
f = b010 − b000
g = b001 − b000
h = b000

fx,y,z
( )
=a xyz+b yz+c xz+d xy+ex+fy+gz+h
a=b
111
-b
110
-b
101
-b
011
+b
100
+b
010
+b
001
+b
000
b=b
011
-b
010
-b
001
+b
000
c=b
101
-b
100
-b
001
+b
000
d=b
110
-b
100
-b
010
+b
000
e=b
100
-b
000
f=b
010
-b
000
g=b
001
-b
000
h=b
000