Max Payne – two decades later – Graphics Critique (2021)
darkcephas.blogspot.com
darkcephas.blogspot.com
While Max Payne was cutting-edge, a lot of what made the visuals appear impressive was due to hand-tweaking by a team of highly skilled artists and designers, who were probably using ridiculously primitive tooling. Pretty much every realistic 3D game of this era had to make do with low-res diffuse textures, prebaked lighting, mostly fixed-function rendering, pre-scripted interactions, and particle dynamics that were basically just a few lines of C++. Other early-2000's games like Serious Sam, Halo, and Metroid Prime also managed to create immersive visuals with very limited tech, using the same techniques as Max Payne.
And let's not forget what while the game was released in summer of 2001 - it was in a development for the almost five years, with the first demos at '98 E3. There is a lot of things what were not even available in 1997 (Voodoo just released) and in 2001 there was already GeForce 3.
I remember being at a friends house while working on my masters thesis and him telling me to take a break and try out Halo. I had not had a console since the Nintendo 64 came out. I booted Halo and was literally mesmerized when I came out of a tunnel onto the Halo and saw the sky and the landmass. I can still remember that afternoon 20+ years later. Bought an Xbox the next morning.
Current game devs, especially in the AAA space, spend a lot of time and effort looking for hyper realism and embracing new tech to achieve accurate PBR. I wonder whether the limitations of the older hardware force a more artistic stance on everyone, even down to technical artists, to embrace an art style and art direction and work to achieve attractiveness vs realism. Or I could just be seeing my early 20’s through rose-tinted glasses.
I'd argue that during Max Paynes time (early to mid 00s) gaming was far more graphics tech driven than these days, especially on PC. It is far more common to see heavily stylized or non-photorealistic games these days than back then imho. When I think early 00's PC games, lot of it is shooter games pushing the tech envelope very heavily, stuff like HL2, Far Cry, Doom 3 etc, and I don't think we really see that sort of games often these days anymore.
For comparison, it was like stepping from a bit upgraded XBOX graphics to the ones from an XBOX 360 in two or three years.
For GenZ-ers: kinda like gap from the PS3/ (and high end PSP games even) to the first games for the PS5 in two years. Insane.
Take Minecraft, for example. The most successful game of all time along many axies, and it looks .. a certain way. It's definitely not realistic. It's not even pretty in a lot of cases. But it's consistent, and people have pushed it to the limit and created some truly beautiful artwork.
I guess what I'm trying to say is that I think visual fidelity can be a selling feature, but art-style and consistency is much more important.
I had the same feeling when I exited starship in Unreal. Right now it is nothing, but then it was oh my god, this is beautiful. The bird in sky, the colors, the palm…
That hapenned for PC users in 1998, literally the same you described, but with Unreal. You got out from a techy base, and then open nature in front of your eyes, "open" compared OFC to the limited outdoors environment from every FPS since Doom. With the exception of RPG's of course, but:
- RPG's reussed assets like crazy. Cities were almost a copy of each other.
- Because of that, the details weren't as high as an FPS. Landscapes felt a bit empty because of that.
- "Open world" RPG's where a thing... in 2D/2.5D days because it was cheap. No first view beside of a fake 3D dungeon. Then 3D environments happened with Might and Magic and the like, but the worlds paled against the details from an FPS.
Unreal changed that a little, and the first Deus Ex (same engine) it's almost an open world game with slight gaps. Even more with GMDX, where they might be new doors between areas. Is not a secret that in DX you could jump between further sections from the game by exploring around, and even bypass complete sections (and the game predicted that too).
I'm not so sure. I grew up playing with offline 3d rendering rather than real-time game stuff - and game dev was merely reusing the same smoke and mirrors that people used to keep rendering time under a week a decade earlier. People always knew the "correct" way to do things but it was just out of reach given the hardware constraints. GI, radiosity, path-tracing etc already existed well before this - but nobody could do it on consumer hardware
Without that level Max Payne wouldn't have been anywhere near as memorable for me.
Depends I would say, not the word I would use in the context of dead babies, but they were definitely great, intense games.
Additionally, I believe Rockstar gave the go-ahead for work on a remake for 1 & 2. Hopefully they have James Perry McCaffrey's voice work in good enough quality. RIP.
Also interesting how his life changed after the game, he went a totally different route and left programming for good.
Tech is an exhausting treadmill for me at this point. Hard to find somewhere I can work where my high empathy is a positive power and not a stressor.
He had a burn out. He mentioned to me in the mid 2000s after Max Payne 2 that he could not touch or see a keyboard anymore.
I just saw him last year, he is in good spirits, programming a bit again iirc but we did not talk that much about it. Still one of the smartest people I ever met.
I came out of the demo scene into pro game dev, and there was a lot of useful overlap, especially at the time (mid 90s) when you were really trying to get anything 3D on the screen.
P.S. I still see polygonal instead of truly round barrels in modern games, when will we finally have quadratic surfaces or some other solution for that?
IIRC Quake 3 levels had true curved surfaces, though presumably they were polygonised at some point in the rendering pipeline.
Truly quadratic? Not with any technology resembling current GPUs which are all about computing strictly linear (/affine) functions as fast as possible. Plausible approximate dynamic level-of-detail approach? That was first used by Quake III Arena in 1999, widely advertised as being able to render truly curved surfaces (which was of course not the case, it just tessellated Bezier patches/splines in real time).
We've had tessellation shaders for a long time now, able to dynamically subdivide surfaces to approximate round shapes on the fly on the GPU. The fact that there are still polygonal barrels is likely mostly about what things to prioritize.
The Holy Grail of real-time rendering is probably micropolygons – the ability to render the whole scene using polygons a fraction of the size of a single output pixel, something that off-line renderers like Pixar's RenderMan have done since the early 90s. There are reasons why GPUs are not very good at rendering a lot of extremely small polygons, leading to approaches such as Epic's Nanite virtualized geometry in Unreal Engine 5 which basically implements a software renderer running on GPU compute shaders.
A remake/remaster of Max Payne 1&2 is in the works by the original developer (Remedy). Stated to be financed by Rockstar (who own the IP) to normal Rockstar AAA levels.
The real story to tell would be what tooling was used to pre-bake the lighing in the textures, e.g. if they used a seperate rendering package or mostly painted by hand, or in what mix.
Also what guidelines they used to make sure the baked-in reflections would match the use and environmental lighing of objects in the scene, e.g. just general constraints or how much customization there was for important unique arrangements. Is it done by the same person in a tight loop or did it involve hand-ofs, etc.
The excellence of the result is down to a lot of tasteful choices in how to blend these techniques, achieved either from experience or iteration.
As programmers we tend to focus a lot on the raw rendering techniques, but there's a whole systematic practice around art direction and how to achieve and maintain quality in it that feels I guess softer and less deterministic but is still worth talking at length about.
This especially struck me when the reviewer here recommended using multiple stacked texture planes and parallax mapping to improve things. I know a handful of games that have done this, and unless used exceedingly sparingly (e.g. mesh fence over pipes or something, where the foreground isn't expected to have a lot of depth) in my experience it very quickly gives away the illusion and looks very hokey. Humans are good at telling it's planes sliding over each other and doesn't correspond to their experience with depth perception. It also makes a scene a lot busier as the camera is moved, firing "something is changing here!" perceptual sinals all over the screen (note how all the lavish particle effects are about feedback instead), and is not the atmosphere Max Payne was trying to achieve.
In other words, sometimes it's about knowing what possible thing not to do, too. And a lot of magic happens when disciplines meet.
IIRC Max Payne was one of the earlier games to rely heavily on photo-reference textures (instead of hand drawing or computer generating them). Keep in mind that in 2001 digital cameras were rare, expensive, and low-res, so people often just used film cameras and scanned in the physical photo with a flatbed scanner. Max Payne was far from the first, though; even 1998's Half-Life used some photo-ref textures.
The lighting in Max Payne's textures was probably mostly just the lighting from the original photo. Every texture had to be hand-manipulated to make it usable on 3D models, so changing the lighting would have added even more work and would have looked less realistic.
There _is_ deep and rich academic framework around the subject, but I think to understand "why this" you need to program to understand the problem space since it's not really anything you could derive from first principles. I mean you get the rendering equation and so on, but the graphics knowledge portrayed in the article comes from understanding the three pillars of real time rendering.
It's about delicate interaction between human visual system (how to fool it), algorithms, and the hardware capabilities.
In general you need to program graphics, not read it. I mean I'm in the "reading" category myself and the people who've focused on programming are much better than myself.
Real time rendering by Akenine-Möller, Haines et all is the standard entry reference. Now in it's fourth edition. It's really good and dense.
If someone wants a simple recipe how to learn real time graphics alone in their cellar, nowadays I would recommend getting Real Time Rendering and going through https://learnopengl.com/.
After that you just continue... continue ... continue.
There are some people who understand everything about the topic instantly intuitively apparently but that's very, very unique. For the rest of us it's a life long adventure facing our own limitations and trying to get better, one program after another.
Speaking as graphics/geometry dev for 20 years now.
But the developments in the field have mostly been motivated by "I think this looks better than that" followed by a formal mathematical model. The aesthetic aspect has been far more impactful in driving development than drive for technical precision as such.
"Does it look good" is far more important metric than displaying graphs with error bars.
This is not to say the field _isn't_ extremely technical. It is! But the main motivation for all developments has been aesthetic - hence it's IMHO almost as hard to learn computer graphics by just reading about it as it would be to learn something like academic oil painting just reading about it.
A seminal example of aesthetics based development to me is the Mitchell-Netravali filter kernel: https://www.cs.utexas.edu/~fussell/courses/cs384g-fall2013/l...
"In the center of the display, images reconstructed from filters with random values of (B, C) were displayed ... Nine expert observers took part and over 500 samples were taken...It would not be credible to suggest that a single ideal parameter pair can be deduced from subjective testing"
So they basically did kernel fitting based on what looks good - while the theory of the kernel function itself was more technically motivated.