Edit: googling "ray tracer on a business card" gave me this link which is what I had read before.
But actually reading (and not skimming) the submitted link, gave me this paragraph:
> Sometime around September 2009, I posted a version of my program to the now-defunct ompf.org (whose demise is lamented here among other places), a web forum dedicated to the real-time raytracing community.
So that's why it sounded so familiar. Oh and the "spher-y" text was just the first image, which is also cited in the other post from 2013 that google found.
It was based off the excellent introduction Ray Tracing in One Weekend (http://in1weekend.blogspot.com/2016/01/ray-tracing-in-one-we...).
and the "Build a renderer in a weekend"
I've recently been making a Julia version from the C++ source code
The PBRT ray tracer is also a production quality ray tracer and uses many advanced techniques you won't find hobby ray tracers, such as differential geometry, which naturally increases it's size.
 Some utility classes are left out.
REDACTED as per author's request
I'm the author of the book.
Could you please not post links to pirated versions of it on HN?
When the search on the common academic piracy pages showed this book, I assumed that I was only harming the parasitic journal companies. Evidently, I wasnt :/ For that, I apologise.
The publishing industry has gotten worse in a lot of ways in the ~10 years since we did the first edition. The whole for-profit academic journals thing makes me sad in general, etc.
However, it's also impressive how much work how many people put in to publish a book (illustrators, proof-readers, copy editors, professional layout, etc., etc.). For a specialist book like PBR that sells ~1500 copies a year, no one involved is making a ton of money from the process including, as far as I can figure, the publisher.
Even though the most important reason I've done my part of that work is to try to spread knowledge as widely as possible, that all does make me want to do my small part to discourage piracy. :-)
If you are an ACM member, it is also available to you as eBook: http://learning.acm.org/books/book_detail.cfm?id=1854996&typ...
It's feasible today, it just depends on what quality level, scene complexity, and frame rate you're looking for. I can trace a the standard bunny model with 2 light sources in a 640x480 window at >10 FPS on my dual core AMD64 from 2005. The problem is that we want better surface models, global illumination, and higher resolution. OTOH, we can get 8 core 3GHz+ processors today so that make simple renderings go pretty well. You should be able to render very complex geometry at HD resolution without any lighting effects at very interactive rates, but if that's all you want, just throw triangles at OpenGL.
That's correct - you CAN get more realistic images. I guess what I was trying to say is that the better (photo realistic) rendering quality is not real-time yet on high resolution displays, but simple rendering using ray tracing techniques can be near real time. But if all you want is simple rendering with phong shading you're probably not going to bother with ray tracing.
With basic (i.e. Whitted) ray tracing, you get shadows, reflection, and refraction. You can do that in OpenGL too, but it's more work and you have to do go through some unnatural contortions and/or use approximations that might look convincing but aren't physically accurate.
Soft shadows, focal blur, and motion blur can be supported by tracing more rays per pixel.
The big leap in realism (the kind where you would say ray tracing is definitely better than what you would see in a modern game) comes when you add global illumination, which is computationally a lot harder than basic ray tracing because it requires a large number of rays per pixel. It works by random sampling, so you can generate a blurry, grainy image fairly quickly, but noise-free images take a lot longer.
Also, plain raytracing can look kind of bland. Most global illumination algorithms are based on ray tracing, but require tracing a very large number of rays. So, really the question is more whether we can get to real-time path tracing, which is a harder problem.
Another problem is tooling. Game developers know how to get good performance on GPUs, but ray-tracers have completely different performance characteristics. Re-building a bounding volume hierarchy is, in general, O(NlogN), so you have to be careful about partitioning your scene into things that move/deform and things that don't and only rebuild the parts of the BVH that need updating.
For open-source, I know that Blender uses Cycles, which fires ray-tracing renderings in the normal views on each change, and this so is for quite a while already.
Great for a quick preview though, especially while setting up lighting. And if you've been good with naming your objects you can always select things out of the document tree.
(Yes I know the subtleties that distinguish ray[tracing|marching|casting].)
Even worse than not knowing them, you think you do and have no idea.
But please correct me if I'm wrong.
then it becomes very difficult to stop ;)
GitHub Pages uses their profile name as the github.io sub-domain.
>> Once I made a robot to play video games for me.
Also, a path tracer in 100 lines of C++: http://www.kevinbeason.com/smallpt/
Is this not correct?
As for open source path tracing renderers, some well known ones are:
- LuxRender: http://www.luxrender.net/
- Mitsuba: https://www.mitsuba-renderer.org/
- Tungsten: https://github.com/tunabrain/tungsten (uses Embree)
This is when I came across my second lesson, mentioned in this article, it doesn't render fast. In my case even though all the assets are downloaded, it's still too heavy.
Either way, when you get time to work on this type of stuff it can be pretty fun.
We have hard drives with terabytes of storage, and making descriptive variable names do not increase the file size of the binary by the way.
So if your program is 1kB because you shaved the white space and made it illegible, don't boast. Instead, shame on you.
It is still an impressive piece by the way, and i would have been fine with it if it was a few tens of kilobytes.