Of course, the benefits of having three distinct textures (standard 3-channel texture map, normal map, channel-packed roughness, displacement, metallic) is color, quality, and quicker computation. You’ll be able to have parallax occlusion with a semi-metallic surface, complete with normal maps and full color textures. Even though that expanded capabilities is also twice as memory-intensive and requires 3 draw calls instead of just one, really, memory and draw calls don’t matter anymore. You should try to avoid anything that is computationally expensive, with a high shader or lighting complexity. That will be your bottleneck.
With Direct X 12 being integrated in UE4 and the prevalence of shared samplers, there is less of a need to worry about draw calls. And with 2 GB GDDR5 VRAM + 8 GB DDR4 RAM and solid state drives as large as 250 GB becoming something of a standard on modern computers, memory has already become a problem of the past. If you still obsess about memory, then you’re developing for consoles and mobile. But even the cheapest of consoles have 1 GB of RAM, and they’re all going to be upgraded pretty soon. By and large, as we move into VR, 4K, and beyond-60-FPS framerates, which is where the future is going now, memory will be the last problem we will have to worry about: instead, we should focus on trying to eliminate the computational expense of rendering such features. Achieving higher framerates with even remotely good graphics will cost us DEARLY in GPU computations. We need to find a way to get better graphics for a cheaper cost, and this means looking back at some of the rendering methods from the past: the Gamecube/PS2/Xbox era games can provide some good study cases. Use reflection maps over water instead of realtime reflections. Use smarter textures with basic lighting built-in. Use vertex shading for translucency instead of pixel shading. Use opaque materials instead of translucent ones. Making tons of smaller particles instead of many larger ones. Use geometry in lieu of bump/parallax mapping. Separate materials, and keep them simple. If you have an expensive shader, limit your lighting. Worst case scenario, use static lighting for the world, and only use specular highlights for dynamic lights. On top of that, don’t have too many dynamic lights overlapping each other.
When it comes to materials, as much as it is a pain to admit, the shader complexity and overdraw will always be your number 1 performance killer. As long as your polygon count is not too bad and you’re not using too many 2K textures and your gameplay elements aren’t complete and total overkill, then your problem is nothing else but shader complexity. The Wii ran hundreds of moving gameplay objects fairly easily, and a modern CPU runs 5 times faster than that on just one thread. Most computers have 4 threads, and since more work being done on GPUs nowadays, that frees up our CPUs a lot. That darn GPU is going to be a tough bottleneck to overcome. My PC runs textures like nobody’s business. I shine a few lights on a chandelier, and the rate crashes. If you want to optimize, just try to find a way to make good graphics with the fewest instructions possible. Use multiply exponents instead of the power function. Find ways to reuse calculations so you don’t run the same calculations twice (this was a problem with parallax occlusion in UDK and older versions of UE4). Limit yourself to a majority of 1K, rarely 2K textures, and make sure those pixels count. Use blending and detail texturing techniques to reduce the repetition in materials, and try not to break the bank doing it. Sometimes, less is more. If your material is getting too complex, try to find ways you can keep the same feeling while cutting back on the complexity. If you made an awesome material, find a way to cut down half of your material nodes while still making it feel as awesome as it did before. If you can do that, then you’re gold.
