[HN Gopher] How much boilerplate code you need to write a ray-tr...
___________________________________________________________________
How much boilerplate code you need to write a ray-tracer?
Author : ibobev
Score : 42 points
Date : 2022-02-17 21:26 UTC (1 hours ago)
(HTM) web link (sergeyreznik.github.io)
(TXT) w3m dump (sergeyreznik.github.io)
| zwieback wrote:
| Nice resource but the headline really brings up the question
| about what language we should use to "quantify" code. I'd go with
| something like C or even Fortran: expressive enough to do this
| kind of work but low-level enough that we can easily imaging the
| assembly code behind it.
| kragen wrote:
| This article is very good! It covers many beautiful techniques
| and has many beautiful images. However, I would quibble with the
| title; if you want to know how much boilerplate code you need to
| write a ray-tracer, you will not find the answer in it.
|
| I wrote the following programs in an attempt to get a better
| answer to that question.
|
| http://canonical.org/~kragen/sw/aspmisc/my-very-first-raytra...
| four pages of C
|
| http://canonical.org/~kragen/sw/dev3/raytracer1k.clj 1K of
| Clojure, condensed down from
|
| http://canonical.org/~kragen/sw/dev3/circle.clj a page of
| unfactored but not obfuscated Clojure, translated into
|
| http://canonical.org/~kragen/sw/dev3/circle.js a page of JS in
| node.js
|
| https://gitlab.com/kragen/bubbleos/blob/master/yeso/sdf.lua a
| page of Lua using signed distance function raymarching that runs
| in real time at a lousy framerate; to run it, git clone the repo,
| install the prerequisites listed in the README, and run `make` in
| the yeso directory, before running sdf.lua.
|
| But none of these can load triangle meshes, render caustics,
| render area light sources, average multiple samples, do
| bidirectional rendering, etc.
|
| Reznik says, "A lot of projects using something like PPM file
| format, which is very simple, but in the end, you need to write
| ... extra code for this simplicity (like tone mapping, converting
| from floating point values to uint8, etc.)," but the amount of
| extra code required is really _very_ minimal:
| /* PPM P6 file format; see
| <http://netpbm.sourceforge.net/doc/ppm.html> */
| static void output_header(int ww, int hh) {
| printf("P6\n%d %d\n255\n", ww, hh); } static
| unsigned char byte(double dd) { return dd > 1 ? 255 : dd
| < 0 ? 0 : dd * 255 + 0.5; } static void
| encode_color(color co) { putchar(byte(co.x));
| putchar(byte(co.y)); putchar(byte(co.z)); }
|
| But on some platforms you don't need even that much; my Clojure
| raytracer[s] just use[s] javax.imageio.ImageIO/write to encode a
| JPEG.
| meetups323 wrote:
| You may be happy to learn that in modern Node, the 3200x2400
| example which used to take 6.8 seconds now runs in 0.25
| seconds. I unfortunately don't have a clojure setupt to compare
| against.
| kragen wrote:
| That's astounding! Maybe V8 is catching up to LuaJIT's
| performance?
| dekhn wrote:
| The underlying algorithms of ray tracing, ignoring the details
| of the graphics system and IO, really are very simple (Snell's
| law). The 1K of clojure example is pretty much that.
|
| All the rest is pretty uninteresting, in my opinion- the
| various tricks to make better rendering in shorter times is
| mostly grad-level math and some computer engineering, while the
| asset loading is a long solved problem with ultra-mature
| libraries.
| kragen wrote:
| None of my examples actually implement Snell's law, just
| diffuse and sometimes specular reflection, but I agree that
| adding Snell's law (and thus refraction) does not add much
| complexity. Recently it's become fashionable to use the
| Fresnel equations and "more filmic" tone mapping to get less
| plasticky images, too.
|
| I think my interests are probably pretty different from
| yours, because I find the details of the graphics system and
| I/O pretty interesting, in particular how they can be
| improved. I also think the various tricks for better
| rendering in shorter time are super interesting, and even the
| question of how to do liability loading has some very
| interesting new answers, like FlatBuffers. Probably the
| liability-loading strategies that we came up with in the
| previous millennium for spinning rust that transferred 40
| megabytes per second after an 8 000 000 nanosecond seek time
| are not optimal for SSDs that transfer 4000 megabytes per
| second with a 1000 nanosecond "seek time".
|
| Another thing worth mentioning is the question of how you
| model the 3-D shapes you want to render in the first place,
| which includes considerations of HCI, sometimes physics
| simulation, and so on. One of the most interesting things
| about SDFs is the tempting possibility of an efficiently
| renderable representation that naturally supports operations
| like CSG and filleting (though not usually both at once!)
|
| That is to say, I think the stuff these minimal raytracers
| leave out is actually very interesting indeed. But I also
| think it's very interesting to see what's left over when you
| do leave it out: a relatively small amount of math and code
| that can still produce visually arresting images.
| foxfluff wrote:
| 7 lines of K: http://www.nsl.com/k/ray/raya.k
| kragen wrote:
| Nice! APL-family languages are really great at this kind of
| thing; I should see how small I can squinch a raytracer with
| just NumPy. Stevan Apter's programs like that one constantly
| make me wish I knew K: even if I don't want my code to _look_
| like that, it seems like it would be great to be able to
| _type it in_ that way.
|
| That also leads to a one-page OCaml version and a two-page
| C++ version by Jon D. Harrop (the Flying Frog guy), both also
| using PPM output and rendering only spheres, much like most
| of my examples: https://web.archive.org/web/20070605173709/ht
| tp://www.ffcons...
|
| He also wrote an SML version https://web.archive.org/web/2007
| 0522030632/http://www.ffcons... and a Java version, and
| others ported it to Scheme and Common Lisp https://web.archiv
| e.org/web/20070515185350/http://www.ffcons..., those these
| seem to be lost now.
|
| Still others ported it to Io http://mike-austin.com/io/ray.io
| and Factor https://github.com/factor/factor/blob/master/extra
| /benchmark... (3 pages).
| mzeeshan7929 wrote:
___________________________________________________________________
(page generated 2022-02-17 23:00 UTC)