What are the coordinate frame conventions for vehicle, camera, vec3 API?

I'm working on a camera script and I'm getting quite confused on what the directionality of BeamNG's coordinate system is.


Vehicles have 3 basis vectors, leftward, backward, and upward which are vec3(1,0,0), vec3(0,1,0), vec3(0,0,1) respectively.
This is because, for some reason, the vehicle's X direction is opposite to the world's X direction.
Thus for vehicles, +X,+Y,+Z map to leftward, backward, upward respectively.
When you set a vehicle's EulerRotation to (0,0,0) it'll appear with it's left side facing the +X and backwards side facing the +Y direction in grid,small,pure


(+Z direction would be upward, from the vehicle. perpendicular to +Y and +X)
However I check the Torque3d engine docs (https://docs.torque3d.org/for-designers/editors/world-editor/scene-editor#move-tool-gizmo) and it says the engine's coordinate system is +X,+Y,+Z is rightward, forward, upward.

What is the accurate, canonical handedness convention for BeamNG drive?

Also I'd love if someone could teach me how euler angles work in this game. The conventions are obscure/inconsistent there too. Idk if it's intrinsic or extrinsic, what basis vectors it uses, etc.


* for vehicle: position +X +Y +Z corresponds to vehicle's leftward, backward, upward direction vector, aka local versions of (1,0,0), (0,1,0), (0,0,1)
* rotationEuler: +X +Y +Z corresponds to pitch about X axis, car flips/pitches backwards
* roll about Y axis, car rolls rightwards
* yaw about Z axis, car steers rightwards
That's for vehicles. For the camera, +X +Y +Z corresponds to yaw, pitch, roll instead. And of course the directionality will be even harder to study because I haven't figured out which is intrinsic euler rotations and which is extrinsic euler rotations, what the basis vectors are, etc

If anyone wants to research into it keep in mind that there will probably be a lot of "transformations" between different coordinate frames of reference, which prolly explains why the roll-pitch-yaw correspondences are inconsistent between e.g a camera object and vehicle object.

These aren't comprehensive notes by any means. If I ever figure all the weird quirks for sure I'll post my learnings here in case some other modder gets confused.

Spoiler: By the way

some more cursed facts about the Beamng euler angles:
The Quaternion->Euler angle conversion function and Euler angle -> Quaternion conversion function aren't perfect inverses of each other . If you try and do example_quat->euler, then take that exact result euler triplet and convert it back to quat with the inbuilt euler->quat lua function (forgot which one exactly, it's in `mathlib.lua`) there will always be one component of the resultant quat that has the wrong sign. BeamNG Euler lua API for some reason maps a vec3 being x,y,z to euler angle with y,x,z, causing weird quirks.

There is also normalisation applied to euler triplets which stops the occurence of euler singularities, which might throw someone off.