Allow double precision modelview

[celyk]

Allows user shaders to access a valid MODELVIEW_MATRIX by moving the precision calculation.

We should consider adding a helper function that can handle the high precision multiplication of two matrices.

Bugsquad edit:

• Fixes Double Precision Multi-mesh based rendering applies transforms incorrectly #104654
• Fixes Double Precision MultiMeshInstance3D does not Scale Properly #101139
• Fixes GPUParticles3D billboarding is affected by particle's global rotation when precision=double #76388
• Fixes CPU Particles not emitting in correct direction with double precision #89061
• Fixes GPUParticles3D parameter local_coords not working with doubles builds of the engine #73383
• Supersedes Fix billboarding of GPU particles in double precision builds #89165

[cridenour]

Thank you @celyk for this fantastic work.

I've tested the MRPs and this affects the following:

Closes #104654
Closes #101139
Closes #76388
Closes #89061
Closes #73383
Supersedes #89165

[clayjohn]

This change loses the precision benefits of using the split operators. With this the transforms are just using single precision.

The most important part of the double precision approach is to separate the translation of the vertex position into two additions (1 add the vertex position to the modelview translation, 2 add in the error term.

This PR completely removes that operation and combines everything ahead of time. Which means that when transforming the vertex we lose the extra precision and effectively do a single precision transformation.

What this appears to improve is the addition of the multimesh instance translation with the normal instance transform

[celyk]

the transforms are just using single precision

Yes, but the transformation from model to view space does not need double. The translation component of the transformation is small enough because it's centred around the camera.

when transforming the vertex we lose the extra precision and effectively do a single precision transformation

This is what you do anyway? The vertex never goes into double_add_vec3(), and the translation uses regular addition.

This PR completely removes that operation and combines everything ahead of time

But I was careful not to alter calls to double_add_vec3(). Notice that each of those calls should give the same output as before, thus respecting the error term.

Whether the final translation is applied through an addition or a translation matrix, what difference does it make? Either way it becomes a single precision addition by the end.

[celyk]

Tested using Calinou's Large World Coordinates demo

[fire]

@celyk can you post the MRP as the issue report too. It'll help. Like off and on.

[celyk]

Sorry fire I'm not sure what you mean. The MRP (the official demo project) is provided, you want me to put this at the top?

[fire]

Let me try message you.

I wanted to double check that the https://github.com/godotengine/godot/files/13539578/INV_VIEW_MATRIX.bug.Game.Project.zip MRP would be fixed in the situation where the camera is far away from the origin due to concerns from @clayjohn

[celyk]

No that will not be fixed, because my PR only applies to MODELVIEW_MATRIX. But I'm thinking of making a proposal for how the other transforms can be addressed

[celyk]

To elaborate on my idea of a helper function, here's some example code (untested)

// Multiplies a double mat4 with a double vec3
mat4 double_mul_mat4_vec3(mat4 base_a, vec3 prec_a, vec3 base_b, vec3 prec_b, out vec3 out_precision) {
	// Assume that M * vec4(p,1) == M[3].xyz + mat3(M) * p
	base_b = mat3(base_a) * base_b;
	base_b = double_add_vec3(base_a[3].xyz, prec_a, base_b, prec_b, out_precision);
	return base_b;
}

// Multiplies a double mat4 with a double mat4
mat4 double_mul_mat4(mat4 base_a, vec3 prec_a, mat4 base_b, vec3 prec_b, out vec3 out_precision) {
	// Only the translation part supports double precision at the moment.

	// Single precision transform just to fill the mat3 basis. Ignore the last column
	mat4 T = base_a * base_b;

	// Transform the origin of base_b, and pass out the error term
	T[3].xyz = double_mul_mat4_vec3(base_a, prec_a, base_b[3].xyz, prec_b, out_precision);

	return T;
}
#endif

If I'm correct this should allow arbitrary concatenation of transforms, and this PR would reduce to:

#ifdef USE_DOUBLE_PRECISION
	vec3 temp_precision;
	mat4 modelview = double_mul_mat4(scene_data.view_matrix, view_precision, model_matrix, model_precision, temp_precision);
#else
	mat4 modelview = scene_data.view_matrix * model_matrix;
#endif

[celyk]

Hmmm, double_mul_mat4_vec3() looks wrong for transforming base_b with single precision. The reason this is ok in the PR is we know the vector is already small relative to the camera.

[clayjohn]

Thank you for your clarification. On second thought this does seem safe.

I was forgetting that the original adds the model transform and camera transforms together with high precision but adds the result of that to the vertex position with single precision. So indeed, this does do the final operation in single precision, but that doesn't change from how it was before.

[clayjohn]

The final step before merging is to rebase and then squash all the commits together so that the whole PR only contains 1 big commit with all your changes. We like to merge one commit at a time to keep the git history clean and navigable.

If you don't know how to do that, we have a helpful tutorial in the official documentation https://docs.godotengine.org/en/latest/community/contributing/pr_workflow.html#the-interactive-rebase

[clayjohn]

Looks great! I've queued this up for Beta 2 :)

[Repiteo]

Thanks! Congratulations on your first merged contribution! 🎉