Would the author of floating origin blog please contact me?

Ah thanks @imerso, and I appreciate your own contribs.
I was thinking of directly proposing changes here anyway, so here goes:

With reference to the 32bit
When I began this investigation, graphics hardware was pretty much limited to 32bit, but it was starting to change. Now one can run doubles on cards like nvidia (see Ampere and CUDA-X). I have not used these APIs myself so cannot say much, however, one scientist reported to me he used all doubles on GPU for some simulation and it was slower than single precision.
My emphasis on SP now is related more to performance and the fact that floating origin can at the same time maintain high accuracy.

  1. fp32 can yield double the vector bandwidth of fp64: between cpu/compute unit and memory/cache.
  2. fp32 functions take less space and therefore can yield greater cache persistence, which in turn delivers better performance.

edit: Please change “The original article by Chris Thorne uses single-precision floats” to
“The original implementations by Chris Thorne used single-precision floats”
I originally planned and designed for a hybrid of double and single precision but want to completely exhaust all fp32 solutions before adding fp64 where it can enhance the lower precision code. There is a very important motivation for this: throwing fp64 at jitter problems early produces good results but hides the problems causing jitter. If I had taken this approach I would not have gained an early understanding of distant relative jitter and loss of degrees of freedom (demonstrated by the interaction “sliding” effect in see: Dimensional collapse bookmark and speed issues: Speed perception bookmark) and I would therefore have not developed general purpose solutions to these by now.

Feel free to include any of my text in the article yourself: this should a collaborative effort, after all.

@RaananW I was going to but for now I think it works better with @imerso mods his article. I was trying to work out the best way to approach a joint set of pages and he has already taken the initiative :slight_smile: So, for now, I will suggest edits to his page.

1 Like

Thanks @sebavan much appreciated. I like the idea behind Babylon. I would be good to have some implementations going here. However, I cannot divert much of my time to work on it.
So, if someone wants to try translating my code, let me know.

1 Like

Sorry but I have no more disposition this year, Chris. Some frustrated dreams had a big impact on me already, now this new event finished me in great style. Not a good moment for me.

Regarding the single or double precision argument, I did not read your other articles yet, but I still believe that using double precision is the most effective way to have centimeter precision on an astronomical scale (our entire solar system), without having to resort to more hacks. Modern machines have no problems to grasp double precision. In fact, Javascript uses doubles everywhere anyway. Doubles won’t reach the GPU, they’ll be converted to floats before the upload for rendering, and as the important objects will be within its reasonable range, we don’t see any jittering.

As a final example, my latest engine which is all based on double precision runs on different operating systems and hardware, and its Raspberry build (even on old Raspberry 2) runs at full speed in full hd.


I submitted an update request, adding an overview on floating origin and thanking immerso for his page.
Also, @immerso please don’t give up your dreams: keep at it :slight_smile: