我的理解简单讲就是让美工在制作上有了方便，且十分可以信赖的参考物。。
在此之前过分依赖美工的感性思维。。
从概念上来讲，和影视制作中ibl模型与实景合成类似~

这不是技术上的进化，而是制作上的进步，ps360到今天技术上估计都没啥可挖了。。
也不是日本人的长处~

个人是十分认同的，技术上无论如何叼转高超，
最终归依也是离不开艺术家们为群众的眼睛服务的。。
最极端的反面例子就是像用ce3那一大堆棒子厂啊，巨人网络搞的网游乐色画面了。。

但让我很不能理解的是，既然平台是ps360，为何在pc上跑？
尽管这是台高配笔记本。。都世代末期了，宣传影像大于实机还有什么意义呢？？

再个dv式纪实型摇摄已经很过时了，实在太刻意。。
而且也很不适合低帧率的过场，观众会疲劳~

其实最终效果倒不是特别真实, 不是好的东西结合到一起就是最好的.

让我想起了问题多多的UE3的光照模型，处理材质粗糙度一坨屎般，导致画面处处是“油腻感”

引用:

原帖由 倍舒爽 于 2013-4-7 11:07 发表
我的理解简单讲就是让美工在制作上有了方便，且十分可以信赖的参考物。。
在此之前过分依赖美工的感性思维。。
从概念上来讲，和影视制作中ibl模型与实景合成类似~

这不是技术上的进化，而是制作上的进步，ps36 ...

用pc的原因，我猜是小岛组还没做好ps360的架构。这里讲的都是比较基础的材质，渲染方法，但实现起来，pc和ps360差异太大。相对于现在更流行的light prepass（cryengine3，unigine等等），fox用的还是老式的大gbuffer，里面什么都放。ps3还好说，360可能直接就放不下（light prepass不存在这个问题，并且能渲染更好更多样的材质，不知道fox为什么不用）。小岛组可能就是先用pc验证一下算法效果。个人觉得小岛组技术上还是落后欧美大厂很多，不过美术上非常认真。

引用:

原帖由 shinkamui 于 2013-4-7 12:04 发表

用pc的原因，我猜是小岛组还没做好ps360的架构。这里讲的都是比较基础的材质，渲染方法，但实现起来，pc和ps360差异太大。相对于现在更流行的light prepass（cryengine3，unigine等等），fox用的还是老式的大gbuff ...

关于材质没有多样性的问题，Stalker 的 X-Ray Engine 已经给出方案了：对 GBuffer 进行 Multipass 渲染，根据 Material ID 进行剔除。其实这个架构就已经很类似 Light Pre-pass 了，而且依然有几何复杂度无关的特点

1. 渲染一套 GBuffer
2. 计算光照缓冲
3. 按材质 ID 用多个全屏渲染（FullScreenPass）来渲染不同材质（在 Light pre-pass 渲染中是再次渲染整个场景）
4. 传统管线
5. 后期处理

仔细看一下 Fox 的 GBuffer，其中的内容 Albedo、Normal、Velocity、Dpeth ，Specular、Glossiness、Translucency、MatID
可以套用 Crysis3 的打包方式 Depth 先去掉，
RT0： RG：Normals，B：Glossiness，A：Translucency
RT1： R：AlbedoY，G：Albedo CbCr（4:2:2），B：Specular，A：MatID
只需要将 RT1 格式从 RGB111110 变成 RGBA8888 即可将目前 Fox 中除了 Velocity 之外的参数全部塞到两个 RT 里去。如果说重新编组一下，加入速度亦可以是这样
RT0： RG：Normals，B：Glossiness，A：Translucency
RT1： RGB：Albedo，A：Specular
RT2： RG：Velocity，B：MatID
—— 某种程度上来说也就是会议上说的 4MRTs 吧。只要牺牲掉 Per-Pixel 的动态模糊（Camera Based 没问题），XBOX360 上跑几乎不需要什么修改，不是么？

[ 本帖最后由 FXCarl 于 2013-4-7 16:54 编辑 ]

引用:

原帖由 FXCarl 于 2013-4-7 16:52 发表


关于材质没有多样性的问题，Stalker 的 X-Ray Engine 已经给出方案了：对 GBuffer 进行 Multipass 渲染，根据 Material ID 进行剔除。其实这个架构就已经很类似 Light Pre-pass 了，而且依然有几何复杂度无关的特 ...

我没仔细分析gbuffer组织方式，记得原ppt里面貌似没有说这四个rt具体怎么安排的，兄台很认真啊，赞一个。
这样安排也算可以吧，不过压的有点太狠了啊。精度低了，有些还塞不进去，画面上还是要缩的，这就没light pre pass自由度高了，唯一的好处就是少渲染一遍。下一代机器内存大带宽高，这样搞无所谓，只是fox还是要面向ps360的，light pre pass还是更好点。

ps：X-Ray Engine 我不了解，有否文章链接？学习一下。不过印象中stalker虽然貌似用了不少当时先进的技术，但画面感觉很差啊

[ 本帖最后由 shinkamui 于 2013-4-7 18:23 编辑 ]

你们业内谁说说这和UE4,CE3比怎么样? 有差距的话差距多少?

引用:

原帖由 掳卡古米 于 2013-4-7 17:48 发表
你们业内谁说说这和UE4,CE3比怎么样? 有差距的话差距多少?

差不多是ue3到3.5之间，和ue4ce3什么的差得远。

引用:

原帖由 shinkamui 于 2013-4-7 18:02 发表

差不多是ue3到3.5之间，和ue4ce3什么的差得远。

不会吧, 搞了半天开发出来就是等于已经用了N久的UE3? 里面的扫描技术呢? 应该会给画面增加不少真实度吧.

引用:

原帖由 掳卡古米 于 2013-4-7 18:43 发表

不会吧, 搞了半天开发出来就是等于已经用了N久的UE3? 里面的扫描技术呢? 应该会给画面增加不少真实度吧.

做素材不能算引擎实力。就好像某组photo shop用的再好也不能说他们的引擎牛逼一样。

感谢啊:D

引用:

原帖由 shinkamui 于 2013-4-7 17:41 发表

我没仔细分析gbuffer组织方式，记得原ppt里面貌似没有说这四个rt具体怎么安排的，兄台很认真啊，赞一个。
这样安排也算可以吧，不过压的有点太狠了啊。精度低了，有些还塞不进去，画面上还是要缩的，这就没light  ...

light pre-pass 的问题在于一定要光栅化场景两遍，对于场景复杂度高的场合其实也尴尬。所以 Crysis3 又滚回了 OnePass 延迟渲染的策略，然后把复杂材质都改成传统管线渲染的了。可以参考这个 http://www.crytek.com/download/S ... ies_of_Crysis3.pptx 历史总是轮回的向前发展哇 ~

X-Ray 的历史来自于这里 http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter09.html

关于 Material ID 的用法，使用了一个比我想的更为优雅的做法 —— 将几种不同的材质都做成查找表，然后做一个纹理查询 …… 连 Multipass 都不用了 …… 这法子相当简洁有力

后来 ClearSky 做了一些修改 http://developer.amd.com/wordpre ... rClearSky210309.ppt 变得反而没有那么特立独行了

我是一个标准的 Full Deferred 党 ~ 因为更简单一些 ~ 只是显得不那么针对这代主机的特性

其实看起来的画面不行只和两件事情有关，第一个是光照/材质模型不行，第二个是素材制作太随意 …… 这些都不是渲染架构的错，架构只关乎效率和伸缩性

[ 本帖最后由 FXCarl 于 2013-4-7 23:28 编辑 ]

posted by wap, platform: iPhone

预告片很燃~

引用:

原帖由 FXCarl 于 2013-4-7 23:25 发表


light pre-pass 的问题在于一定要光栅化场景两遍，对于场景复杂度高的场合其实也尴尬。所以 Crysis3 又滚回了 OnePass 延迟渲染的策略，然后把复杂材质都改成传统管线渲染的了。可以参考这个 http://www.crytek. ...

遇见高人。我问一下，我也很喜欢Deferred的方式，但是我一直觉得Deferred Rendering的在深度上（特别是被深度检测剔除的地方）缺少信息是这个架构的硬伤，现在有没有好的能够解决这个问题的研究成果或方式？

因为虽然现在可能关系不大，但是发展的趋势总是朝着实时全局光的方式走，如果缺乏深度上的光照信息对实时全局光的话应该会有比较大的影响吧？

[ 本帖最后由 Metalgearray 于 2013-4-8 11:45 编辑 ]

引用:

原帖由 Metalgearray 于 2013-4-8 11:44 发表


遇见高人。我问一下，我也很喜欢Deferred的方式，但是我一直觉得Deferred Rendering的在深度上（特别是被深度检测剔除的地方）缺少信息是这个架构的硬伤，现在有没有好的能够解决这个问题的研究成果或方式？

...

直接从fragment上面走gi是不好的，无论如何，与视线平行的内容会被大量抛弃，这跟前向还是延迟没关系。对于深度方向的内容倒是有办法，可以用amd的像素列表方案，基本就是个abuffer，原本是用来做oit的，不过既然全部像素包括挡住的都存在，你要做gi也可以。参考amd的一个oit机器人demo以及对应论文。

正儿八经做gi，目前唯一推荐的就是svo下cone tracing。crytek用的是基于rsm的，仍然不够全局，效果也有很明显短板，各种抖动，溢出等等。