I recall working on a sports game where they hired a new art director who had previously worked in Hollywood on visual effects for movies. One of my coworkers had a meeting where the new art director requested that the player's uniforms have cloth simulation in the dynamic cut scenes.
It was then necessary to explain the difference between pre-rendered scenes and real-time rendering budgets.
It often isn't a question about whether or not something can be done. In pre-rendered scenes, or screenshots, the budget is very different than in game. At whatever target frame-rate you choose, there is a finite amount of visual effects you can achieve. Spending that budget requires compromise.
It's easy to live in a fantasy world where you can demand no compromise. The hard thing is doing the most you possibly can given very real budgets and doing so with the people you have available. Not every studio is Rockstar with the ability to throw unlimited devs for several years at the problem.
Even in high-end VFX (previous industry - working on pathtracing renderers), things were often over-the-top in terms of how things were modeled (polycount) or how the lookdev (shader material definitions) were done.
Some of that was due to just human time resource constraints (and assets being modeled for director validation at full screen turn-table resolution, but then just used at 1/8 size in the film), but other times it was just people losing context as to what was "needed" or would even make any difference (unfortunately, often without considering the "cost" - in terms of memory usage and CPU-time for rendering / compositing) - vs look difference.
Then there are questions from the artists like "Why's this rendering so slow, it's 'only' a load of skyscrapers in a city with the camera 0.5 km away?"
You then have a look at what's actually going on, and all the rooms in the skyscrapers have modeled (and lookdev-ed) furniture and things like lamp shades around lights. Which A: is expensive memory-wise and just silly, but also makes light-transport to sample all the lights and light the scene (even with clever NEE light-sampling techniques) stupidly expensive.
Then again, that same building, this time being rendered from about 300m away was very slow to render, and we looked at the BSDF material stack, and there was a homogeneous volumetric scattering layer on the glass windows. Like - WTF - that's insane for a uni-directional path-tracer (and physically wrong). "What's this for, this is why it's so slow.?"
"Oh, it's to represent the algae/dirt on the glass".
stillpointlab · · focus · HN ↗
It was then necessary to explain the difference between pre-rendered scenes and real-time rendering budgets.
It often isn't a question about whether or not something can be done. In pre-rendered scenes, or screenshots, the budget is very different than in game. At whatever target frame-rate you choose, there is a finite amount of visual effects you can achieve. Spending that budget requires compromise.
It's easy to live in a fantasy world where you can demand no compromise. The hard thing is doing the most you possibly can given very real budgets and doing so with the people you have available. Not every studio is Rockstar with the ability to throw unlimited devs for several years at the problem.
pixelesque · · focus · HN ↗
Some of that was due to just human time resource constraints (and assets being modeled for director validation at full screen turn-table resolution, but then just used at 1/8 size in the film), but other times it was just people losing context as to what was "needed" or would even make any difference (unfortunately, often without considering the "cost" - in terms of memory usage and CPU-time for rendering / compositing) - vs look difference.
Then there are questions from the artists like "Why's this rendering so slow, it's 'only' a load of skyscrapers in a city with the camera 0.5 km away?"
You then have a look at what's actually going on, and all the rooms in the skyscrapers have modeled (and lookdev-ed) furniture and things like lamp shades around lights. Which A: is expensive memory-wise and just silly, but also makes light-transport to sample all the lights and light the scene (even with clever NEE light-sampling techniques) stupidly expensive.
Then again, that same building, this time being rendered from about 300m away was very slow to render, and we looked at the BSDF material stack, and there was a homogeneous volumetric scattering layer on the glass windows. Like - WTF - that's insane for a uni-directional path-tracer (and physically wrong). "What's this for, this is why it's so slow.?"
"Oh, it's to represent the algae/dirt on the glass".
"I'm sorry!?"