优化重叠矩形的绘制 [英] Optimising the drawing of overlapping rectangles

问题描述

我有很多矩形，有些重叠.每个矩形都有一个绝对的z顺序和颜色. (每个矩形"实际上是粒子效果，网格或纹理的与轴对齐的边界框，并且可能是半透明的.但是，只要您不尝试将矩形剔除在其他矩形之后，它就更容易抽象化地思考彩色矩形. ，因此我将在问题描述中使用它:)

I have a large number of rectangles, and some overlap others; each rectangle has an absolute z-order and a colour. (Each 'rectangle' is actually the axis-aligned bounding box of a particle effect, mesh or texture and may be semi-transparent. But its easier to think abstractly about coloured rectangles as long as you don't try to cull rectangles behind others, so I will use that in the problem description:)

更改颜色"的成本非常高；连续绘制两个蓝色矩形比绘制两个不同颜色的矩形要快得多.

The cost of changing the 'colour' is quite high; its much faster to draw two blue rectangles in succession than it is to draw two different-coloured rectangles.

绘制甚至不在屏幕上的矩形的成本也很高，应该避免.

The cost of drawing rectangles that are not even on the screen is quite high too and should be avoided.

如果两个矩形不重叠，则它们相对于另一个的绘制顺序并不重要.只有当它们重叠时，z顺序才重要.

If two rectangles do not overlap, the order they are drawn relative to one-another is not important. Its only if they overlap that the z-order is important.

例如:

1(红色)和4(红色)可以绘制在一起.也可以将2(蓝色)和5(蓝色)以及3(绿色)和7(绿色)绘制在一起.但是必须在6(蓝色)之后绘制8(红色).因此，要么将所有三个红色绘制在一起，然后在两组中绘制蓝色，要么将所有蓝色绘制在一起，然后在两组中绘制红色.

1 (red) and 4 (red) can be drawn together. 2 (blue) and 5 (blue) can also be drawn together, as can 3 (green) and 7 (green). But 8 (red) must be drawn after 6 (blue). so its either we draw all three red together and draw the blue in two sets, or we draw all the blue together and draw the red in two sets.

某些矩形可能偶尔移动. (并非全部；已知某些矩形是静态的；已知其他矩形是可移动的.)

And some of the rectangles may move occasionally. (Not all of them; some rectangles are known to be static; others are known to move.)

我将在JavaScript/webGL中绘制该场景.

I will be drawing this scene in JavaScript/webGL.

我如何才能以合理的顺序绘制矩形以最大程度地减少颜色变化，同时又要权衡JavaScript清除代码与GPU的淘汰程度?

How can I draw the rectangles in a reasonable order to minimize colour changes, with a good trade-off of JavaScript culling code vs letting the GPU cull?

(仅计算出哪些矩形重叠以及哪些矩形可见是昂贵的.我有一个基本四叉树并且这极大地加快了我的场景的绘制速度(相比之下，整个场景只是发出绘图)；现在的问题是如何最大程度地减少OpenGL状态变化并尽可能多地连接属性数组)

(Just working out which rectangles overlap and which are visible is expensive. I have a basic quadtree and this sped my scene drawing up immensely (compared to just emitting the draw-ops for the whole scene); now the question is how to minimize OpenGL state changes and concatenate attribute arrays as much as possible)

UPDATE 我创建了一个非常简单的测试应用程序来说明问题并用作演示解决方案的基础:源代码在github上，可以轻松地分叉: https://github.com/williame/opt_rects

The source-code is on github and can easily be forked: https://github.com/williame/opt_rects

事实证明，制作具有足够状态更改的小测试应用程序以真正重现我在完整游戏中遇到的问题非常困难.在某些时候，您必须考虑到状态更改可能会非常昂贵.同样重要的是如何加快空间索引(演示中的四叉树)和整体方法.

It turns out its hard to make a little test app with sufficient state change to actually recreate the problem I see in my full game. At some point you'll have to take it as a given that state changes can be sufficiently expensive. What is also important is how to speed up the spatial index (quadtree in demo) and the overall approach.

推荐答案

您做出了非常错误的假设，即在桌面浏览器上获得的性能将以某种方式决定iPhone的性能.您需要了解，iPhone硬件实现了基于图块的延迟渲染，这意味着该片段无论如何，shader在管道中使用得非常晚.正如苹果自己所说("不要浪费CPU时间对对象进行前后排序")，对基元进行Z排序将不会给您带来什么性能上的好处.

You are making the very wrong assumption that the performance you will be getting on the desktop browser will somehow determine the performance on your iPhone. You need to understand that the iPhone hardware implements tile-based deferred rendering which means that the fragment shader is used very late in the pipeline anyway. As Apple themselves say ("Do not waste CPU time sorting objects front to back"), Z-sorting your primitives will get you little performance gain.

但是，这是我的建议:如果更改颜色的成本很高，请不要更改颜色:将其作为顶点属性传递，并将行为合并到一个超级着色器中，以便绘制所有内容一到几批甚至没有分拣.然后进行基准测试，并确定适合您平台的最佳批次大小.

But here’s my suggestion: if changing the colour is expensive, just don’t change the colour: pass it as a vertex attribute, and merge the behaviours into one super shader so you can draw everything in one or a few batches without even sorting. Then benchmark and determine the optimal batch size for your platform.

这篇关于优化重叠矩形的绘制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！