So we all know PA has a great built in LOD system. However, i'm wondering if there are any guidelines in place in terms of texture size and poly counts for units. Does the LOD system create simplified models out of the base PAPA, or am I rather just thinking about how the game doesn't render units that are covered by their strategic icons? In any case, perhaps we could have a discussion on tools/techniques to bring down poly count and texture resolution to fit the scale of PA without destroying unit quality.
Wait, we do? For features (small rocks, trees, metal greebles, etc.) we have the full resolution model, a "sprite" like representation (3 axial planes with a flat texture, or "impostors") and hidden. For planets the mesh detail never changes, we never really hide them, we just modify their texture resolution dynamically. For units we either show a unit or we don't (either from distance or if hidden by a strat icon). We don't do any mesh decimation (reducing the poly count), and we don't create impostors for anything but features. All of our unit models are by default so low poly that almost any level of detail on the mesh would just reduce them to polygon soup. That and the rendering of units has yet to become a limiting factor, even when there are 5000 of them on screen. We don't even instance units yet.
Trees (and all features in general) are done in (almost*) one pass per mesh, per planet, per LOD, per every few thousand. So a single tall pine tree and a single short pine tree are two passes, as would be 5000 tall pine trees and 5000 short pine trees, or 2500 pine trees as full poly meshes and 2500 pine trees as impostors, etc. There's a limit on the number of trees per pass because we store the location data in what are essentially textures, so we're beholden to existing texture size limits. There are other methods, but the performance varies too much from video card to video card (even from the same manufacturer). * Technically there's a second pass for every pass that includes shadow casters for the light's "view". There's also instancing for particles and the decals used for rendering the planet virtual textures. However we never implemented instancing for animated objects like tanks or buildings. We didn't even do it for projectile meshes, though those don't animate generally. There's always been bigger fish to fry for performance. The biggest gain we got for units was we stopped updating their animation if they're far enough away.
So Ben, regarding textures, does that mean that keeping relatively high resolution textures on models shouldn't be much of a problem due to the dynamic resolution change? Or, rather, would a lower-res texture still be important to performance, especially on a low tier spam unit? Besides that, since the full mesh is "rendered" as long as it's "visible" perhaps for high poly count objects it would be a good idea to bring the object in after a bit of poly decimation? In your tests, did you ever come across a certain # of polys where the mesh rendering started to really break performance?
Only the terrain virtual texture resolution is dynamic. And even then the actual virtual texture dimensions are a fixed size. It's more complex than I want to type out in this post. Unit textures we output through our internal process at a fairly high resolution, especially commanders. However the actual texture assets shipped in the game have commanders at 512x512 and most units smaller than that. Some might be as low as 32x32. We do this because the engine doesn't support dynamic texture sizes. The full resolution of all textures are loaded into memory and onto the video card even if only the lowest mipmap levels are used. There's little impact in actual performance using a higher resolution texture, it's simply a matter of reducing memory usage. As for poly counts, we never tested high poly models because that wasn't the style of the game. Generally we've shot for a few thousand polys for commanders (5k or so max), and much, much less for everything else. Trees top out at around 150 polys. We did this because we wanted to be able to render thousands of them. As for exactly how many polys starts to cause problems, that's entirely dependent on the number of that unit you want on screen and what kind of hardware you have. You could probably make a commander with a million polygons and it might not noticeably change performance for some, and a 20k poly commander might mean the difference between a playable and unplayable game for another. This is the nature of PC development.
Really do appreciate the information bgolus. Hopefully this is helpful for anyone else bringing in some custom models/textures and wondering how to not make the game totally bog down.
