Transcript 问题 - GDC Vault


Colt McAnlis （柯尔特•麦克安利斯）
 图形程序员 – Blizzard

60 分钟（估计）

纹理数据太多，无法全部载入内存。

纹理数据具有独特性

超强分辨率

可达每个像素1米
顶点数据
 常见地形纹理问题
 低端硬件
 技术综述

页面置换与缓存
 DXT++ 压缩
 复合 （Compositing）框架
 编辑问题
 基于示例的纹理合成


一次只能看一小部分

不可见区域的数据仍留在磁盘上

新的页面必须源源流入 （Streamed In）


很快便受限于磁盘I/O 能力
视锥台的快速动作导致性能剧降

新页面发生频繁

但是，无需置入玩家周围的所有径向页面。

只需流入远处的页面。

在MIP（Maximum Intensity Projection，
最大强度投影）图分层成块流入（Chunks
stream in）
距离变化时，LOD也发生变化。
 新的MIP分层取自磁盘。


纹理的划分通常横跨图块的范围。

对绘制请求数量而言，这不理想..

每个分块都有各自的MIP链 （MipChain）。
很难跨越边界进行过滤。

但我们不需要每一个分块的全部链。

径向页面置换需要的内存较少。
要是过滤更方便就好了！
 如果有一个大型 MIP 链情况会怎样？


按“距离”使用一个纹理


所有纹理大小相同


区域内的分辨率一致
当距离增加时，质量降低
能存储为三维纹理/数组

仅将一种纹理与 GPU 绑定
纹理片
三维纹理
MIP栈

优点是可以使用一种纹理


不再有边界交叉过滤问题


纹理不再是断开批次的原因了
一层只有一个样本，确保过滤正确
但MIP映射仍旧是个问题

因为MIP是分散的

每个“距离”只需两个MIP


在距离边界处，MIP层应相同。


当前MIP，下一个最小的MIP
当前距离被最大强度投影至下一距离
内存 – 性能 – 质量之间的权衡

YMMV
MIP过渡
MipChain
如何更新纹理？
 GPU 资源？
应使用“渲染至纹理”（RTT）进行填充。
但压缩了怎么办？
 无法对已压缩的目标进行“渲染至纹理”
（RTT）
 GPU 压缩是有限的
没有足够的循环以获得高质量



您不是被GPU绑定的吗？
那么就使用GPU对其进行填充？

Lock（锁定）+ memcpy （内存拷贝）
页面置换与缓存
 DXT++ 压缩
 复合 （Compositing）框架
 编辑问题
 基于示例的纹理合成

目标：在 CPU 中填充大型纹理
 问题：DXT 不错

但其他系统更好 （JPG）

ID Software：
JPEG->RGBA8->DXT
 重压缩已解压的流

会带来二级质量失真
 解压/重压缩速度？


归根到底，我们必须采用 GPU 友好格式


摒弃“中间人”？



这是迟早的事 ..
我们需要直接解压成为DXT
这意味着我们需要更大程度地压缩DXT数据
让我们来看看DXT版面
DXT1：结果为4BPP
高565
低565
2位
选择子
现实中，您往往有很多这样的图块：
512x512的纹理是16K个分块
……
每个纹理拥有两类不同的数据。
16位分块颜色
每类数据均可进一步压缩
2位选择子
输入纹理：
可能包含上百万种颜色
输入纹理：
实际使用的颜色
16位压缩后
使用的颜色
•每一图块具有两种独有的颜色
•但要是其他分块中也存在这些颜色将怎样？
•这导致重复数据
•让我们试着去除这些重复数据。
无损数据压缩
 代表最少位字典集
频繁使用的值具有较小的位索引 （Bit Rep）


字符串：AAAABBBCCD（80位）
符号

编码
使用%
A
50%
0
B
25%
10
C
15%
110
D
5%
111
结果：00001010101101101111（20位）

更多常用颜色将被赋予较小的索引值
4096个相同的565色 = 8KB
 Huffman编码后 = 514字节



4K 单个位，一个16位色
问题：当独有颜色数量增加时，Huffman
法的效率将降低。

可量化 （Quantize）相似的颜色


量化矢量


肉眼不会察觉
将大量的数据集归并入相关的分组内
可将组内的元素替换为单一值

第一步：矢量化独有颜色输入


第二步：对矢量化后的颜色进行Huffman
压缩


减少独有颜色数量
对每个DXT块，存储 Huffman 索引而非 565
色
W00t..（什么…）

每个选择子分块由少量数位组成

将2位选择子串起来，构成较大的符号

也可以使用Huffman 法！
4x4 的2位数组——每块的值
 结果是四个8位值



或采用单个32位值


可能太小，无法获得良好的压缩结果
如果有太多的独特选择子则没有帮助
用您的数据进行测试，确定理想的大小

实践中，8位至16位的效果较好
DXT数据
分开
矢量
量化
量化分块
颜色
Huffman
Huffman表
颜色索引
选择子索引
选择子数位
Huffman
Huffman表
至磁盘
图块颜色
颜色索引
选择子索引
Huffman表
选择子数位
Huffman表
图块颜色
填充DXT块
未压缩
DXT1 （4BPP）
DXT1 ++
3MB
512KB
91KB
未压缩
DXT3A （4BPP）
DXT ++
1MB
512KB
9KB
回到纹理化
 将解压后的数据插入MIP栈层

可以锁定MIP栈层


在 CPU 中更新子区域
解压缩不是唯一的方法
页面置换与缓存
 DXT++ 压缩
 复合框架
 编辑问题
 基于示例的纹理合成


进入缓存的页面来源不一


不必是经过压缩的独特数据
溅射算法 （Splatting）如何?
标准屏幕空间方法
 能用其填充缓存吗？


溅射是标准纹理化方法
重新渲染地形至屏幕
 每次都将新纹理与Alpha绑定
 通过混合，逐渐累积形成最终效果


地形纹理化的标准方法

同样的过程可用于我们的缓存模式


不要溅射至屏幕空间


获得相同的内存优势
复合在缓存中的页面
压缩了怎么样？

无法复合与压缩

Alpha 混合 + DXT 压缩？？？
复合->ARGB8->DXT

压缩很棒


重复纹理 + 低分辨率Alpha


但理应可以获得更好的结果
= 节省大量内存
避免了顶点绘制超量（Vert Overdraw）

这可棒极了！

权衡质量与性能
在同样的性能水平上，难以获得独特性高的质量
更多的混合 = 更差的性能

为了内存，牺牲独特性


平铺的特征很显眼
循环浪费严重

为每个框架重新创建相同的资产
复合与解压的混合
 关于前景/背景的有趣想法

根据距离在两者之间切换

关于低端平台的有趣想法
高端使用解压
 低端使用复合


同时使用两者的有趣想法
非常灵活的管道…
解压
缓存
磁盘
数据
CPU 压缩
二维复合器
GPU压缩
页面置换与缓存
 DXT++ 压缩
 复合 （Compositing）框架
 编辑问题
 基于示例的纹理合成


标准管道被数据所堵塞
专为一个用户设计 -> 一个资产作业
 主要由源文件控制配置所决定


需要直接处理海量纹理化

允许多个画家对星球进行纹理化
所带来的问题。


只由一个画家纹理化一个星球，太慢了…
标准的源文件控制概念失效
如果所有的纹理化都存储在一个文件中，那么
安全的做法是：同一时刻只能有一个人编辑该
文件
 解决方案：2百万个单独的文件？


需要更好的设置

允许多个用户编辑纹理化


用户反馈极为重要
编辑过的区域立刻亮显让其他用户知道
亮显意味着“已被更改”
 亮显意味着“不能更改”

纹理化服务器
更新数据
有更改
画家 A
画家 B

需要定制合并工具


每台机器只检收自身所作的少量修改
在提交至实际源文件控制前，服务器将它
们合并

充当“中间人”
源文件控制
纹理化
服务器
更改
更改
画家 A
画家 B

星球级的批次操作怎么办？
能立刻修改整个星球吗?
 会忽略未受影响的区域吗？


双刃剑...
具备批次特性仍很重要。
 也许可以限制批次操作的距离？
 如果常识修改已编辑区域，是否会作标记？


常见纹理化概念
根据斜坡设置纹理
 根据高度设置纹理
 根据区域设置纹理


能否进一步扩展？

将“设定”（Set）操作视为“遮罩”
（Mask）

通过过程函数设定纹理化
将遮罩与图形设置相结合
 常见概念


.kkriger、Worldmachine 等

遮罩能随顶点变更而重新生成。


为其他数据生成多个遮罩


只要您存储的是图形而非遮罩。
应用树、对象等等
这是很棒的通用算法
页面置换与缓存
 DXT++ 压缩
 复合 （Compositing）框架
 编辑问题
 基于纹理合成的示例


重复纹理带来了问题

采用较多的混合，减少重复
占用更多内存
 增加性能负担


最好能自动解决它

为每个像素生成输出纹理


基于当前的“邻居”选择新像素
将输入像素表示为其“邻居”的函数
创建搜索加速结构
 找到与输入相似的“邻居”


这就是所谓的“像素级”（Per-pixel）合
成
纹理的合成
样例

基本上是“最近邻居”搜索

不会达到最佳质量

只根据先前更正过的“邻居”，更正所输入的像
素


引入序列化依赖关系
若要获得更好的效果，需增加邻居的数量

这就增加了采样时间
范例
杂乱的输出图像

Hoppe 2006 （微软研究院）

多分辨率：输出图像大小变化时，像素保
持不变

这样能“保持”文理的固有特征
减少图像失真

基于 GPU

可控性强

画家 / 网格提供的矢量域

能合成大型纹理


使用地形法矢作为输入


而不是相同的重复纹理
允许纹理随轮廓“流动”
允许画家调整矢量

这样他们就能绘制定制的漩涡等


甚至能用于合成地形顶点数据

不过这是另一个讲演的内容了;）

在编辑时，复合海量地形还是太慢
合成整个星球？
 可能要采用渲染农场 （Render-Farm）过程。


事实上，处理非海量地形时仍然太慢…


也许可以生成定制贴标 （Decal）？
但是 CPU 怎么办？
或可一试多内核
 未来的研究？


纹理数据使用一个纹理资源


使用 DXT++ 减小占用空间


MIP栈 （MipStack）结构
而不采用 RGBA->DXT
多输入缓存填充算法

流 + 复合
使用定制纹理化服务器
 让纹理合成更快！！


我在对您说呢，Hoppe （霍普）先生 ;）
Andrew Foster（安德鲁•弗斯特）
 Rich Geldreich（瑞奇•戈尔德瑞克）
 Ken Adams（肯•亚当斯）
