《虐杀原形2》的特效系统

最新推荐文章于 2024-08-17 10:30:00 发布

原创最新推荐文章于 2024-08-17 10:30:00 发布 · 9.3k 阅读

3 ·

CC 4.0 BY-SA版权

Engine&Render 专栏收录该内容

242 篇文章

订阅专栏

由activision&blizzard旗下的，坐落在加拿大的radical entertainment带来：http://www.gamasutra.com/view/feature/169769/fire_blood_explosions_prototype_.php?print=1

radical entertainment虽然带来的暴力畅快的游戏，但是还是于12年被关闭，不免有点蛋蛋的忧伤。

prototype系列一直血腥无比，里面特效系统功不可没，

特效制作

美术在maya里面开发特效
然后特效由其in game的脚本系统所驱动，这个过程，可以对一些参数进行修改，大一些，快一些等等
- 这也带来一个好处就是，起到一个资源被多个instance共享，同时保持不错的多样性的好处

cache friendly

particle的attribute被分组放在一起（内存连续），比如position们是在一起的，这是一个典型的data oriented的方式，最大化cache friendly
- 像position被分离的话，在camera cull&sort方面都会更好

内存优化

频繁allocate造成严重的memory fragment，解决方式就是使用memory pool，pool满了之后，再进行dynamic的heap allocate.

另外一个很棒的方法是把particle分类：

爆炸类，环境特效类，火花子弹类等等，并使用queue来管理
这样可以进一步分类的对特效进行限制，在系统承受不住的时候，可以对每一个类型设限，如果还要新生成某一个类型的时候，可以把一个老的来强制关闭，通过fading一系列步骤回收
更棒的是对于不同种类的particle可以使用不同类型优化方式，比如火花子弹，就可以以更激进的方式，在离远的时候禁播

vertex buffer memory

这个也是每个particle系统必会提到的，这个文章里面的情况有些特殊，只能在console上面这种有内存绝对控制权的平台上面使用，对于pc不太行。

prototype2是使用一个frame allocator（每帧清掉，线性递增）来处理，这个也是有些年头的技术了，大家很熟悉了

与美术一同处理性能

虽然美术也是有这样的性能意识，但是在压力之下（项目总是很容易出现这个情况，或者说这就是应该出现的情况），美术很难再保持对性能的关注。

这点在prototype1的开发过程，让radical entertainment没少吃苦头。

那么程序这边就需要来良好的帮助美术，找到有问题的点，进行处理。把所有特效都处理的高效，听起来很美，但是现实中不具备实现的条件。

第一个是可视化的给出特效的百分比，这个非常的棒，尤其是pc平台的开发，因为平台机器性能的问题，可能有一些强力机器上面跑得非常快，一个东西1点几毫秒，你很难说它是快是慢。

但是放成比率，那么准确度就大幅度上升了。

这样美术可以较为容易的看到消耗，另外还有一些文字化的统计信息，也非常的好：

prototype2还是用occlusion query来标识overdraw，也是particle消耗的重要方面。

这样美术可以比较直观的看到相关的所有，这也让对性能的控制更加的容易了。

LOD等性能的控制

如第一部分提到的，有脚本来控制一些attribute，这样就在lod的时候，可以做到一个smooth的改变。

同时也会根据上一帧的性能情况进行dynamic lod的改变，更少的，更低lod的particle生成等等。

渲染

multi resolution:这点借鉴bungie的做法，也是有一个动态的，性能压力大的时候，就更多的放到低分辨率buffer上面去，小的时候甚至一点都不放
在低resolution贴回高resolution部分，使用nearest depth filter，这个应该说是效果最好的（好于bilaterial filter）
alpha blending/addive：使用了一个比较常用的：在shader里面计算好，进而把blending和additive统一起来，代码：

Add-Alpha Shader Code
// Add-alpha pixel shader. To be used in conjunction
// with the blend factors {One, InverseSourceAlpha}

float4 addalphaPS(
float4 vertexColour : COLOR0,
float2 uvFrame0 : TEXCOORD0,
float2 uvFrame1 : TEXCOORD1,
float subFrameStep : TEXCOORD2 ) : COLOR

{

// Fetch both texture frames and interpolate

float4 frame0 = tex2D( FXAtlasSampler, uvFrame0 );
float4 frame1 = tex2D( FXAtlasSampler, uvFrame1 );
float4 tex = lerp(frame0, frame1, subFrameStep);

// Pre-multiply the texture alpha. For alpha-blended particles,
// this achieves the same effect as a SourceAlpha blend factor

float3 preMultipliedColour = tex.rgb * tex.a;
float3 colourOut = vertexColour.rgb * preMultipliedColour;

// The vertex alpha controls whether the particle is alpha
// blended or additive; 0 = additive, 1 = alpha blended,
// or an intermediate value for a mix of both

float alphaOut = vertexColour.a * tex.a;
return float4( colourOut, alphaOut );

}