Physics API should support vector objects

[Ulydev]

For methods with multiple vector parameters, should it support any combination of x,y,z and vectors? As an example, would https://lovr.org/docs/v0.13.0/Collider:applyForce accept only (x, y, z, px, py, pz) and (v, pv) or also (x, y, z, pv) and (v, px, py, pz)?

And what about getters? Would there be an optional boolean to return either x,y,z or a vector?

[bjornbytes]

I think the setters will accept any combination of vectors and numbers. This is similar to how other functions work, and there is a luax_readvec3 helper that makes it pretty easy by returning the next stack index to read from.

For getters, I'm not sure. I think those would probably stick to just returning numbers. You can always wrap it in a vec3 or pass it to vec3:set, which isn't too bad.

[bjornbytes]

Arg World:raycast is sooo painful without vectors!

[jmiskovic]

Even when accepting either vectors or numbers, raycast is still painful because of returned values are 6 numbers. Maybe optional argument could trigger using vec3 in raycast callback? Is this too complicated?

[bjornbytes]

Yeah, I think a parameter to control the return format is kind of awkward. An option that seems a little cleaner to me would be to accept "out args", where you can optionally pass 2 vectors as the last arguments, and they get filled in as the result.

I'm still trying to figure out whether it's okay to have functions in the API return vectors in general. There are things to think about like whether they should be permanent or temporary vectors, and if this could be annoying for people that aren't interested in using vector objects or something.

[jmiskovic]

My motivation is to drop xyz coordinates altogether from Lua code. Vector math is easier to write and read, less verbose and more high level. Several places in API make this hard and require manual conversion, for example syncing physics and graphics. Ideally, something like this should work: lovr.graphics.box('fill', boxCollider:getPose()). But that would mean returning mat4 object and not x,y,z,angle,ax,ay,az.

Regarding returning permanent vs temp vectors. Always permanent is not an option, raycasting is common operation. I would be ok with API always returning temp vectors. Better than having to remember which function returns which. LOVR quite helpfully points out where exactly in code the expired temp vector was used.