问题 - GDC Vault
Download
Report
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(肯•亚当斯)