OpenGL平滑相机移动，计算速度比渲染慢
我对OpenGL中的相机运动感到困惑。 作为一个例子，我读过[0]，但我不确定哪种解决方案最适合我。 这是我想要实现的：
最后一点需要大量的计算（目前大约需要20秒！希望这会随着进一步的优化而降低），但是大部分关于我读取的运动的教程通常都基于假设渲染是最耗时的步骤。
现在（至少第一次）我想将相机从一个位置移动到另一个位置，使其看起来像是一个线性运动。 我可以通过任意数量的步骤来分解摄像头的位移（旋转/平移），但是我不知道如何在主循环中安排它，以便在渲染过程中不会有任何暂停。 我是否需要并行化计算和渲染？
我看到的很多相机移动示例都使用了gluLookAt函数，但更改模型视图矩阵对我来说似乎已经足够了，是否有任何限制？
[0] http://dewitters.koonsolo.com/gameloop.html
这听起来像你的计算总是比实时渲染慢，所以对我来说最有意义的设计是“实时”工作渲染和“生产”渲染的分离。 例如，您可以拥有一个执行繁重计算的线程，并将结果存储在内存或文件中以便快速查找。 当你在一个单独的线程中渲染它们时，你可以让这个线程替换不太精确的模型。
任何形式的实时交互 - 即通过模型进行的任何交互式移动 - 的游戏名称都是尽可能多地将计算移出渲染线程。 你希望你的渲染只能从模型中查找数据并且并行更新模型。
所有教程都关注渲染速度的原因是他们忽略了（为了范围）模型是如何生成的 - 为了简洁起见，他们只是使用茶壶或文件中的模型，并且专注于渲染性能只要。 对于任何需要计算或改变模型的任务（例如对象正在移动并具有物理效果的3D游戏），计算渲染循环中的所有内容以使渲染尽可能平滑是标准的，即使“重新渲染陈旧的模型。
如果你不想混淆线程，你可以通过包含“加载”或“编译”步骤来完成一个穷人的版本，在这个步骤中你通常会跳过重建你的模型，但是在按键或菜单操作中，你重建了整个模型，同时让用户等待。 模型建立之后，他们可以自由导航，跳过计算，直到另一个手势重新加载或重新编译模型。 这是一个很好的中间步骤，因为如果您决定长时间停顿不符合您的要求，它可以逐渐导致以后处理线程。
仅供参考， gluLookAt()在模型视图矩阵上运行。
如果您有一个冻结渲染过程的函数，则可能需要考虑将该函数移至第二个线程，以便在处理自定义函数时不影响渲染。
链接地址: http://www.djcxy.com/p/60417.html上一篇: OpenGL smooth camera movement with computations slower than rendering