He was pretty open about his design process, and I think he did voice this: https://www.youtube.com/watch?v=ENa2Hmh3lGU

I can't seem to find the 2007 webpage (maybe it was one of the wiki-based ones?) but the 2008 syllabus looked very hands on: https://web.archive.org/web/20081208171743/http://stanford.e...

I never took 193p, but I always found 148 to be hands on, and I made it very hands on for the year I contributed: https://web.archive.org/web/20130522184434/https://graphics.... .

I regret that we put my subdivision assignment as the last one, and we allowed students to skip one assignment. Most students skipped it, but those that did the work thought it was super cool to have their own subdivision tool for making smooth meshes.

They linked directly to https://alexgaynor.net/2019/apr/21/modern-c++-wont-save-us/ which did exactly what I'd guessed as its example:

> The following code for example, simply returns an uninitialized value:

  #include <optional>

  int f() {
    std::optional<int> x(std::nullopt);
    return *x;
  }

Sadly I have lots of code that exclusively uses the dereference operator because there are older versions of macOS that shipped without support for .value(); the dereference operator was the only way to do it! To this day, if you target macOS 10.13, clang will error on use of .value(). Lots of this code is still out there because they either continue to support older macOS, or because the code hasn't been touched since.

Just a cursory search on Github should put this idea to rest. You can do a code search for std::optional and .value() and see that only about 20% of uses of std::optional make use of .value(). The overwhelming majority of uses off std::optional use * to access the value.

Not only is this a silly No True Scotsman argument, but it's also absolute nonsense. It's perfectly idiomatic to use `*some_optional`.

It is with a prior .has_value call. It's not correct without. It's simple, and covered by static analysis. This is not an issue in real code, it's a pathologic error that doesn't actually happen. Like most anti c++ examples.

Not at all. We've been working on this for a while, and we're now comfortable with the reliability bar we've hit to begin a gradual rollout to the public. As people said, this has been years in the making.

Make sure to do whatever "express interest" is required inside the app. We've often done a first-come, first-served approach for getting people off of waitlists, so get in now :).

Sorry about that. Please file in-app feedback (now under Help > Leave Feedback) any time you experience something like that. There's a dedicated "Car Condition" tag.

We comply with the posted speed limits. Definitely on 101 near San Francisco where there are 55 mph zones (and maybe even 50 mph?) it's pretty noticeable. But we do hug the right lanes.

That is precisely what this one was. The OP posted a follow-up comment at https://www.reddit.com/r/Terminator/comments/d65pbi/comment/...:

> I have an updated, I found out that T2 4K is an HDR movie that needs to be played with MadVR and enable HDR on the TV itself, now the colors are correct and I took a new screenshot: https://i.imgur.com/KTOn3Bw.jpg

> However when the TV is in HDR mode the 4K looks 100% correct, but when seeing the screenshot with HDR off then the screenshot looks still a bit wrong, here is a screenshot with correct colors: https://i.imgur.com/KTOn3Bw.jpg

Yes, there have been a couple re-render the whole thing. There was a good write up somewhere that I cannot find now where there was a discussion of keeping RenderMan bug compatible with the original or not. They also upped the shading rate and a few other quality knobs.

I recommend interviews with Roger Deakins, like https://m.youtube.com/watch?v=w56rFxPyZno