如何防止透支？
这是一个很难在谷歌中搜索的问题，因为它在金融中有其他含义。
当然，我在这里的意思是“绘图”，如..计算机图形学..不是金钱..
我对防止 3D 绘图和 2D 绘图的透支感兴趣。
（我应该将它们分成两个不同的问题吗？）
我意识到这可能是一个非常广泛的问题，因为我没有指定要使用哪种技术。如果它太宽泛，也许对我可以阅读的一些资源的一些提示就可以了。
编辑：
我所说的过度绘制是指：
- 当你绘制太多的对象时，渲染单帧会非常慢；
- 当你绘制的区域比你需要的多时，渲染单帧会非常慢
This is a difficult question to search in Google since it has other meaning in finance.
Of course, what I mean here is "Drawing" as in .. computer graphics.. not money..
I am interested in preventing overdrawing for both 3D Drawing and 2D Drawing.
(should I make them into two different questions?)
I realize that this might be a very broad question since I didn't specify which technology to use. If it is too broad, maybe some hints on some resources I can read up will be okay.
EDIT:
What I mean by overdrawing is:
- when you draw too many objects, rendering single frame will be very slow
- when you draw more area than what you need, rendering a single frame will be very slow
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
根据距离和位置减少考虑绘制的对象数量（即拒绝视锥体之外的对象）。
还可以考虑使用某种基于对象的遮挡系统来允许大对象遮挡小对象。然而，除非您有很多形状相当规则的大型物体，否则这可能不值得。在某些情况下，您可以预处理静态对象的潜在可见集。
您的 API 通常会拒绝不面向视点的多边形，因为您通常不想绘制背面。
当涉及到实际渲染时间时，从前到后渲染不透明对象通常很有帮助，因此深度缓冲区测试最终会拒绝整个多边形。如果您打开了深度缓冲，这也适用于 2D。
请记住，这是一个性能优化问题。大多数应用程序不会出现严重的透支问题。使用诸如 Pix 或 NVIDIA PerfHUD 在花费资源修复问题之前衡量您的问题。
Reduce the number of objects you consider for drawing based on distance, and on position (ie. reject those outside of the viewing frustrum).
Also consider using some sort of object-based occlusion system to allow large objects to obscure small ones. However this may not be worth it unless you have a lot of large objects with fairly regular shapes. You can pre-process potentially visible sets for static objects in some cases.
Your API will typically reject polygons that are not facing the viewpoint also, since you typically don't want to draw the rear-face.
When it comes to actual rendering time, it's often helpful to render opaque objects from front-to-back, so that the depth-buffer tests end up rejecting entire polygons. This works for 2D too, if you have depth-buffering turned on.
Remember that this is a performance optimisation problem. Most applications will not have a significant problem with overdraw. Use tools like Pix or NVIDIA PerfHUD to measure your problem before you spend resources on fixing it.
这是一个相当复杂的话题。
首先要考虑的是视锥体剔除。它将过滤掉不在相机视野中的对象，以便您可以将它们传递到渲染阶段。
第二件事是对相机中的对象进行 Z 排序。最好从前到后渲染它们，这样近处的对象会将“近值”写入深度缓冲区，而远处对象的像素将不会被绘制，因为它们不会通过深度测试。这将节省 GPU 的填充率和像素着色器工作。但请注意，如果场景中有半透明对象，则应首先按从后到前的顺序绘制它们，以使 alpha 混合成为可能。
如果您使用某种空间分区，例如 Octree 或 四叉树。哪个更好取决于您的游戏。四叉树更适合大型开放空间，八叉树更适合多层室内空间。
并且不要忘记简单的背面剔除，可以通过单行启用DirectX 和 OpenGL 可防止绘制用背面看着相机的脸部。
It's quite complex topic.
First thing to consider is frustum culling. It will filter out objects that are not in camera’s field of view so you can just pass them on render stage.
The second thing is Z-sorting of objects that are in camera. It is better to render them from front to back so that near objects will write “near-value” to the depth buffer and far objects’ pixels will not be drawn since they will not pass depth test. This will save your GPU’s fill rate and pixel-shader work. Note however, if you have semitransparent objects in scene, they should be drawn first in back-to-front order to make alpha-blending possible.
Both things achievable if you use some kind of space partition such as Octree or Quadtree. Which is better depends on your game. Quadtree is better for big open spaces and Octree is better for in-door spaces with many levels.
And don't forget about simple back-face culling that can be enabled with single line in DirectX and OpenGL to prevent drawing of faces that are look at camera with theirs back-side.
问题确实太广泛了：o）查看这些“指针”并询问更具体的问题。
典型的过度绘制抑制剂有：
在稍高一点的逻辑级别上
编辑：添加模板测试，确实具有有趣的透支预防用途，尤其是在 2d/3d 组合中。
Question is really too broad :o) Check out these "pointers" and ask more specifically.
Typical overdraw inhibitors are:
on little bit higher logic level:
EDIT: added stencil test, has indeed interesting overdraw prevention uses especially in combination of 2d/3d.