循环生成几何挂起，内存似乎很好答案

【问题标题】：Loop generating geometry hangs, memory seems fine循环生成几何挂起，内存似乎很好
【发布时间】：2013-08-20 11:27:10
【问题描述】：

如果我像这里一样在循环中生成 Tubes

    for (var y = 0; y < 800; y++){...}

尽管主内存似乎正常（任务管理器）并且 GPU 内存似乎也很好，但循环开始挂起并且不会结束。

它挂在生成管几何图形的循环中。它甚至没有被渲染。

有谁知道这是怎么回事？

奇怪的是 700 个循环在 5 秒内执行，800 个循环根本没有，或者真的非常慢。

【问题讨论】：

标签： three.js webgl

【解决方案1】：

好吧，我只是看了你的小提琴，我不确定你的整个循环。您在循环中创建了太多东西。参见例如材料。只需在循环外创建一次。然后将 vector[0] 和 [1] 定义移出循环并在循环内执行 vector[0].y = 。因此，您不会为每次运行创建 2 个 Three.Vector3()-objects。此外，将所有变量声明移到循环之外。就像 var line;在里面，你做 line = SPline ... 接下来，为什么不直接在循环内创建整个样条线，然后在循环之后创建一个 TubeGeometry，而不是创建数百个网格？好吧，无论如何我都不知道你的用例。

【讨论】：

感谢您的回答。主要问题是我没有注意到任何内存问题，所以我不明白为什么循环会挂起。我尝试尝试将材料设置在循环之外，但没有帮助。我需要数千个用不同颜色和不同样条顶点渲染的管子。
Javascript 对象有 64k 限制吗？
嗯，是的。几何的索引缓冲区只能处理 65k 个顶点。我认为还有一个 bufferGeometry Particle 示例，它展示了如何将多个 65k 顶点块与 BufferGeometry 一起使用。还有一个更高限制的扩展......见这里：stackoverflow.com/questions/4998278/…
如何判断缓冲区是否已满？
奇怪的是，如果框架函数后面的某个地方隐藏了 64k 限制，为什么 google chrome 会挂在 800 个绘制的样条上，而 Firfox 可以绘制更多。