|
楼主 |
发表于 2008-8-14 23:31
|
显示全部楼层
我选择一些提要:
In all, Starcraft II uses about 8,000 unique, non﹔epeating lines of shader code, divided amongst 70 files.
We chose early on to stress the GPU more than the CPU when ramping up quality levels within the game. One of the main reasons for this is that, in Starcraft II, you are able to spawn and manage potentially hundreds of the smaller base units such as zerglings and marines. ...balancing the engine load such that CPU potential is well utilized in both high﹗nit count and low﹗nit unit count situations becomes cumbersome. In contrast, GPU loads in our case tend to be much more affected by the pixel shader load, which tends to stay constant for a real﹖ime strategy game because of the generally low overdraw.
Deferred lighting in Starcraft II is used for local lights only: point and spot lights with a defined extent in space. Global directional lights are forward rendered normally; because these lights have no extents and cover all models, there is little benefit in using deferred rendering methods on them, and it would actually be slower to resample the deferred buffers again for the entire screen.
The computation results for deferred rendering vs. forward rendering equations are equivalent, yet the deferred form is more efficient for complex lighting due to the tighter light coverage offered by rendering the light shapes as a post﹑rocess. For the most part, the new equation simply moves terms from one stage of the rendering pipeline to a later stage, with the notable exception of the pixel’s view space position, which is more efficiently reconstructed from the depth information.
To benefit from early stencil, the light shapes must be rendered again with color writes off before its normal lighting pass. The stencil operation is slightly different depending on whether the viewing camera sits inside the light shape – this has to be tested on the CPU.
Although our initial interest in screen space ambient occlusion was sparked by the excellent results that we observed in such games as Crysis©, we arrived at our solution independently. In a nuts**, the main idea behind screen space ambient occlusion is to approximate the occlusion function at points on visible surfaces by sampling the depth of neighboring pixels in screen space. The resulting solution will be missing occlusion cues from objects that are currently hidden on the screen, but since ambient occlusion tends to be a low frequency phenomenon, the approximation is generally quite convincing. |
|