在基于HTML5 3d-tranform的模拟游戏中，每英尺像素的比例效率最高？

Question

我的问题并不常见，而且我认为需要一些背景才能充分说明问题，所以这里有......

我有一个类似于Kieth Clarks'的3d世界引擎，但没有所有酷炫的灯光效果。相反，我还有一些其他沉浸式3D特权也很昂贵，并选择伪造照明，以便能够在移动设备上实现最复杂的功能，而不会显着丢失许多帧。

我有css像素与对象大小的近似视觉/空间比例（不说话变换比例）。例如，50px约为5英尺。请注意，我并不是想在现实世界中建模精确的尺寸，只是足够接近相当令人信服。无论如何，这意味着大对象通常是从tile元素100px ^ 2构建的。因此，一个非常简单的1车库，小屋等很容易建模为由div或任何你想要的100px立方体。通常我将墙壁和顶部div放在底部div中，定位使其充当底座，无需额外的包含元素。

现在，平铺可以是任何2d px比率，但我使用100px ^ 2用于大型平铺css类，66px，50px，20px，10px等用于较小的平铺类，以使标记更简单，更容易改变px＆＃34; scale＆＃34;在＆＃34;世界＆＃34;通过css表，或稍后在运行时样式更改期间。

需要很多的瓷砖来模拟复杂的对象。 Obvi，当您添加对象，动画，尤其是大型动画或复杂形状（如圆柱体或球体）时，帧速率上的潜在消耗呈指数级叠加，并且具有填充的模拟环境，尤其是在外部或任何可以看到很多内容的地方一次。

我已经完全重写了这个东西三次以适应一些重大变化，使用不同的＆＃34;物理尺度＆＃34;比。一旦达到足够的复杂性，很明显当使用不同的像素与英尺的比率（或米，3英尺足够接近）时，渲染效率存在巨大差异。基本上它可以计算像素/英尺，但重要的是要注意基本的瓷砖尺寸比1车库车门大一点。

这种差异并不像看起来那么明显，例如更多像素更多的gpu。一些实验证明在100px：10ft（我现在使用的是什么）而不是50px：10ft时效率更高，这是我在第一个版本中使用的。

引擎的第二个版本比第一个和第三个版本更有效，而不仅仅是因为这个原因。涉及到不同的效果，以及现在对于此事物的目的至关重要的特殊功能，因此使用多少像素来制作它真的非常耗时。

为了让发动机正常工作，我必须考虑各个方面，例如css透视，透视原点，旋转木马的高度和距离，以及许多没有直接相关的物理视角线索。 css或DOM属性，并且不容易转换为数字我可以使用等式换出。此外，如果您不小心，更改其中一个可能会导致适当的渲染，当然如闪光，视觉超级位置，明显的z顺序（不是真正的z顺序）不正确等，或者只是制作视觉透视外观＆＃34; wierd＆＃34;，即使它更有效率而不是丢帧，所以进行这种改变是一个真正的麻烦，并需要花费大量时间和页面重新加载才能使其正确

现在我的问题是：

性能与像素到英尺的理想尺寸比例是多少？ 我甚至尝试过很小，比如1px是一辆汽车的大小而且不同转换舞台的比例，使其看起来正确。我可以通过这种方式收集更多的效率，但它会让物理方式的数字无法发挥，即使我调整它们，我对事物的运动方式也不太满意。几乎就像你将自己缩小到一个蜘蛛的大小，你和你的相对大小的行为会比现在有很大的不同。

我应该小一点放大吗？我应该使用更大的图像切片并转换：scale3d整个阶段下来吗？或者我应该只使用小图像和平铺元素？我应该使用div作为图块，还是在css 3d空间中渲染时效率更高的新语义标签之一？

上述组合似乎更有效，但它不是一条直线。几乎像谐波一样。它是一个周期性的。在小到大的像素/英尺比率连续体中，一些较小的尺寸似乎比一些较大尺寸的 效率低。

有一个演示可以测试您的浏览器可以有效渲染多少个多维数据集，但我想知道是否有人发布了描述不同多维数据集或不同立方体像素大小的结果，或者是否有人在这里试过像这样的东西。

附录：这主要适用于Chrome Android作为即时应用程序或嵌入在webview中，但希望Firefox能够很快赶上，因为它无法处理尽可能多的多维数据集。我会喜欢的。

测试空间的几个截图...注意天空是圆的。这是立体视图，需要最多的处理。 SBS视图效率更高，因为它们使用视口的一半或更少，因此渲染较少，因为每只眼睛的视图是浮雕宽度的一半。 也是混合浮雕视图的开销。