Funny story! I'm an undergrad Computer Science student who received this postcard raytracer from my Pixar recruiter back in November when they visited my school (CMU). To try and woo my recruiter, I changed the "PIXAR" text to say "HIRE ME" and sent it back to them. I also called fork() twice before the render loop to use 4 cores (plus a spooky mmap call to share the memory).
I didn't end up moving forward with my offer at Pixar, but I had a ton of fun with this! Super awesome idea, Pixar sure knows how to get computer graphics programmers thinking.
If anyone is interested in diving deeper into distance field ray marching and using it in a production game engine, check out my article on the topic here:
http://flafla2.github.io/2016/10/01/raymarching.html
The words are defined using Signed Distance Field functions -- a function that determines the distance to object's surface. It is quite simple to write down an SDF for primitive objects like cube and sphere, cylinder, torus, then using negation and min/max you can create unions, intersections and differences of shapes defined by SDFs.
Incidentally, he also works at Pixar --- and I'm not sure if he was the one who popularised using SDFs there, because I don't remember seeing this stuff before he first put up those webpages explaining SDFs.
Inigo Quilez works at Facebook (after Oculus story studio was shut down) and is the creator/primary developer of the VR art tool Quill (https://quill.fb.com). He quit Pixar in 2014.
There are no vertices in the code. Everything is done with CSG functions. If you are unfamiliar with them, let's just say that they are functions describing if a coordinate is inside or outside an object.
I believe this technique was first popularised in the demoscene, because it makes for some extremely concise procedural descriptions of 3D scenes:
For anyone else who read the article and is itching for more, the International Obfuscated C Code Contest[0] (IOCCC) is the place for this kind of compact, obfuscated trick code. Stuff like [1] reminds me how far I still have to go with programming.
There’s a bug in the deobfuscated version — sizeof(letters) should be 60 or sizeof(letters)-1 (that version reads past the end of the buffer otherwise).
It's hardware accelerated support for tracing rays efficiently. That can be used to implement a variety of rendering approaches that make use of tracing rays, including traditional Whitted ray tracing, path tracing and all sorts of hybrid approaches.
To be more precise: RTX (like OptiX before it) makes no particular assumptions about the applications. It concerns itself mostly with fast ray/scene intersections while user code in the form of very specialized shaders form the actual rendering algorithms around that core. That makes sense because constructing acceleration structures and the intersection tests themselves tend to dominate the runtime for these algorithms unless some particularly fancy shading is applied to the surfaces.
It’s easy to swap out the limited use of printed in this program, which just prints strings and integers, with a short loop and a syscall. Like I said, nobody needs libc; it’s just convenient to use.
Even the AMD64 instruction names alone for fabsf, sqrtf, powf, fmodf, will add up to more than a dozen characters. That's before you implement rand and printf. I'm skeptical.
Here's the gist of my modified code (clang-formatted with comments): https://gist.github.com/Flafla2/d2f44c9e5e5a0ff13e6071fb782d...
And here's what it renders: https://i.imgur.com/Yhqt0Le.png
I didn't end up moving forward with my offer at Pixar, but I had a ton of fun with this! Super awesome idea, Pixar sure knows how to get computer graphics programmers thinking.
If anyone is interested in diving deeper into distance field ray marching and using it in a production game engine, check out my article on the topic here: http://flafla2.github.io/2016/10/01/raymarching.html