suggestion with double precision version of engine

[steve3d]

Now ungine have a big step forward to much higher precision with double precision number, But, current implication seems not so good,

 

I've just played with double precision engine, but found some problems.

1. after this version, we have to change all reference from vec3 to Vec3, this will cause incompatibility. so, if in USE_DOUBLE defined in engine, and if all functions of engine need dvec3, why not change vec3 to fvec3 and typedef vec3 type, also similar to vec2, mat4 etc..?
   
2. why dmat4 has a 4x3 matrix not 4x4, this is huge incompatibility. or you guys designed dmat4 as 4x3 matrix not 4x4, but mat4 has 4x4 matrix. this confused me a lot.
   
3. if engine build with USE_DOUBLE, then why there is no copy constructor function in dvec3 which use vec3 as it's argument, I think we all knows lower precision number can be safely casted to higher precision without any precision lost, right? if problems 1 can not be solved and engine must use current design, then I think this will improve the compatibility of using float version world/scripts to double version engine without any change.
   

 

I've checked the manual, manual said dmat4 can not have last row, why? for example, I need a Catmull-Rom curves(which I've already added to engine as WorldCurve class), it's need a Hermite matrix as follows

mCoeffs.m00 = 2;
mCoeffs.m01 = -2;
mCoeffs.m02 = 1;
mCoeffs.m03 = 1;
mCoeffs.m10 = -3;
mCoeffs.m11 = 3;
mCoeffs.m12 = -2;
mCoeffs.m13 = -1;
mCoeffs.m20 = 0;
mCoeffs.m21 = 0;
mCoeffs.m22 = 1;
mCoeffs.m23 = 0;
mCoeffs.m30 = 1;
mCoeffs.m31 = 0;
mCoeffs.m32 = 0;
mCoeffs.m33 = 0;

 

this matrix's last row can not be 0 0 0 1, then this means I can not use double version of curve. this is strange setting, why? :blink:

[steve3d]

as for the memory and performance difference between the float version and double version engine. I've made a little test with heaven scene.

 

float		double
FPS:	 105.2		104.0
Scores:	 2649		2621
Min FPS: 45.2		33.3
Max FPS: 258.9		260.0
Memory	 322M		360M

 

memory usage increased 12%, but still acceptable, as for the performance, We can say the difference can be ignored.

[luke.errington]

I've just played with double precision engine, but found some problems.

1. after this version, we have to change all reference from vec3 to Vec3, this will cause incompatibility. so, if in USE_DOUBLE defined in engine, and if all functions of engine need dvec3, why not change vec3 to fvec3 and typedef vec3 type, also similar to vec2, mat4 etc..?
   
2. why dmat4 has a 4x3 matrix not 4x4, this is huge incompatibility. or you guys designed dmat4 as 4x3 matrix not 4x4, but mat4 has 4x4 matrix. this confused me a lot.
   
3. if engine build with USE_DOUBLE, then why there is no copy constructor function in dvec3 which use vec3 as it's argument, I think we all knows lower precision number can be safely casted to higher precision without any precision lost, right? if problems 1 can not be solved and engine must use current design, then I think this will improve the compatibility of using float version world/scripts to double version engine without any change.
   

 

While the new functionality is good, it required us to do a fair bit of porting of current code because the double-precision and single-precision interface/capabilities are not symmetric or consistent. This is particularly for C++, but applied for the script side too. For instance, the code for creating a rotation matrix in C++ is different depending on whether you are working with dmat4 or mat4. (Of course, to get these consistent probably requires the interface for single-precision to change too, which may upset a number of people initially, but it will result in a more consistent manner of using the engine, and it will allow projects to easily switch between double and single precision which is not the case at the moment.)

 

It would be good if the interface was consistent for both.

[manguste]

Which type is used, vec3 or dvec4, mat4 and dmat4, etc. matters ONLY for world coordinates values. You can use ANY types for input arguments or returned values in all other cases in both builds.

For example:

1. mat4 can be used in a double precision build
   
2. dvec3 can be used in a single precision build
   

As long as it is not a world coordinates value, it can be any type. Check the following function that takes different arguments in different builds:

// single precision build:
// vec3 for position, vec4 for color 
engine.visualizer.renderMessage3D(vec3,string,vec4,int);
// double precision build:
// dvec3 for position, vec4 is still used for color 
engine.visualizer.renderMessage3D(dvec3,string,vec4,int);

 

this matrix's last row can not be 0 0 0 1, then this means I can not use double version of curve. this is strange setting, why?

dmat4 is basically for world transformations only (translation, scaling, rotation). It is not used for 3D projection, that's why the last row can be skipped. Such approach allows to avoid performance degradation and large memory consumption when a double precision build is used. For any other purposes mat4 that has all components can be used in both builds.

 

 

why there is no copy constructor function in dvec3 which use vec3 as it's argument, I think we all knows lower precision number can be safely casted to higher precision without any precision lost, right? if problems 1 can not be solved and engine must use current design, then I think this will improve the compatibility of using float version world/scripts to double version engine without any change.

This is a very dangerous conversion, because it will make the code prone to all kinds of imprecision bugs when dealing with world coordinates. It will be a pure debugging hell to find out why some object are jittering in the double build, while others are rendered ok. You'll never know, as vec3 will be silently converted to dvec3 without any errors.

 

 

For instance, the code for creating a rotation matrix in C++ is different depending on whether you are working with dmat4 or mat4.

Well, the last row is irrelevant for rotation in any way, while not storing it makes dmat4 much smaller in size :)

[steve3d]

thanks for explanation