UNIGINE script double data type

[ulf.schroeter]

Proposal

 

Addition of double-precision-support to UNIGINE script

 

Reason

 

64bit-double precision is required for large-world coordinates (e.g. earth-centric) calculations.

 

Features

 

• new core double data type
  
• Unigine::Variable double support
  
• Math Functions double support
  

[alexei.garbuzenko]

Same for 64-bit integers. We need it as core type, not as user class!

[frustum]

I have finished double and long long types support in Unigine Script.

 

There are new data types: long, double, dvec3, dvec4.

 

1.0 will be treated as double.

1L or 1l will be treated as long.

 

Any mathematic operation with double will produce double as result:

vec3(1.0f) * 1.0 result will be dvec3

 

Because of this 'f' postfix after floating point numbers is very important from performance and memory consumption points of view.

 

Support of double and long long types will be available next update.

[ulf.schroeter]

Perfect ! Any chance for something like dmat4 ?

[frustum]

Perfect ! Any chance for something like dmat4 ?

 

I will add special transformation class for nodes, which will be consists of mat3 and dvec3 parts.

dmat4 is very memory wasteful we shouldn't keep 64 precision for rotation and scaling.

[ulf.schroeter]

I will add special transformation class for nodes, which will be consists of mat3 and dvec3 parts.

dmat4 is very memory wasteful we shouldn't keep 64 precision for rotation and scaling.

 

you get all my respect for 1) your work attitude 2) your solutions !

[frustum]

you get all my respect for 1) your work attitude 2) your solutions !

 

Thank you:)

[frustum]

There are several #pragma directives for easy script upgrading:

 

to treat all floating point constants as float:

#pragma no_double

 

to stop script compilation on double constant:

#pragma warn_double

 

to treat all integer constants as int:

#pragma no_long

 

to stop script compilation on long constant:

#pragma warn_long

[ulf.schroeter]

I will add special transformation class for nodes, which will be consists of mat3 and dvec3 parts.

dmat4 is very memory wasteful we shouldn't keep 64 precision for rotation and scaling.

 

Hi alex, will this special node transformation class be integral part of each world node and solve general floating-point-issues mentioned in the following article ?

 

 

having double precision support within UNIGINE script is definitely a good first step, but I guess some major refactoring of the general node transformation pipeline is still required, right ?

 

We already tried to implement a floating-camera origin approach, where the camera stays at the coord system origin, while we are translating multiple top-level scene nodes towards the camera instead. Both camera and each top-level node require an absolute world-position in double-precision used for calculation of camera-relativ node position with float-precision each frame for each top-level node.

 

The upcomming UNIGINE double script support and special transformation class for nodes will at least provide the required higher precision for absolute world node placement, which is great.

 

Still this approach has some fundamental problems without additional engine modifications

 

• continous translation of top-level nodes forces cpu-intensive general spatial index updates (which might be unnesessary as spatial relations stay the same when moving the whole world )
  
• world-relative particles do not follow world movement, world-movement-based shift emitters falsely spawn particles due to "camera-induced" world movement
  
• .....