@sgredsch

2 months ago

Former Mod developer here, working with source engine as 2d/3d artist. id like to share some basic views onto game optimizations. Petersen did a great job explaining deeper driver/engine Level optimizations, but this is only one part of it. Its not just the engine or driver, its also the assets, and this is also where some studios just drop the ball. you want to load a gpu evenly, but you can absolutely choke a gpu when overloading it with a heck of a lot of one single workload. that might be one specific shader, or absolutely insane geometry load, or stuffing the vram. 1. 3D models. models are basically a wireframe that form a body. the possible level detail of a model is determined by the number intersecting lines of the grid. patches formed by the grid are refered to as polygons (there are different types like ngons, quads, not gonna touch on that). a high polycount gives you a higher resolution mesh with potentially more detail, HOWEVER you can have a model with millions of polygons with no details at all. the polycount is direct geometry load on the gpu. the higher the polycount in the scene, the higher the load on the gpu. once you overload the geometry pipeline with absolutely insane levels of geometry, the gpu performance drops off a cliff. this is basically what tessellation does - it takes a simple wireframe and bloats the polycount, increasing mesh fidelity, but blasting the gpu with geometry load. this was nvidias big trick to choke radeon gpus in certain games using gameworks or hairworks. nvidia massively increased the geometry capability of their gpus starting with fermi, and tried to get studios to use their tessellation libraries found in gameworks/hairworks that would absolutely obliterate radeon gpus with stupid high amounts of geometry load. notable games are the witcher 3 with hairworks and crysis 2 with environment tessellation that does absolutely nothing except cutting radeon framerates in half - this is why you can find the tessellation factor option in the radeon and intel arc driver, it limits the mesh complexity scaling of tessellation. geometry load is the whole visible scene with all models and map geometry on the screen. so you want to keep the polycount of the rendered scene as low as possible, and you absolutely want to avoid wasting polygons on geometry that doesnt even need it. a cube can be done with a "single digit" number of polygons, or 2.000.000.000.000 without any visible difference. you can have thousands of the minimal polygon cubes on screen without breaking a sweat, while just a few of the bloated cube will make your gpu scream. modern gpus can handle a ton of geometry load, but this is not an excuse to just waste it. having a ton of unnecessary polycount puts unnecessary load on the gpu, and is a result of lazy mesh optimization. sure, you want higher fidelity models for better visuals, but you can assume that studios rather cut on time per model in exchange for worse client side performance. one technique, usually used in older games, is "backface culling", which basically deletes all parts of the model that the player is never seeing, cutting geometry load. there are possible artifacts when you can actually see the deleted backface, and the model looks hollow. today this is not done alot because gpus are pretty powerful, but there are situations where this should still be done but isnt. but dont worry, polycount isnt the only way to have detailed models, theres a way to simulate polycount with textures, thats why we will switch over to... 2. textures: textures in games have 3 main usecases. 1. give color and texture to a 3d model and to the map/environment, 2. decals and sprites, and 3. control shaders. like you already heard textures are relatively easy on the gpu, HOWEVER, this is not entirely true across the board. the taxing factor of textures is resolution, file size and function - hitting the Vram and the shader pipeline. resolution gives better clarity, but bloats filesize and you can combat filesize with compression. you wanna set a texture resolution that makes sense. high resolution textures that the player is viewing up close, low resolution where it doesnt matter so much, also use compression where possible. this applies for the albedo map, or diffuse map, which is basically the texture that gives you the color information. there are other textures that control shaders, like bump and normal maps, specular maps, phong shader maps, self illumination maps, parallax maps. these textures tell the engine what to do with which part of the texture. these can be greyscale or include different informations on each of the R G B channels, like a normal map (this is a very fancy bumpmap with accurate "3d" information baked into 2d space. normal maps are either hand made (legacy) or more commonly "baked" in a 3d application from a high resolution version of a 3d model to reduce geometry load by using a low poly model + normal map instead of a model thats 100-1000 times the polycount). so you can use a 2d texture to reintroduce "3d" details back onto a low poly model. the normal map acts somewhat like a textured rubber glove you pull over your hand. normal maps should not be lossy compressed, because it will introduce awful blocky artifacts when light hits the object, and normal maps usually also have an alpha channel (greyscale channel next to the RGB channels) with a different function, usually controlling a different shader, like specularity, which makes the normal map a chonker in file size. you dont wanna overdo normal map resolution, as it will eat vram for breakfast and very high resolution normal maps also put more load on the shader pipeline. a gpu can withstand a considerable amount of normal maps, but you can obviously overdo it. lets briefly talk about how you map texture space to models. in the 3d modeling software you "unwrap" or "uv map" the model into 2d space. imagine taking a roll of toilet paper and cutting it across the long side, now you can put it flat on the table and when youre done painting, you can put it back into a roll shape. its basically the same with 3d models, but theres a twist. with the toilet roll you have a 1:1 representation of the model and the texture, but with 3d models you set a texture size (for example 2048x1024) and then you place and scale parts of the model onto it. the bigger the parts on the uvmap, the more pixel space they get, hence higher resolution. now comes the kicker: to preserve texture size you map important parts big and unimportant parts, that are barely visible, but can still be seen, small. take a gun, for example - you want the regions close to the camera to be as high resolution as possible, but you also have tons of parts that just need color, but arent usually seen, or just are plain black that can be smaller. you can also use mirroring to cut uv map area in half for some parts. by not properly scaling the parts of the uv map you can end up with a very unoptimized uv map that gives you worse resolution to important parts while being twice the size. the impact of one bad texture set for one model isnt big, but consider a scene sometimes containing hundreds or thousands of assets. it adds up.

299 |