11–20 of 128 posts
Can we say that modern AAA graphics is way more complex than a single human can handle unless perhaps he started graphics programming many years ago?
Can we say that modern AAA graphics is way more complex than a single human can handle unless perhaps he started graphics programming many years ago?
Indeed the author has caught on that graphics is now much wider. Yet his post still focuses on the APIs. A bias he admits to. APIs are the easy part of graphics programming. Now perhaps I say that out of bias, as I focus on shaders and artist work pipelines. The author focuses on APIs and thus reached for a simpler API as a teaching on ramp, while I would new learners run the other way and learn the basics of blender…
And then once you know how to draw things you start looking at how to import models to draw, instead of starting with a big complex object you learn exactly what each instruction does to the pixels. Then you use what you learned to make what the large structure you imported look like it did in blender, rather than follow a tutorial how to make it look the same you use the skills you learned when you learned the basics before. That way you learn how to create small samples to debug etc, because you did the small samples in code before you did the blender import.
Say we have a scene to render and a frame can be rendered in 10ms given the chosen game engine or graphics API or whatnot. There is a hypothetical optimum code for rendering that scene that can do it in less time. And the delta between those times is the price you pay for API abstractions, human abstractions (eg. maintainable code vs clever code), and other things.
Is this a concept with known terminology?
I was thinking tonight, “my hardware is running this game at 45FPS and I know that it could hypothetically be WAY faster if we put a ton of money and brilliant engineering behind it.”
And that got me thinking about how you would go about measuring efficiency loss or waste. We’ve all experienced it: two comparable games running at vastly different performances given the difference various technical and business choices made.
Furthermore, I’ve been very curious about why there isn’t a tool that can provide a concrete answer to, “what part of my PC is bottlenecking performance?” I’ve been playing a game that’s running slow and noticed GPU is never above 80% and CPU is pegged at 100% so I shuffled my computer hardware to essentially upgrade my CPU by a lot. Didn’t have any effect.
There’s a lot of focus on API driven learning. Vulkan, D3D12, 11, etc.
Wrong approach.
Learn fundamentals of what the hardware is capable of. For each feature, write down a few ideas of how you could use it by itself. Write down a few ideas of how you could combine it with other features. Think of “I want to do X. What features can allow me to do that?” The APIs, although they are not easily interchangeable, use the same hardware and can often do the same things with a bit of effort.
Graphics Programming needs to be restructured. There’s a lot of focus on API driven learning. Vulkan, D3D12, 11, etc. Wrong approach. Learn fundamentals of what the hardware is capable of. For each feature, write down a few ideas of how you could use it by itself. Write down a few ideas of how you could combine it with other features. Think of “I want to do X. What features can allow me to do that?” The APIs, althoug…
Can we say that modern AAA graphics is way more complex than a single human can handle unless perhaps he started graphics programming many years ago?
It's getting much more complicated. Here's an hour long talk on how Unreal Engine 5's Nanite works.[1] This is a huge breakthrough in level of detail theory. Things that used to be O(N) are now O(1). With enough pre-computation, rendering cost does not go up with scene size. See this demo.[2] You can download the demo for Xbox X/S and PlayStation 5, and soon, in source form for PCs. Explore 16 square kilometers of photorealistic city in which you can see a close-up view of anything.
The format of assets in memory for Nanite becomes far more complicated. GPUs need a redesign again; UE5 has to do more of the rendering on the CPUs than they'd like. What they need to do is simple but not well suited to current GPU designs. It's such a huge win this approach will take over, despite that.
New game engines will need to have something comparable. Maybe using the same format. Epic doesn't seem to be making patent claims, and the code for all this is in the Unreal Engine 5 download.
(Basic concept of how this works: A mesh becomes a hierarchy of meshes, allowing zoom in and out of on level of detail. The approach to subdivision is seamless. You divide the mesh into cells of about 20 triangles. Then, each cell is cut by one or two new long edges across the cell. These become the boundaries of a simpler cell with about half as many triangles, but no new vertices. The lower-resolution cell has no more edges than the higher-resolution cell. There's a neat graph theory result on where to cut to make this work. This process can be repeated recursively. So, one big mesh can be rendered at different levels of resolution depending on how close the camera is to each part. The end result is that the number of rendered triangles is determined by the number of pixels on the screen, not the complexity of the model. Hence, O(1)).
Then, all that needs to stream in from the network. That's probably Unreal Engine 6. In UE5, the whole model has be downloaded to local SSD first. Doing it dynamically is going to require precise download scheduling, and edge servers doing partial mesh reduction. Fun problems.
Then the metaverse starts to look like Ready Player One.
Kind of a weird New Years fever dream tangent. Bear with me: Say we have a scene to render and a frame can be rendered in 10ms given the chosen game engine or graphics API or whatnot. There is a hypothetical optimum code for rendering that scene that can do it in less time. And the delta between those times is the price you pay for API abstractions, human abstractions (eg. maintainable code vs clever code), and other…
Kind of a weird New Years fever dream tangent. Bear with me: Say we have a scene to render and a frame can be rendered in 10ms given the chosen game engine or graphics API or whatnot. There is a hypothetical optimum code for rendering that scene that can do it in less time. And the delta between those times is the price you pay for API abstractions, human abstractions (eg. maintainable code vs clever code), and other…
It's hard or impossible to know that delta. The amount of complexity that goes into rendering a modern scene is beyond what could be formally specified without putting nation-state level resources and decades of time into it. Even then, you'd have to go through a massive amount of analysis and development to find the most optimal implementation for a particular problem, and it would only be a local optimum, not guara…
It’s funny how it might be impossible to quantify but it’s often trivial to qualitatively know, “this ought to be way faster…” (but also the biases that make us think that given we don’t appreciate what some games have to do to render that state…)
Indeed the author has caught on that graphics is now much wider. Yet his post still focuses on the APIs. A bias he admits to. APIs are the easy part of graphics programming. Now perhaps I say that out of bias, as I focus on shaders and artist work pipelines. The author focuses on APIs and thus reached for a simpler API as a teaching on ramp, while I would new learners run the other way and learn the basics of blender…
I learned unity about 5 years ago and got burnt out on it after a few personal projects and a few freelance side gigs I took that used it. But I was not a decent programmer then and I have earned a CS degree in the time since. I actually used 3DS Max and Blender more than Unity but have since been distracted with web development and once I’m settled in my new job I am planning to write a raytracer. Any other recommen…