request for lerp(a, b, c)

Description of the problem

currently objects are defined

object.set(a, b, c)

but, for some reason, the lerp function goes … 🤷‍♂️

object.lerp(new ObjectConstructor(a, b, c), alpha)

all that i have seen, vectors, colors, etc. the constructor is unnecessary, creates memory overhead (in a loop, class construction every frame), makes it harder to operate (dummy objects to save memory), and conflicts with the set method.

if this api would be consistent it would open crazy possibilities in the react world. it could behave like apples swiftUI basically, which would be a game changer:

function AnimatedPingPong() {
  // define state
  const [x, set] = useState(true)
  // flip state every second
  useEffect(() => void setInterval(() => set(x => !x), 1000), [])
  // write out state as x swinging between -1 and 1
  return (
    <mesh position={[x ? -1 : 1, 0, 0]} position-lerp={0.1}>
      <sphereBufferGeometry attach="geometry" />
    </mesh>
}

automated animation would not be possible today, because due to the api the reconciler must know how the constructor is shaped, which it can’t. it doesn’t what what a color is or that the argument needs to be shaped { x: 1, y: 2, z: 3 }.

Suggestion

just allow both:

vector.set(1, 2, 3)
vector.lerp(1, 2, 3, 0.1)
vector.lerp(new Vector(1, 2, 3), 0.1)

color.set("red")
vector.lerp("red", 0.1)
vector.lerp(new Color("red"), 0.1)

• very easy to implement
• can be made typesafe in TS
• it’s backwards compatible
• saves memory
• makes threejs easier
• enables swiftUI-like behaviour in the declarative world. 👍

or:

vector.set(1, 2, 3)
vector.lerp(1, 2, 3, 0.1)
vector.lerpVector(new Vector(1, 2, 3), 0.1)

color.set("red")
vector.lerp("red", 0.1)
vector.lerpColor(new Color("red"), 0.1)

could at least be made backward compatible for a couple of months by testing against props.

[donmccurdy]

Our usage pattern is fairly consistent: set(...) re-initializes an object from its primary member properties, copy(...) re-initializes an object from another object of the same type. lerp(...) is consistent with the latter, as are most modifier methods, so I don’t quite follow the consistency argument on this.

On memory usage, we universally discourage creating objects in the render loop — but we accomplish that with an inversion of the order you’re suggesting. The caller is responsible for reusing a parameter across calls:

var _v = new THREE.Vector3(...);

function hot ( x, y, z ) {
  _v.set( x, y, z );
  mesh.position.lerp( _v, 0.5 );
}

So this proposal doesn’t inherently save memory, it shifts the responsibility for saving memory. Not saying that as an argument against your suggestion, but to clarify the effects here. I couldn’t tell you whether that pattern is compatible with a reconciler, and maybe that’s the core question.

Is this request specific to the lerp method? Or would the same argument apply to Vector3’s addScaledVector, applyAxisAngle, applyEuler, applyMatrix3, applyMatrix4, clamp, cross, distanceTo, divide, dot, max, min,muliply, … ? The application to lerp(), specifically, doesn’t seem unique. Supporting primitive values interchangeably with Math classes would be a pretty major change, library-wide. 🤔

[drcmda]

you’re right, a constructor map with temp objects could indeed work, nice idea!