posted by wap, platform: Android
40帧那个说的是lumen，说的是单那个场景在编辑器里跑40帧，看前面的说的，lumen是个混合的方案，包括基于体素的，ssgi，prt的都有利用到，也提到了，lumen的消耗比nanite大的多，因为是完全看算力，然后51：26说了需不需要rtx硬件，然后解答是有了会更好，因为体素和ssggi也是可以利用光追硬件加速的，我的理解是，ps5版没有用的光追加速，因为官方这么说了，2080笔记本上的跑到了40帧，很可能是利用到了rtx加速硬件，也不排除现在他们迭代的版本优化到了40帧

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2020-5-17 12:05 发表
你这是直接给出结论了，问题是开发者确实可以设计超高io吞吐的处理流程，或者说，虚构的飞过500雕像场景怎么减少io吞吐？我是想不出办法

内部讨论是说，整个nanite最大的贡献是解决了gim的平滑mip的问题，具体细节没讲，通俗点理解就是视距越远的物体读取越少，这样数据流量就和像素正比

posted by wap, platform: Android

引用:

原帖由 @讴歌123  于 2020-5-17 12:26 发表
按照常识，赛车比赛时，20辆左右的赛车是常驻内存的，赛道的大部分内容也是常驻内存的，你要5.5GB/s的IO干嘛？过了2s赛车和赛道就完全不一样了？马自达2s后变成劳斯莱斯，2s就从地球开到火星了？

你的思维还停留在3d渲染=构建3d世界这个框架中，实际上，我们最终看到的只是2d图像，那从这2d图像对应的每个像素，只需要在每帧取得对应的最小资源用来渲染就可以了，20辆车每时每刻存在于内存中是极大冗余的

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2020-5-17 14:11 发表
ue5只是一个引擎，还有用其他开发游戏的
即使都用ue5，也不代表每个游戏都是一样的io需求，fifa就算用寒霜，io需求也很低，肯定比同样寒霜的战地低多了

其实你就想想如果一个游戏，模型精度是蜘蛛侠5倍，移动速度也是5倍的话，需要的io是蜘蛛侠多少倍就明白了

前epic中国首席ta都说ps5的高io在游戏中是有实际作用的，而且索尼也不可能花钱只为了广告，ue5出不出来还能改变什么呢

ps5的SSD优势不仅在于持续传输率，更多的在于大量随机访问延迟能力，这个对帧生成时间的意义更大

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2020-5-17 14:27 发表
所以我不能理解他说的用分辨率怎么倒推io需求
除非ue5支持读取同一个模型，要求精度低的时候只读取这个模型的一小部分数据这种黑科技


更让人难以理解的是，如果真的动态到这个程度，引擎怎么预期短时间内对模型精度的变化呢？比如说这一帧画面时候，这个雕像只需要100个像素，所以引擎智能读取的素材只有10m，但是3帧以后(射击游戏开了高倍镜)，引擎要读高模版本大小是200m，怎么在0.1秒内保证能加载到呢？传统的lod可没有细到这个地步

多级mipmap置换贴图加曲面细分，可以做到精细读取，但也不是无级lod的，并且置换贴图很费，多级mipmap也增大包体

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2020-5-17 14:45 发表
再精细读取，也做不到根据当前帧的每个模型的在屏幕的实际位置来反过来决定ssd载入模型的实际大小吧？
所以即使引擎支持从一个超高模型中选择性读取很小一部分数据，问题是对于无法预期的实际游戏流程，引擎怎么保证下一帧来得及读取精细度变化的模型呢？

模型压缩完了没你说的那么大，geometry image一个50万的模型才250x250的尺寸

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2020-5-17 14:51 发表
demo里一个雕像有33m面，还有几套8k贴图

一张8k贴图加个通道就完全存的下了，正好和uv点对点对应

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2020-5-17 14:53 发表
实际是几套贴图，而且模型本身就很大了

你没明白我的意思，这个3千万的模型完全可以写到一张8k的uv贴图里面去，完了还可以利用图片格式的各种压缩手段

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2020-5-17 14:57 发表
问题是ue5  demo用的就是33m面的模型本身，存在ssd里的模型没有用代理模型

额。。。。？
ue5导入zbrush的模型进demo以后的就不是常见的模型格式了，而是一张图片，小了非常多，2500x2500可以表达5000万以上的面，无损，可随机寻址

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2020-5-17 15:04 发表
33m的无损模型占多大容量？

你算算一张2500x2500的图片不就大概晓得了？而且还不一定需要32bit，uv里面分两个通道16bit应该就可以了

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2020-5-17 15:18 发表
为什么rebio2 的mod里，随便一个人物就是上百m呢

这是新方法啊，完全不同的流程做法，无法再用以前的那种模型格式

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2020-5-17 15:22 发表
以前那种，实际生成的模型最高lod等级也就10万面左右
现在能无损记录3千万面的信息，容量小10倍？

对啊，新的方法不仅只为了容量，主要还是为了流载虚拟化流程，但是代价肯定是有的，解码重建肯定要耗费的

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2020-5-17 15:26 发表
那传闻这个demo 有100g以上是怎么回事？

你没有实际用过ue5吧？现在的容量数据来源是？

传闻而已，根据以前的模型容量推导呗
没有，技术上就是这样，但里面还有些细节，我也不是很明白，比如无级化lod，还有一个像素到底对应几个三角形也不清楚

本帖最后由 342401 于 2020-5-17 15:29 通过手机版编辑

posted by wap, platform: Android

引用:

原帖由 yfl2 于 2020-5-17 15:32 发表

"With Nanite, we don't have to bake normal maps from a high-resolution model to a low-resolution game asset; we can import the high-resolution model directly in the engine. Unreal Engine supports Vi ...

24张也正常啊，这段的意思是一个雕像分割了8个部分，每个部分三张贴图（基色，金属度，法线），总共24张，表达的是贴图精度高分段容易编辑，没说模型，但是模型按这种方法很明显是小于贴图的尺寸的
来源是圈子里分析讨论来的，现在谁能接触到ue5啊，epic直播的那些人说放技术细节也没放
贴一篇Brian Karis（nanite技术的主要贡献者，几乎是个人研究）在2009年的博客，那时候就有Virtual Geometry Images这个想法了
http://graphicrants.blogspot.com ... try-images.html?m=1

本帖最后由 342401 于 2020-5-17 15:54 通过手机版编辑

posted by wap, platform: Android

引用:

原帖由 @yfl2  于 2020-5-17 16:04 发表
看你之前的说法，已经实现了，实际上（2500x2500可以表达5000万以上的面，无损，可随机寻址）只是一个预计？

geometry image是09年以前就出现的技术，把它改造到引擎里面实现肯定有不少问题解决，不然也不会研究十几年这么久，不敢说最终的nanite实现一定是这样，但肯定思路具有很高的吻合度