Reimplement Projection in rust

[lilizoey]

The classes Basis, Transform2D, Transform3D, and Projection, are all matrix-based classes. All of them except Projection have most of their methods largely reimplemented in rust, mainly for performance reasons as crossing the ffi-boundary can be expensive.

Projection is mainly used as a 4x4 graphics projection matrix. So if you're familiar with graphics programming this would be a good thing to do.

The projection impl should ideally look similar to Basis, Transform2D, and Transform3D.

In addition, writing tests would be needed. Both unit tests for code that can be tested entirely in rust, but also integration tests. See here for an example of what integration tests could look like.

The original PR, #124, that added Projection and the other matrix-types to the bindings can also be useful to look at.

For more information about Projection see:
docs
source code

[Dheatly23]

Hello, i'm trying to crack this issue and found a problem. In static method create_perspective_hmd the argument eye can be neither 1 or 2, in Godot source the behavior is defined (although undocumented). Should we provide neither/zero value in the enum?

[Bromeon]

What happens in that case (you happen to have a link to the source)?

If it's not documented, I tend to consider it as an implementation detail that can change any moment 🤔

[Dheatly23]

In projection.cpp

	switch (p_eye) {
		case 1: { // left eye
			left = -xmax + frustumshift;
			right = xmax + frustumshift;
			modeltranslation = p_intraocular_dist / 2.0;
		} break;
		case 2: { // right eye
			left = -xmax - frustumshift;
			right = xmax - frustumshift;
			modeltranslation = -p_intraocular_dist / 2.0;
		} break;
		default: { // mono, should give the same result as set_perspective(p_fovy_degrees,p_aspect,p_z_near,p_z_far,p_flip_fov)
			left = -xmax;
			right = xmax;
			modeltranslation = 0.0;
		} break;
	}

I guess it's fine to leave it as-is. But let's just say for consideration and completion.

[lilizoey]

  default: { // mono, should give the same result as set_perspective(p_fovy_degrees,p_aspect,p_z_near,p_z_far,p_flip_fov)

As they note here, this should be the same as create_perspective. You could add to the documentation of the function that if people want this functionality, they should use create_perspective instead.