Real-Time Rendering

The REYES algorithm isn't really the problem, you can just generate an acceleration structure and shade each shading point using ray tracing [1]. The REYES algorithm is just an algorithm that generates shading points and determines in which pixels those points are visible, it puts no restrictions on how you shade those points. The downside to mixing REYES and ray tracing is that you have to keep two representations of the geometry in memory, but that doesn't mean you can't combine the two.

The main problem with RenderMan before version 19 was that it didn't have a good acceleration structure and that you basically had to implement a path tracer in RSL on your own. Pixar wrote a path tracer in RSL for Monster's University, so Disney could have just used that. I doubt that they would write their own renderer if they could have just asked Pixar to implement a better acceleration structure in PRMan, so there were obviously different reasons too.

I think Ptex was an important reason for them to write their own renderer, as they seem to put a lot of focus on textures in their paper on the architecture of Hyperion [2]. Hyperion's architecture also allows them to use packet tracing and to load and subdivide geometry on demand, which is also really great.

[1] http://www.realtimerendering.com/resources/RTNews/html/rtnv11n1.html#art6

[2] https://disney-animation.s3.amazonaws.com/uploads/production/publication_asset/70/asset/Sorted_Deferred_Shading_For_Production_Path_Tracing.pdf

Still worthwhile in my opinion! But full disclosure, I happen to be working on ray tracing problems.

Writing them is still really fun, it’s no less useful today for learning things than it was 20 years ago. You can get amazing pictures with not very much code, and the algorithms are really satisfying to understand & implement.

There are also still tons of low hanging fruit. You’d think the easy problems would be mined out by now, but they’re not. New developments are actively happening with intersection primitives, color handling, sampling, direct lighting, shadowing, the list goes on. If you want to do research, you don’t have to dive that deep to find something unsolved that is solveable.

For an oblique cone intersection, I don’t know the right answer, but the oblique cone is a skew transform of a regular cone, right? You might be able to use a regular cone intersector, but pre-transform the ray by the inverse skew transform?

This resource is fantastic for finding intersection building blocks and code examples: http://www.realtimerendering.com/intersections.html

Much of that is mostly of historical interest.
Today, either you're using the scene graph of some game engine, or you're
down at the Vulkan and shader level, working on the engine and programming the GPU. A theoretical understanding of the whole pipeline is helpful for both, but how much of the old mechanics should be taught is a question.

WebGL is easy for students to start with, since all you need is a browser. It's not really used much on the Web; most of the good demos are over 5 years old. Despite that, it's probably worth teaching WebGL simply because students can use it to get something they can show to others.

Here's the Utah teapot in WebGL: [1] Udacity uses that example. Once students understand how that works, they probably know enough unless they intend to do game engine development.

[1] http://www.realtimerendering.com/teapot/

This is a great resource. Some others along the same lines:

TinyRenderer: https://haqr.eu/tinyrenderer/

ScratchAPixel: https://www.scratchapixel.com/index.html

3D Computer Graphics Programming by Pikuma (paid): https://pikuma.com/courses/learn-3d-computer-graphics-programming

Ray-tracing:

Ray Tracing in One Weekend: https://raytracing.github.io/

Ray Tracing Gems: https://www.realtimerendering.com/raytracinggems/

Physically Based Rendering, 4th Edition: https://pbr-book.org/

I'll also link a comment[1] I made a while back about learning 3D graphics. There's no better teacher than manually implementing the rasterisation and ray-tracing pipelines.

[1]: https://news.ycombinator.com/item?id=46410210#46416135

You're welcome!

Scratchapixel was new to me, so thanks for that link. PBRT (which you already have) is definitely a favorite. You also cited Graphics Gems IV but I enjoy dipping into all of them. Other suggestions:

* http://tog.acm.org/resources/RTNews/html/ (Somewhat dead, but the archives are great)

* http://ompf2.com/ (Active, lots of ray tracing specific discussion)

* http://www.realtimerendering.com/ (I'm fond of the book as well)

* http://kesen.realtimerendering.com/ (Especially the sections for "Symposium on Interactive Ray Tracing" and it's successor, "High Performance Graphics")

If I had to pick one, though, it'd be PBRT since it's a unified work that starts from the ground up.

I sort of know this area.... There two separate paths -- realtime or non-real-time.

For non-real-time there is: http://www.pbrt.org/

For real-time there is this: http://www.realtimerendering.com/

Neither book gets into the details of the specific API, they are theoretical.

Real-time techniques change nearly complete about every 10 years because GPUs get faster and render more techniques possible and obsolete the older less good looking techniques.