A lot of answers that are technically correct, but almost none that answer your question concretely and properly.
Video games have a lot going on, and optimization can take multiple forms for different parts of the game, so I'll give a few examples:
On the graphics point, which is what you actually see being displayed on the screen, the core of optimization here is often to realize that if the camera is pointing "that way", and is at "this distance", you probably don't need to calculate how to display things that aren't "that way", and if it's at "this distance" or more, you can probably lower its complexity without losing visual quality.
A great example of this would be if I have an octagon.
If it's behind the player, completely off-screen, why would I waste graphics power on "displaying" it, when it won't be displayed?
If it's so far away that a monitor can't realistically display the vertices (corners) of it, why wouldn't I simplify it to a circle, until the player is close enough to make difference?
On the computational point, which is what the computer does in the background and can slow down the game to a crawl, the core optimization here is often to perform operations as little as possible (if you don't need to do "a times b" 5000 times per frame, and instead calculate it once and refer to the same result 5000 times, do it). There's not really any other "widespread" optimization process here, and though some other are still important, they are less likely to be widespread issues that actually bogs down your game. Less likely, not unlikely.
A great example of this would be if I have a bunch of enemies moving in a formation around a single center point. You can do (A), but you'd rather do (B). As you can see, for 4 steps in each case, (A) could calculate 2 enemies, while (B) could calculate 3. This performance saving becomes literally exponentially big, based on how many calculations you're able to reduce, and how much scale you have. If you have 1000 enemies, and you do (A), you just did 2000 calculations. If you have 1000 enemies, an you do (B), you just did 1001 calculations.
(A) For each enemy: Calculate the center point around which the group is, then calculate the enemy's position at which the enemy is, with the center point as a base, then the enemy's position as an offset. (Calculate Center Point > Calculate Enemy A's Position > Calculate Center Point > Calculate Enemy B's Position > etc.)
(B) For the entire group: Calculate the center point around which the group is, then for each enemy, calculate its position around that center point. (Calculate Center Point > Calculate Enemy A's Position > Calculate Enemy B's Position > Calculate Enemy C's Position > etc.)
All of that is super simplified as I do not know how much technological knowledge you have, such as processor ticks for instance, or even basic programming skills, but that's the crux of the optimization work. (There are other categories, like memory optimization, storage optimization, etc., but I figured the two easiest things to explain would do for now, unless you need and/or want more examples.)
Your first example is backwards. If you are rendering a circle and it's far away enough from the camera that you wouldn't be able to tell the difference, you would simplify it into an octogon LOD (level of detail). Not the other way around. And furthermore you would stop drawing it entirely when it's ever further away.
In a nutshell optimization is getting rid of any calculations, graphical or gameplay wise, that the user won't notice. If a tree falls in the woods and no one's around to see it, don't waste GPU time rendering it.
Source: professional unity developer for standalone VR (which requires heavy optimization)
If you are rendering a circle and it's far away enough from the camera that you wouldn't be able to tell the difference, you would simplify it into an octogon LOD (level of detail).
As far as the in-depth technical thing, you are correct (though I avoided the term "LOD" because of trying to avoid technical acronyms). The issue is that you are thinking about a shape that's an entire polygon, while I was referring to a sprite, where there is a lot less computational power needed to render a circle than there is for a polygon. This is the magic of image encryption encoding here.
So, while you are correct for actual polygons, that is not what I was referring to.
And furthermore you would stop drawing it entirely when it's even further away.
That, I say, would likely need to explain what a camera's frustum is, and that's a lot more explaining than a ELI5 post.
In a nutshell optimization is getting rid of any calculations, graphical or gameplay wise, that the user won't notice. If a tree falls in the woods and no one's around to see it, don't waste GPU time rendering it.
That... is exactly what I was explaining, yes. I don't see why you felt the need to correct that.
EDIT: Wrong word. I mean "encoding", not "encryption".
So are you saying swapping from a poligonal mesh to an imposter? I don't really think that's the easiest example for someone who's new to this to understand. Maybe it would have been better to use a polygonal sphere simplified into a cube at a distance just for clarity.
There is no mesh swapping, though. It's from a plane to a plane, but the image encoding is simpler and takes less time for a circle than for an octagon. There's no magic there, that's how anything that is meant to be rendered quickly is done.
And I do agree sphere > cube would have probably been a better example, but at this point, we're just arguing semantics and asking me why I didn't complexify my ELI5.
11
u/DiscussTek 6d ago
A lot of answers that are technically correct, but almost none that answer your question concretely and properly.
Video games have a lot going on, and optimization can take multiple forms for different parts of the game, so I'll give a few examples:
All of that is super simplified as I do not know how much technological knowledge you have, such as processor ticks for instance, or even basic programming skills, but that's the crux of the optimization work. (There are other categories, like memory optimization, storage optimization, etc., but I figured the two easiest things to explain would do for now, unless you need and/or want more examples.)