持续移动ThreeJS相机导致其他LERP动画大幅变慢？

我用ThreeJS搭建了模拟第一人称射击（FPS）的场景，动画循环中使用了一段来自ThreeJS Controls示例的代码。场景运行正常，但持续移动相机（比如FPS游戏中的Strafing横向移动操作）时，正在执行Lerp插值的模型动画会大幅变慢，几乎停滞。想请教该问题的成因是什么？能否解决？

const onObject = userIsLookingAtObjects.length > 0;

let delta = (currentTime - prevTime) / 1000;

// Limit long delay gaps, which indicate
//  a background task interfered with us and
//  we don't want the camera/user
const limitDelta = 0.2;

if (delta > limitDelta) {
    delta = Math.min(limitDelta, delta);
    console.warn(`${errPrefix}Capping delta time at: ${limitDelta}`);
}

velocity.x -= velocity.x * 10.0 * delta;
velocity.z -= velocity.z * 10.0 * delta;

velocity.y -= 9.8 * 100.0 * delta; // 100.0 = mass

// ROS: The Number() constructor is simply being used
//  to convert the TRUE/FALSE move<direction> values
//  to a number in the following set of values: [-1, 0, 1]
direction.z = Number(moveForward) - Number(moveBackward);
direction.x = Number(moveRight) - Number(moveLeft);
direction.normalize(); // this ensures consistent movements in all directions

if (moveForward || moveBackward)
    velocity.z -= direction.z * 400.0 * delta;
if (moveLeft || moveRight)
    velocity.x -= direction.x * 400.0 * delta;

if (onObject === true) {
    // ROS: This appears to be part of a check to allow jumping or
    //  not.  See the raycast intersection code above involving
    //  onObject.
    velocity.y = Math.max(0, velocity.y);
    canJump = true;

    if (g_BreakHerePlease)
        // This aids tracing using Chrome DevTools.  See pointerlock.js
        //  for the keystroke that sets g_BreakHerePlease to TRUE.
        console.info(`${errPrefix}Set DevTools breakpoint here.`);
}

g_ThreeJsControls.moveRight(-velocity.x * delta);
g_ThreeJsControls.moveForward(-velocity.z * delta);

g_ThreeJsControls.getObject().position.y += (velocity.y * delta); // new behavior

if (g_ThreeJsControls.getObject().position.y < 10) {
    velocity.y = 0;
    g_ThreeJsControls.getObject().position.y = 10;

    canJump = true;
}

成因分析 #

• 核心问题是动画与相机逻辑共用delta时间，且相机移动导致主线程负载升高时，delta被强制限制，拖慢了Lerp动画进度
• 你这段代码里的delta被限制在0.2秒以内，当持续移动相机时，浏览器主线程需要处理更多的物理计算、Controls更新，可能还伴随userIsLookingAtObjects的射线检测，导致实际帧率下降，帧间隔被拉长。此时delta被强制设为0.2，而如果你的Lerp动画直接复用这个delta，相当于每帧最多只让动画推进0.2秒的进度，实际动画速度就会被大幅压低。
• 另外，如果Lerp动画的步长是基于帧率的固定比例（比如lerp(target, 0.1)）而非基于时间的速度，帧率下降时动画自然会变慢。

解决方案 #

1. 给模型动画单独维护时间追踪 #

不要和相机逻辑共用同一个prevTime，为Lerp动画单独记录时间戳，计算独立的delta值，确保动画进度只和实际流逝时间挂钩，不受相机移动的性能波动影响：

// 单独为动画初始化时间变量
let animationPrevTime = performance.now();

function animate() {
    requestAnimationFrame(animate);
    const currentTime = performance.now();

    // 相机逻辑的delta（保留原代码的处理逻辑）
    let cameraDelta = (currentTime - prevTime) / 1000;
    const limitDelta = 0.2;
    if (cameraDelta > limitDelta) {
        cameraDelta = limitDelta;
        console.warn(`${errPrefix}Capping delta time at: ${limitDelta}`);
    }
    // ... 原相机移动、物理计算逻辑 ...
    prevTime = currentTime;

    // 动画专用的delta，不做上限限制（或单独设置合理上限）
    const animationDelta = (currentTime - animationPrevTime) / 1000;
    // 基于时间的Lerp动画，比如每秒完成80%的插值
    model.position.lerp(targetPosition, animationDelta * 0.8);
    // 或者用线性插值：model.position.x += (targetX - model.position.x) * animationDelta * 5;
    
    animationPrevTime = currentTime;

    renderer.render(scene, camera);
}

2. 优化相机移动的性能开销 #

• 检查userIsLookingAtObjects的射线检测逻辑，比如是否每帧都对大量对象做射线检测。可以改成每2-3帧检测一次，或者只检测相机前方一定范围内的对象，减少主线程负载。
• 避免在动画循环里做DOM操作、复杂计算，把这些逻辑移到requestAnimationFrame之外，或者用Web Worker处理。

3. 让Lerp动画基于时间而非帧率 #

把Lerp的步长从固定比例改成基于时间的速度值，比如不要用model.position.lerp(target, 0.1)（每帧插值10%，帧率低时动画慢），而是用model.position.lerp(target, delta * speed)，其中speed是每秒完成的插值比例（比如0.8代表每秒完成80%的插值），这样不管帧率多少，动画速度都是一致的。

内容的提问来源于stack exchange，提问作者Robert Oschler