查看完整版本: [-- [CG] 1GB 的 MegaTexture 实现 ( 更新演示截图) --]

-> 同人游戏创作/Doujin Games Workshop -> [CG] 1GB 的 MegaTexture 实现 ( 更新演示截图) [打印本页] 登录 -> 注册 -> 回复主题 -> 发表主题

glkasumi 2010-04-12 04:16

[CG] 1GB 的 MegaTexture 实现 ( 更新演示截图)

 

-----------------------------------
以上场景使用 1GB 的纹理,屏幕分辨率 1280 x 800,帧频200+fps,点击放大
场景几何部分是由四个顶点构成的正方形,Demo太大现在就不放了... (其实主要是我现在写入纹理的部分还没优化...)
关于如何快速操作大文件(>4GB)的读取和写入,希望了解的同学们给些建议的说


--------------------------------------
经过周四周五的努力,总算避开了显存往内存回读的瓶颈,将帧频由45优化到到200+,
基本算将最基础的渲染架构整出来了,(某些截图已经和ID官方的很类似了)
而现在主要的性能瓶颈则集中在数据的搬移上(硬盘到内存,内存到显存),
对于1GB可能还不是那么严重,但是如果继续扩张纹理,或加大在场景中的移动速率,由于延迟所造成的问题将非常明显
另一方面就是相应的编辑器用于绘制这张大纹理,即便这张从NASA上下的火星表面纹理也没能把整张纹理填满...

总而言之,三星期的研究工作告一阶段,要开始忙课业了...

------------------------------------

MegaTexture 是 ID SOFTWARE 的下一代渲染技术ID TECH5的主要组成部分,
有兴趣的同学可以关注一下今年或明年发售的游戏 Rage,当然 Trailer 已经有了

基本思想就是无论使用的纹理多么精细,显示出来的也不可能比屏幕的分辨率更高,
所以理论上显存中需要加载的纹理像素数应该和屏幕的像素数是1:1的关系,当然实际情况不会这么完美,但大体上应该如此,

这项技术就将整个场景中所有的纹理封装进一张超大的全局纹理(ID的实现是64GB的纹理),
然后通过全局纹理坐标构建世界空间和纹理空间的映射关系,从而优化纹理的动态加载

传统的动态加载技术如ClipMap(类似于GoogleMap)是应用于地形纹理绘制,
而MegaTexture是更具一般意义的,因为它可以用来从任何视角渲染场景中的任何物体

几个比较明显的优点
1. 场景中可以使用高精度的纹理而不出现重复
2. 只占用很少的显存,几十MB即可
3. 对显卡要求不高,只需要支持最基本的shader即可(OpenGL2.0 通过)
4. 和传统的渲染方法不冲突,而且将几何和纹理独立开之后更加灵活
总之,就是解放显存和美工,加快游戏开发的一项很优雅的技术




avg3271m 2010-04-12 11:31
>>关于如何快速操作大文件(>4GB)的读取和写入,希望了解的同学们给些建议的说

如果LZ说的是随机读写的话...
读取是这样的:
用unsigned long long int类型的指针按照你感兴趣的信息类型建立一个二进制类型的索引文件(比如文本文件里的行号,每隔1000行记录一个地址)
索引的时候要读完整个文件,可能会比较慢,但是有了索引文件以后取任意中间的内容都会快很多。比如按上面的方法记录的索引,要找第50,001,234行,只需在索引文件上位移到5000001*sizeof(unsigned long long int)的位置(用seekg),读一下里面存的值,再往目标文件seekg一下,跳过233行,读取一行即可.
以上方法在64位Linux系统下测试10G以下文件均成功,以上的没试过..如果你说的是Win32下4GB地址的那个问题的话..咱还没测试过= =
Win32 测试失败,似乎还是要fopen64一类的东西啊..

随机写入的话似乎没有什么好办法...要么就多点冗余放数据,要么就把要写入的数据全部存起来并记好要写入的地方,然后一次重写整个文件...

关键字seekp,seekg,tellg,C++

littlewater 2010-04-12 19:23
文件吗?顺序读大概就算是最快的,最高效的算法,大概就是无限趋近于你的磁盘读写速度……
一般顺序读写,开大一些的缓存就差不多了……

干吗要用1GB的纹理,显卡只有512MB=-=,还是说是有重复的^-^?

Wiksy 2010-04-12 20:16
有没有关于MegaTexture的详细介绍文章?
虽然大概知道是怎么回事(印象中仿佛看过id关于这个的ppt文件),但是还是无法理解……

>2. 只占用很少的显存,几十MB即可
不是全部的东西都放到一张巨型纹理里面吗?那么如何只是用几十MB的显存?
此外我才不信Rage里面会只有一个64GB的纹理文件……应该是动态构建的吧?

littlewater 2010-04-12 20:57
WIN32下文件肯定可以超过4GB吧||||

seekg= =? 水水用过 _fseeki64 貌似这个名字^^||

-----------------------------

istream::seekg 原来是C++的^-^||

鸡蛋灌饼 2010-04-12 21:58
>>>关于如何快速操作大文件(>4GB)的读取和写入,希望了解的同学们给些建议的说
软的不行来硬的,上SSD
其他的真没什么好建议,如果可能的话单独划个分区直接读写,绕过文件系统也是方法
1F说的是文件内容如何组织,这方面数据库和文件系统有很成熟的经验,我就不废话了。


>>>不是全部的东西都放到一张巨型纹理里面吗?那么如何只是用几十MB的显存?
>>>此外我才不信Rage里面会只有一个64GB的纹理文件……应该是动态构建的吧?
我觉得这是虚拟内存思想在纹理管理上的体现
不管你总共有多少数据,WorkingSet其实就那么点

glkasumi 2010-04-12 22:09
引用第1楼avg3271m于2010-04-12 11:31发表的 :
>>关于如何快速操作大文件(>4GB)的读取和写入,希望了解的同学们给些建议的说
如果LZ说的是随机读写的话...
读取是这样的:
用unsigned long long int类型的指针按照你感兴趣的信息类型建立一个二进制类型的索引文件(比如文本文件里的行号,每隔1000行记录一个地址)
.......

 
呃,多谢测试,那看来只能用64位的文件函数了...
 


引用第2楼littlewater于2010-04-12 19:23发表的 :
文件吗?顺序读大概就算是最快的,最高效的算法,大概就是无限趋近于你的磁盘读写速度……
一般顺序读写,开大一些的缓存就差不多了……
干吗要用1GB的纹理,显卡只有512MB=-=,还是说是有重复的^-^? 

 
它是将一个游戏所有的纹理全部封装进超大纹理,那64GB都不为过
使用1GB的纹理,但是并不代表一次需要全部加载进显存,可以参考GoogleMap的实现 
PS: 那看来文件要采取一定策略顺序读了...




引用第3楼Wiksy于2010-04-12 20:16发表的 :
有没有关于MegaTexture的详细介绍文章?
虽然大概知道是怎么回事(印象中仿佛看过id关于这个的ppt文件),但是还是无法理解……

>2. 只占用很少的显存,几十MB即可
不是全部的东西都放到一张巨型纹理里面吗?那么如何只是用几十MB的显存?
.......

利用和 MipMap 同样的思想,一个1024x1024的纹理如果在屏幕上只能显示几个像素,只需要加载粗糙的层次即可

Rage是用蓝光存的纹理,Demo就有20GB



引用第5楼鸡蛋灌饼于2010-04-12 21:58发表的 Re:[CG] 1GB 的 MegaTexture 实现 :
>>>关于如何快速操作大文件(>4GB)的读取和写入,希望了解的同学们给些建议的说
软的不行来硬的,上SSD
其他的真没什么好建议,如果可能的话单独划个分区直接读写,绕过文件系统也是方法
1F说的是文件内容如何组织,这方面数据库和文件系统有很成熟的经验,我就不废话了。

.......


没错,就是虚拟纹理
谢谢建议的说,去查一下相关资料

h5nc 2010-04-13 00:55
小镇总在偶需要研究啥东西的时候出现相关话题
嘛,看完了相关东西偶觉得,这样做之后和纹理大小没什么太大关系,只是因为利用虚拟纹理技术将显存消耗降至非常低
而如何读取大文件之类的属于另一个方面了
偶的理解是:当大文件问题不是问题的前提下,这个技术是最速度的场景渲染方式……

嘛,其实偶最近要研究的是很简单的不同话题……………………基本完全无关
偶在移植到PSP上时遇到内存or显存管理的问题,主要出在加载的纹理上
偶只会整张加载……偶在想是不是必须控制加载纹理个数or大小来控制内存显存消耗……而已
仔细看了看实在米啥关系

目前进度……引擎搭载成功 3D部分米处理,放PSP上必黑 还米优化过素材呢……

Advance 2010-04-13 03:56
不是很明白,纹理不是在场景内或者即将进入场景时才加载的么……
在物理或虚拟内存中存放多达64GB的纹理有明显好处?仅仅是为了方便显卡管理纹理和顶点之间的关系?求解说

glkasumi 2010-04-13 04:22
引用第7楼h5nc于2010-04-13 00:55发表的  :
小镇总在偶需要研究啥东西的时候出现相关话题 [表情]   
嘛,看完了相关东西偶觉得,这样做之后和纹理大小没什么太大关系,只是因为利用虚拟纹理技术将显存消耗降至非常低
而如何读取大文件之类的属于另一个方面了
偶的理解是:当大文件问题不是问题的前提下,这个技术是最速度的场景渲染方式……
.......


H大说得没错 ,其实这种技术的核心思想和你的考虑是一致的,我以前也有类似的考虑,但是一个一个分开单独的纹理是很难处理的,而全局统一的纹理恰恰提供了这样一种优化的手段;而事实上,以我现在做到的程度来看,主要的瓶颈在于镜头移动所造成的数据搬移,真正绘制几乎不会耗费时间(因为只与屏幕分辨率成正比,而与场景复杂度无关)

glkasumi 2010-04-13 04:41
引用第8楼Advance于2010-04-13 03:56发表的  :
不是很明白,纹理不是在场景内或者即将进入场景时才加载的么……
在物理或虚拟内存中存放多达64GB的纹理有明显好处?仅仅是为了方便显卡管理纹理和顶点之间的关系?求解说

A大,不是说存放64GB的纹理拥有什么好处,而是在于引擎拥有即时渲染64GB纹理的能力,
即便以现在硬件的水平,也无法做到将64GB的纹理全部加载进内存,更不要说加载进显存去渲染了,
那么传统的解决方法无外乎1。 美工使用几种小纹理进行组合叠加;2。对场景进行分割,进行分区域加载;
但是第一种会产生明显的重复效果,第二种每个单独分割的小区域也无法使用过多的纹理
而且传统的纹理管理技术是和几何管理密切相关的,不同的场景管理会有不同的纹理管理对策
但是,这种技术允许你即便在一个角色上投入几百MB的纹理也没有关系,就是说,可以真正地实时达到电影级别的画质;而美工只需要在这张超大纹理上进行绘制,自由发挥就可以了,而且由于这种全局对应统一关系,无论使用什么几何管理方法,都可以使用统一地纹理管理策略,比如我渲染地这个场景,即便改成复杂地网格渲染也没有关系,只要纹理坐标赋得正确就可以

Advance 2010-04-13 05:28
你也没睡啊
其实是因为引擎可以进行这样的渲染而采用平坦映射所有纹理的方式,指定窗口坐标,就能通过一个不需要显式指定加载位置的接口来实现动态的纹理管理,是这个意思么

顺便读文件的话你要实现一个CACHE管理,不过NT系统在读CACHE上的策略已经很有效率,只需注意利用重叠IO完成端口模型即可。其它系统可能就要自己写了……

glkasumi 2010-04-13 09:38
引用第11楼Advance于2010-04-13 05:28发表的  :
你也没睡啊 [表情]  
其实是因为引擎可以进行这样的渲染而采用平坦映射所有纹理的方式,指定窗口坐标,就能通过一个不需要显式指定加载位置的接口来实现动态的纹理管理,是这个意思么
顺便读文件的话你要实现一个CACHE管理,不过NT系统在读CACHE上的策略已经很有效率,只需注意利用重叠IO完成端口模型即可。其它系统可能就要自己写了……


嗯,大致是这个意思
Cache现在还是主要去写算法上的Cache,硬件上看来还得慢慢钻研...
我忽然想起来FAT32不支持4GB以上的文件,通用起见,还是分割成1GB的文件储存算了...

littlewater 2010-04-14 19:26
引用第11楼Advance于2010-04-13 05:28发表的  :
你也没睡啊 [表情]
其实是因为引擎可以进行这样的渲染而采用平坦映射所有纹理的方式,指定窗口坐标,就能通过一个不需要显式指定加载位置的接口来实现动态的纹理管理,是这个意思么
顺便读文件的话你要实现一个CACHE管理,不过NT系统在读CACHE上的策略已经很有效率,只需注意利用重叠IO完成端口模型即可。其它系统可能就要自己写了……


啥都可以搭上话,真好~
水水那显卡只有PS14- -|| 从未碰过任何>2的东西(不论GL DX)………………

ryuka 2010-04-15 13:31
上次G大还给我晒过=v=.这个技术我感觉只要cpu和gpu的传递数据的速度上去以后就很快了.弱点是不容易扩展.假设我要使用一个新的纹理测试或者做用户自定义换装之类的,我必须要把那个纹理打包进megatexture的Mipmap层次结构里面.还有如果我要使用一个renderTarget做反射类用途,这个renderTarget也要打包进megaTexture的mipMap层次结构里面.把新的纹理要打进那个大文件里面可是要费事情啊..

glkasumi 2010-04-15 14:13
上次我给YUKI晒的时候时候还只有45fps,因为需要回传内存在CPU上做运算,现在这步直接没了,所以...
嘛,任何一项渲染技术有都有自己的弱势(而这个往往还是由它的优势所造成的...)
要说这项技术的缺点,其中之一就是透明物体需要分别处理(透明物体到哪里都是难题啊...)
不过因为它只是一种索引纹理的技术,所以跟具体的渲染流程没有关系,
总之就是,没办法避开的问题回归到传统渲染方法就可以了(这点倒是不像延时渲染与传统渲染方式差别那么大)
Yuki所说的拓展性的问题倒是可以通过增强编辑器IDE的功能来补足;


查看完整版本: [-- [CG] 1GB 的 MegaTexture 实现 ( 更新演示截图) --] [-- top --]


Powered by phpwind v8.7 Code ©2003-2011 phpwind
Time 0.044242 second(s),query:2 Gzip enabled