Cost of hires meshes compared to lowres + baked normal maps


Did anyone compare what is performance cost of having hi res ( 4x more polygons, 1x subdivision in modeling app) vs lowres + baked normal maps. I have read that modern GPU can chew a lot of tris, perhaps not having normal maps can save some workload.

I want to avoid tedious process of generating low res mesh from hi res, cage for normal map baking, and maintaining them if hi res will change. Why not just go hi res ? Low/Hi ratio is 4x.

Looking for tips from you guys. Im from vfx, having mils of polys ( yes, im not used to say “tris” :stuck_out_tongue: ) is normal, the more the better haha.

It’s all situational really. Baking down a 40k poly mesh down to 10k polys is completely worth it, but baking down 400 polys to 100 polys maybe not so much. Unless of course, that 100 poly mesh would be used 10 times in the scene, then all of a sudden it’s worth it again. Just use your best judgement really, there’s not really a hard rule, it even varies depending on your target hardware. Maybe you’re trying to save on texture memory so you’re cutting normal maps and using some higher poly models, or maybe it’s the opposite.

I will say this though, there is no case where 1 million polys for a single mesh is a good idea :stuck_out_tongue:

You can get away with midpoly models, like using a 5k mesh instead of a 1k mesh. With polygons, what really impacts the performance is having a lot of tris that are smaller than 2x2 pixels (quad overdraw). If there’s 8 tris going through 2x2 pixels, it’s 8x more expensive to render. If half of your screen is covered by 2x2 pixels being cut up by 4+ polygons, it’s really going to impact your frame rate. Of course LODs would really help reduce the geometry complexity so that would be less of an issue. Thin/long tris can also cause more quad overdraw, so optimizing polycounts to the point where you are getting a lot of long thin tris isn’t helping. UE4 has a quad overdraw view in view modes > optimizations.

Hi tas, I was also a vfx convert when I started with UE4, so I feel your pain. What Daniel and ZacD said are both very useful tips and I would like to just add on. I would say that you could get away with using some high poly meshes (not crazy high poly, mind you.), Although if you do, if you want avoid performance issues, you should definitely make use of aggressive LOD transitions. But you’ll also need a way of making up for the performance cost, as well. Like Daniel said, a big factor is what hardware you’re targeting, and unfortunately it’s not as simple as spec sheets and and benchmarks. Different GPUs handle different things better and worse than others. Even if they’re in the same GPU brand and family.

I mean, if you’re aiming for as close to photorealism as possible, then my suggestion would be to bake normal for most of your meshes. Because, from what I’ve experienced, the actual meshes and textures aren’t usually the issue when it comes to performance, unless they have either crazy high or really poor topology. You’ll be getting far larger performance hits from things like particle effects, Screen-space/planar reflections, dynamic ambient occlusion, non-static lighting, tessellation/displacement, movable lights, certain directional lighting options, poorly executed code/blueprints, and of course, draw cells.

Textures, including normal maps aren’t usually an issue, especially with higher end GPUs because of texture streaming, as long as occluders are used effectively.

Something else you could use is distance-based tessellation and displacement, which will subdivide the polys, or tris in the case of a game engine, and implement the displacement map as the main camera gets closer to the objects.

Zbrush’s decimation plugin is useful for reducing and maintaining a high poly silhouette while reducing the poly count significantly.

Hope some of this helps!