madjestic / e1338 Goto Github PK

Why?
The reason is that every time we do a computation in 32bits Float (GPU),
we are losing precision.  CPU is 64bit Double.  Since we are dealing
with relativistic distances, we can have very larger values in matrices,
everything right in front of the camera can be very, very far away,
e.g. millions or hundreds of millions km away, or billions or hundreds
billions of meters, i.e. values like 10^(6..11).
 
At the same time, objects of the order of magnitude of 10^(1..10)m.
can be at a distance of just 10^(0..10)m.  I.o.w. our transform matrices
can have values with a large number of values either before, or behind
a dot, or both.  E.g. 9,999,999,999; 0.99; 150.99.
When multiplying such matrices, especially rotations, precision will suffer,
values after the dot may be culled or lost altogether,
partial values approaching integers, which will lead to artifacts,
especially when dealing with thin objects: faces on one side can visually
intersect faces of the opposite side, positions can be generally deformed
with visible imprecisions, z-fighting, etc.

Introducing logarithmic space correction in 32bits precision can only
make such artifacts worse.  On the contrary, if precision is preserved,
logarithmic space correction should help with rendering thin objects 
in coordinates with relativistic distances close to the camera.
 
Solution: do as little matrix math on the GPU side as possible,
only when precision loss is not an issue, move it to CPU side instead.
  
Drawbacks: it's extra work for CPU.
Addressing Drawbacks: high-performance tools, such as massiv, may
give enough performance with added benefit of high precision.