Considerations for RealWorld Applications with GPUl论文翻译.docx

1、Considerations for RealWorld Applications with GPUl论文翻译Considerations for Real-World Applications with GPULevel of DetailIn an ideal 3D scene, all polygons would show up at about the same size on the screen. In practice, though, this rarely happens. The terrain technique presented so far has created

2、 a tessellation that is somewhat uniform in world space, but definitely not uniform in screen space. As a result, distant polygons appear very tiny (one pixel or less in size), which is wasteful, and introduces aliasing artifacts. To alleviate this problem, wed like to divide blocks into three group

3、s: close, medium, and far. Blocks at close range will have polygons at a regular size, and blocks at a medium distance will have larger polygons (in world space). Finally, blocks at a far distance will have the largest polygons. To implement this approach, we can choose from two basic schemes: one i

4、n which lower-level-of-detail (LOD) blocks have fewer polygons in them, and another where lower-LOD blocks simply represent a larger space.In the fewer polygons scheme, all blocks remain at 1x1x1 in world space, but faraway blocks have a smaller internal grid size (163 or 83 instead of 323). Unfortu

5、nately, this scheme causes the number of blocks to bloat very quickly, which rapidly decreases performancefor both the rendering and, especially, the generation of blocks.The bigger blocks scheme is a better approach. Here, all blocks have a constant 323 internal grid size, but the world-space size

6、of the terrain that the blocks represent changes, based on their distance from the viewer. Nearby blocks will occupy a cube that is 1x1x1 in world space, while larger blocks (for terrain that is farther away) will cover a 2x2x2 cube in world space and some even larger cubes (4x4x4) out to a great di

7、stance. At draw time, we draw the large (faraway) blocks first, then the medium blocks, then the fine blocks (1x1x1) overtop. Because the number of blocks remains manageable, this is the preferred scheme.As with many LOD schemes, however, switching a section of terrain from one LOD to another create

8、s a sudden, visual popping artifact. The easiest way to deal with this problem is to draw both LODs during the transition period. Draw the low LOD first and slowly alpha-fade the higher-LOD block in, or out, over some short period of time. However, this works well only if the z-buffer (depth) values

9、 at every pixel are consistently closer for the higher-LOD block; otherwise the higher-LOD block wont alpha-blend over the lower-LOD block.Therefore, some small amount of negative bias on the z (depth) value should be used in the vertex shader when were drawing higher-LOD blocks. Even better, we can

10、 generate the lower-LOD blocks by using a small negative bias in the density function. This approach isotropically erodes the blocks and is similar to shrinking the surface along its surface normals (but better, because it does not result in any pinch points). As a result, the higher-LOD chunks will

11、 usually encase the lower-LOD chunks, and will not have z-fighting problems when alpha blending over the top of them.CollisionsIn an interactive or game environment, many movable objectssuch as insects, birds, characters feet, and so onmust be able to detect, and respond to, collisions with the terr

12、ain. Intelligent flying creatures might need to cast rays out ahead of time (as the dragonflies do in the Cascades demo) in order to steer clear of terrain features. And surface-crawling objectssuch as growing vines (a hidden feature in the Cascades demo), spiders, or flowing watermust stick to the

13、terrain surface as they move around. Thrown or launched objects also need to know when they hit the terrain, so that they can stop moving (such as a spear hitting the ground), bouncing (as in a soccer ball), or triggering some kind of event.These object-terrain interactions are easy to compute if th

14、e objects motion is primarily driven by the GPU from within a shader. Its easiest to do this computation using a geometry shader, where a small buffer containing a single element (vertex) for each moving object is run through the geometry shader for each frame. In order for the geometry shader to kn

15、ow about the terrain, the density function must be placed in a separate file that can be included (via #include) by other shaders. The geometry shader can then include the file and use the function, querying it when needed, to test if a point in space is inside or outside of the terrain.For example,

16、 if a soccer ball were sailing toward the terrain, the geometry shader could test the density function at the previous frames position and at the new frames position. If the ball was previously in the air but the new position would be inside the terrain, then the exact location where the ball first

17、hit the surface could be determined by an interpolation of the density value to find where it would equal zero. Or we could use an iterative refinement technique, such as interval halving. Once we find the exact point of collision, we can compute the gradient at that point (via six more samples). Fi

18、nally, knowing the velocity of the ball and the normal of the terrain, we can compute the bounce direction, and then we can output the proper new position and velocity of the ball.LightingIf the soccer ball of the previous example falls into a cave, the viewer will expect it to look darker because o

19、f the general occlusion of ambient light that is happening inside the cave (assuming its not a magical, light-producing soccer ball). Fortunately, this is easily accomplished by casting ambient occlusion rays out from the center of the object for each frame (if the object is moving), just like the r

20、ay casting when we generate a single terrain vertex.The only difference is that here the density function must be used instead of the density volume, because the density volume data for this block is likely long gone. Using the density function is much slower, but if these occlusion rays are cast fo

21、r only a few dozen moving, visible objects per frame, the impact is not noticeable. GPU技术对实际应用的考虑在理想的三维场景中，所有的多边形会在屏幕中以大致相同的大小显示。实际上，这种情况极少发生。目前，我们提到的地形技术所创建的细节在世界空间中是均匀的，但显然在屏幕空间中并非如此。在屏幕中，远处的多边形显得很小（一个或小于一个像素），这是一种浪费，并且会产生走样失真。要解决这种问题，我们可以将块分为三组：近处、中间和远处。近处的地形将拥有正常大小的多边形，中间距离的块有较大的多边形（在世界坐标系中）。最后，

22、远处的块包含最大的多边形。要实现这种方法，我们有两种方案供选择：一种是低细节层次的块包含较少的多边形：另一种是低细节层次的块表示一个更大的空间。在“较少多边形”方案中，所有的块在世界空间里保持111的大小，但远处的块有更小的内部网格尺寸（用163或83来代替323）。遗憾的是，这个方案会导致块的数目迅速膨胀，从而迅速地降低了渲染以及生成地形块的性能。“更大地形块”方案是个更好的解决方法。在这种方案中，所有的块有不变的323内部网格尺寸，但块所表示的地形在世界空间的尺寸则会基于它们距视点的距离而变化。近处的块会占据世界空间中111大小的立方空间，而更大的块（对应于远处的地形）会占据世界空间中22

23、2的立方空间，最远距离的块则占据的空间更大（444）。在绘制时，我们首先绘制（较远的）大块，然后绘制中等距离的块，最后则绘制最小的块。由于块的数目保持为可控状态，因此这是个更好的方案。然而，对于许多LOD方案来说，从一个LOD切换到另一个地形区域会产生突然地、视觉上的跳动失真。最简单的解决方法是在跳转大的时候同时绘制这两个LOD。首先绘制低层次，然后在一个很短的时间段内使其随着高层次的绘制渐变消失。然而，这种方法仅在每个像素的z-buffer（深度）距离高层次块较近时效果较好；否则高层次块不会自然地在低层次块上做alpha混合。因此，当我们绘制高层次块时，应当在顶点着色器中对z（深度）值进行微

24、小的负向修正。更好的解决方法是，我们可以通过对密度函数进行小的负向修正来创建低层次块。这个方法会等方向性地“侵蚀”LOD块，很类似于沿着表面法线将表面进行收缩（但效果更好，因为不会造成任何尖点）。这样的结果是。高层次的块会逐渐代替低层次的块，同时不会在进行alpha混合时出现z深度冲突的问题。1、碰撞在一个交互的或游戏环境中，许多可移动的对象，如昆虫、鸟、角色的腿等，必须能够被探测并能够对于地形的碰撞进行响应。“智能”的飞行生物或许需要在这种时刻之前就发出射线（如同在“Cascades”演示中的蜻蜓一样）来判别各种地形特征。而贴着地表的对象例如，生长着的藤蔓（“Cascades”演示中的隐藏特

25、性），蜘蛛或流动的水，则必须在移动的时候紧贴着地形表面。被扔出去或者被发射出去的对象同样需要知道它们何时碰撞到了地形，从而可以停止移动（如长矛碰到了地面）、弹起（如足球）或触发一些事件。若对象的动作主要由GPU内的着色器来驱动，那么这些对象与地形的交互非常容易计算。最简单的计算方法是使用几何体着色器，其中一个小缓冲区保存着每帧经过几何体着色器的每个移动对象的单个元素（顶点）。要使几何体着色器得到地形信息，必须将密度函数存放于一个单独的文件中，以使得其他着色器可以将其包含（通过#include的方式）。然后几何体着色器便可以包含这个文件，并使用函数根据需要进行查询，来测试空间中的一点是否在地形之

26、内或之外。例如，若一个足球正沿着地形滚下，几何体着色器可以在前一帧的位置和当前的位置测试密度函数。若球之前在空中，而当前处于地形之内，那么球首次碰撞到地面的位置能够通过对密度函数进行插值的方法计算出来。或者我们可以使用一种相对而言更好的方法，如区间分半法。一旦找到了碰撞的位置，就可以计算该点的梯度（通过6次或更多的采样）。得到球的速度和地形的法线后，就可以计算反弹方向，输出新的位置以及球的速度。2、光照若前面的例子中的球落入了一个洞中，观察者会期望其由于洞内对环境光的遮挡而看起来变暗（假设它不是一个神奇的、发光的足球）。幸运的是，这可以通过每帧（若对象在运动）从对象的中央发出环境遮挡光线来实现

27、，该方法类似于我们创建单个地形顶点时投射光线的方法。唯一的不同之处在于，此处使用密度函数来代替密度空间，因为此块的密度空间的数据很可能早已过时了。使用密度函数要慢许多，但如果这些遮挡光线仅仅是每帧从几个正在运动的、可见的对象中发出的，这方面的影响就可以忽略不计。A Survey of Deformable Modeling inComputer GraphicsAbstract: This paper presents a survey of the work done in modeling deformable objects within the computer graphics re

28、search community. The research has a long history and a wide variety of approaches have been used. This paper organizes the diversity of research by the technique used rather than by the application, although applications are discussed throughout. This paper presents some purely geometric approaches

29、 for modeling deformable objects, but focuses on physically based approaches. In the latter category are mass-spring models, finite element models, approximate continuum models, and low degree of freedom models. Special emphasis is placed on finite element models, which offer the greatest accuracy,

30、but have seen limited use in computer graphics. The paper also suggests important areas for future research.1IntroductionComputers have become an indispensable tool in modeling and simulation. As computational power increases, users and applications are demanding ever increasing levels of realism in

31、 these domains. This trend is particularly apparent in computer graphics where more sophisticated geometric shapes and physical objects are being modeled in the context of complex physical environments. In particular, the ability to model and manipulate deformable objects is essential to many applic

32、ations. Approaches for modeling object deformation range from non-physical methodswhere individual or groups of control points or shape parameters are manually adjusted for shape editing and designto methods based on continuum mechanicswhich account for the effects of material properties, external forces, and environmental constraints on object deformation.Deformable object modeling has been studied in computer graphics for more than two decades, across a range of applications. In computer-aided design and computer drawing applications, deformable models are used to cre