4 ms·
Hi! So, it's been a while, but I'll try to add clarification from the best of my memory. So, in this sequence, I think it is the case that K2-SO was only rend
by Arelius 4y ago
Hi!
So, it's been a while, but I'll try to add clarification from the best of my memory.
So, in this sequence, I think it is the case that K2-SO was only rendered from behind.
IIRC, the reasons for not using it on more shots, and specifically the front shots in the sequence were two-fold, Primarily, we only had one TD/Lighting Artist trained in our pipeline using Unreal, which was still a little clunky to fit into our pipeline, so we were time limited. Now, K2-SO was not rendered from the front in a close-up due to problems with complexities with his eyes. (Some details from Naty later in the talk) Specifically, K2's eyes require fully lit transparencies with the full lighting model, at-least at the time Unreal only supports their full lighting feature set in their deferred renderer, and their forward renderer, used for transparencies was a vastly simplified lighting model which isn't able to fully capture the effect of K2's eyes. We were building a capable Forward renderer inside of Unreal internally, but this was not finished in time for Rogue One.
As an aside, we had a parallel internal renderer we were building for use on Rogue One, that even at the time had advantages, but Unreal was chosen for what I saw as political reasons.
I do not know of more recent examples, but I'm not involved in this project anymore, I know they used Unreal for Season 1 of the Mandalorian, but moved to their internal real-time renderer for Season 2. The internal renderer has a few advantages, not having to deal with the complexity of merging significant changes with Epic's engine for example with the forward renderer was one major advantage, but my understanding is that the major win, is just being able to build a renderer that integrates much better in their existing pipeline. Unreal's renderer is pretty strongly integrated into the rest of their engine, and the engine itself is very opinionated regarding how content is managed. And as you can imagine, ILM has their own opinions going back to about 30+ years of history.
I agree with your dispute of the broad characterization, but thought the counter-example would be illustrative.
BTW, I'm starting a new project investigating real-time rendering for film, and always interested to new perspectives, hit me up if you want to chat real-time rendering sometime.
- dahart 4y agoYes, the example is very illustrative, thanks again for posting it, and thanks for the context here! This history is fun to read. I was partly curious if texture sampling is still one of the reasons for avoiding real-time tech. Back when I was in film production at PDI two decades ago, texture sampling was near the top of the list. It seems true still today that games tolerate (suffer from) texture aliasing and sizzling routinely, while film sups will not tolerate it at all, ever. High quality texture sampling was, at the time, one of the main reasons offline renders took a long time. I remember being blown away how sensitive the lighting sup was to the differences between texture filters, lanczos, sinc, Blackman, Guass, etc., and how quickly he could see it. Today maybe it’s more often about how many samples are used for path tracing.