Skip to content

plan.md

Latest commit

 

History

History
32 lines (28 loc) · 3.81 KB

plan.md

File metadata and controls

32 lines (28 loc) · 3.81 KB

  1. Optimize TreeBatcher (src/foliage/tree-batcher.ts):

    • Import THREE at the top of src/foliage/tree-batcher.ts (it already does, but we need _scratchMatrix or write directly).
    • Actually wait, addInstance takes matrix (which is a THREE.Matrix4). The issue is that mesh.setMatrixAt(index, matrix) is called, which calls .toArray() and sets needsUpdate.
    • Wait, mesh.setMatrixAt(index, matrix) uses .toArray() internally. Wait, the memory guideline says: To eliminate CPU overhead and garbage collection spikes from Matrix4 composition (Object3D.updateMatrix and mesh.setMatrixAt) in high-frequency batcher loops, write position, rotation, and scale data directly into the flat Float32Array of the InstancedMesh's instanceMatrix.array...
    • So inside TreeBatcher.addInstance, we can change: 
      // ⚡ OPTIMIZATION: Write directly to instanceMatrix.array to bypass setMatrixAt overhead
matrix.toArray(mesh.instanceMatrix.array, index * 16);
    • Oh, tree-batcher.ts lines 481-555 use mesh.matrixWorld. The method addInstance receives matrix.

  2. Optimize Proximity Enter/Leave Math (src/systems/interaction.ts):

    • Line 143: try { obj.userData.onProximityEnter(playerPosition.distanceTo(obj.position)); } catch(e) ...
    • distanceTo uses Math.sqrt(). The proximity loop already calculated distSq.
    • Change playerPosition.distanceTo(obj.position) to use Math.sqrt(distSq) since distSq is already computed? Wait, the check for Enters is in a separate loop that doesn't have distSq.
    • Wait, nextNearby is populated based on distSq < radiusSq. When an object is found in nextNearby but not prevNearby, it's an Enter. We could either re-calculate distSq and Math.sqrt or just use distanceTo but we shouldn't use distanceTo().
    • Better: Math.sqrt(playerPosition.distanceToSquared(obj.position)) to avoid Vector3 allocation/overhead? Wait, distanceToSquared doesn't allocate. distanceTo() is just Math.sqrt(this.distanceToSquared(v)). Does distanceTo allocate? The memory guideline says: "avoid distanceTo() which uses the expensive Math.sqrt() function. Instead, use distanceToSquared() and compare it against pre-squared thresholds, or delay the square root calculation until after an early bounds check."
    • Ah, so since onProximityEnter expects a distance, we should pass Math.sqrt(playerPosition.distanceToSquared(obj.position)). Wait, if we use distanceToSquared we can just pass that? Does onProximityEnter need the exact distance, or can we pass the square root of distanceToSquared?

  3. Optimize Harpoon Line Math (src/gameplay/harpoon-line.ts):

    • Line 94: const distance = playerPos.distanceTo(anchor);
    • We can replace this with Math.sqrt(playerPos.distanceToSquared(anchor));

  4. Fix VRAM Leaks in Scene Removal:

    • src/rendering/shader-warmup.ts: Line 270 scene.remove(mesh); should also dispose the geometry and material. Wait, this.warmupGeometry.dispose() is called later, and the material is warmed up.
    • src/core/main.ts: Line 276 scene.remove(previewMushroom); doesn't dispose of the mushroom's geometry and material. The previewMushroom is removed from the scene and discarded. It should traverse and dispose of its geometries/materials.
    • src/systems/weather/weather-effects.ts: scene.remove(rainMesh);, scene.remove(mistMesh); but they seem to call percussionRain.dispose() and melodicMist.dispose() first. What about lightningLight?
    • src/core/deferred-init.ts: Line 208 scene.remove(dummyGroup); dummyGroup contains dummyMesh which has dummyGeo and dummyMat. They should be disposed! dummyGeo.dispose(); dummyMat.dispose();

  5. Pre commit instructions:

    • "Complete pre-commit steps to ensure proper testing, verification, review, and reflection are done."