
A massive fractal in days, not years [pdf] - strangecasts
http://www.jcgt.org/published/0009/02/02/paper.pdf
======
klipt
Co-authored by Tom Duff, originator of Duff's device!

[https://en.wikipedia.org/wiki/Duff's_device](https://en.wikipedia.org/wiki/Duff's_device)

------
whizzter
Really feels like an exercise in making a bad solution fly (Generating a huge
triangle mesh before rendering it). If you use distance functions(SDF) to your
Julia set then with raymarching you can compute the surface directly without
taking the detour via a huge mesh, dunno exactly what Julia set they are using
here but other sets have been directly rendered for the last 10 year in
realtime (adding pathtracing would probably set back the perf a tad but still
be faster than this detour).

[https://www.iquilezles.org/www/articles/juliasets3d/juliaset...](https://www.iquilezles.org/www/articles/juliasets3d/juliasets3d.htm)
(There are links to youtube recordings of the realtime renders as well as
actual code samples on shadertoy)

~~~
tomsmeding
They say in the article that while there are distance estimation functions for
normal quadratic Julia sets, such functions are not known for these higher-
order rational Julia-like functions.

~~~
whizzter
So the day after writing this i noticed that Inigo went ahead and made a
raymarching rendering of the bunny on _CPU_ in a _MINUTE_, seems there was
problems with the GPU variation that probably would have been interactive.

[https://twitter.com/iquilezles/status/1295932323242811393?p=...](https://twitter.com/iquilezles/status/1295932323242811393?p=p)

------
Dylan16807
> the scalability of the technique was limited because it used high-order
> rationals requiring 80 bits of precision. We address the sources of
> numerical difficulty and allow the same computation to be performed using 64
> bits. Crucially, this enables computation on the GPU, and computing a
> 10-billion-triangle model now takes 17 days instead of 10 years.

While improving numerical stability is interesting and useful work, a GPU
isn't strictly limited to 64 bit math. You can glue two 64-bit floats together
to act like a much more precise float. It will be a big hit to efficiency, but
nowhere near a 200x hit!

~~~
tomsmeding
How do you propose glueing together two floating-point numbers? Concatenating
the exponents and mantissas sounds good, but isn't implementable using the
existing floating-point hardware because the operations are now intrinsically
coupled between the two primitive numbers.

~~~
johndough
Maybe the parent poster is talking about double-double arithmetic:

[https://en.wikipedia.org/wiki/Quadruple-
precision_floating-p...](https://en.wikipedia.org/wiki/Quadruple-
precision_floating-point_format#Double-double_arithmetic)

Paper:

[http://web.mit.edu/tabbott/Public/quaddouble-
debian/qd-2.3.4...](http://web.mit.edu/tabbott/Public/quaddouble-
debian/qd-2.3.4-old/docs/qd.pdf)

~~~
guyomes
Double-double and quad-double arithmetic have even been implemented for the
GPU as research prototype libraries (gpuprec [0,1] and campary [2,3] among
other).

[0] [https://github.com/lumianph/gpuprec](https://github.com/lumianph/gpuprec)
[1]
[https://event.cwi.nl/damon2010/gpuprecision.pdf](https://event.cwi.nl/damon2010/gpuprecision.pdf)
[2]
[https://homepages.laas.fr/mmjoldes/campary/](https://homepages.laas.fr/mmjoldes/campary/)
[3] [https://hal.archives-
ouvertes.fr/hal-01312858/document](https://hal.archives-
ouvertes.fr/hal-01312858/document)

------
vmchale
Time to ponder J... wonder if what could benefit from some array-focused
libraries.

------
strangecasts
Title should be "A _Massive_ Fractal in Days, Not Years".

------
akeck
"Such an algorithm is useful, because ever since "A Bug’s Life" in 1998, there
is usually at least one scene in each Pixar movie that exceeds the capacity of
even the most memory-rich node in the render farm. The scene usually appears
well after R&D has concluded, so ad hoc solutions must then be employed, e.g.,
manually trimming the scene until it barely fits in-core."

Reminds me of Hofstadter's Law.

