(Solved) Environment Props Polygon Estimate
polycounter lvl 6
Hi,
So I am making a management/builder sim that involves interior design, eg. many unique props, like The Sims series.
One thing I am still not quite sure is how many polygon to spend on my unique props.
I want to share my current line of thoughts: please let me know whether they make sense and whether I made any obvious oversights/mistakes.
----
- I understand for large team, polygon count estimate is established early in the development cycle, given engine and target platform. That's all great, when they have experienced graphic programmers.
- Since I am working as the sole modeler + programmer, I have more flexibility but less confidence in my estimate: I am thinking I should aim a bit higher, and once I have enough props to stress test with target platform, I can reduce polygon or use LOD or batching to make up for performance.
- The target platform often has decent CPU but weak GPU (aka Laptops, often a recent i5/i7 + Intel GPU), so I am thinking polygon count matter less than texture memory and draw calls.
- My estimate is something like the following:
i) the camera FOV where LOD0 comes in covers a 20m x 20m grid; the closest zoom-level covers a 10m x 10m grid.
ii) for a worst case scenario, assume each cell contains an unique prop, as players can build however they want.
iii) I want to keep on screen models at 500,000 polygon cap, and leave 200,000 polygon budget to on screen characters; it sounds like a lot for environment, but keep in mind this is a builder/management sim.
iv) to be safe, my models can have (500,000 - 200,000) / (20 * 20) = 750 polygons on average.
----
The problems I face are:
- 750 polygons are too strict to have a smooth silhouette when camera is at closest zoom (10m x 10m grid).
- Adding another LOD level between 10x10 and 20x20 zoom levels are not worth its overhead, plus LOD pops would be very noticeable.
- So I am thinking, let's have a more relaxed cap, say 750 * 4 = 3000 polygons, and optimize for the 10x10 zoom level. When I actually run into performance issues I can reduce polygon then.
Does my estimate sound fair? How does large team estimate polycount budget anyway?
(I have read wiki and links, but estimating on screen polycount are quite different from static polycount. For example, I saw polycount estimate for PS4 game scene varies from 11M to 0.4M, I think my 500K cap is a conservative value?)
(Also I am using Unity, so I have read their guide to performance too, my estimate assume draw batching etc.)
So I am making a management/builder sim that involves interior design, eg. many unique props, like The Sims series.
One thing I am still not quite sure is how many polygon to spend on my unique props.
I want to share my current line of thoughts: please let me know whether they make sense and whether I made any obvious oversights/mistakes.
----
- I understand for large team, polygon count estimate is established early in the development cycle, given engine and target platform. That's all great, when they have experienced graphic programmers.
- Since I am working as the sole modeler + programmer, I have more flexibility but less confidence in my estimate: I am thinking I should aim a bit higher, and once I have enough props to stress test with target platform, I can reduce polygon or use LOD or batching to make up for performance.
- The target platform often has decent CPU but weak GPU (aka Laptops, often a recent i5/i7 + Intel GPU), so I am thinking polygon count matter less than texture memory and draw calls.
- My estimate is something like the following:
i) the camera FOV where LOD0 comes in covers a 20m x 20m grid; the closest zoom-level covers a 10m x 10m grid.
ii) for a worst case scenario, assume each cell contains an unique prop, as players can build however they want.
iii) I want to keep on screen models at 500,000 polygon cap, and leave 200,000 polygon budget to on screen characters; it sounds like a lot for environment, but keep in mind this is a builder/management sim.
iv) to be safe, my models can have (500,000 - 200,000) / (20 * 20) = 750 polygons on average.
----
The problems I face are:
- 750 polygons are too strict to have a smooth silhouette when camera is at closest zoom (10m x 10m grid).
- Adding another LOD level between 10x10 and 20x20 zoom levels are not worth its overhead, plus LOD pops would be very noticeable.
- So I am thinking, let's have a more relaxed cap, say 750 * 4 = 3000 polygons, and optimize for the 10x10 zoom level. When I actually run into performance issues I can reduce polygon then.
Does my estimate sound fair? How does large team estimate polycount budget anyway?
(I have read wiki and links, but estimating on screen polycount are quite different from static polycount. For example, I saw polycount estimate for PS4 game scene varies from 11M to 0.4M, I think my 500K cap is a conservative value?)
(Also I am using Unity, so I have read their guide to performance too, my estimate assume draw batching etc.)
Replies
I have heard a few GDC talks about polygon budget, but AFAIK, most of the time artists don't have a hard cap, just a soft average they need to hit. I would like to know how to establish those ballpark number? It's might be less important for performance (eg. premature optimization), but more important from an artist point of view (eg. how much details one can afford to add).
You do want to avoid tiny or thin tris to avoid overshading and consider if you have limitations regarding batching/instancing, so I'd recommend you to do some tests on your target hardware to get the rough estimates on what you can do and start from that.
Your suggestion on avoiding tiny tris is exactly my problem: I know how close the camera would be in game, but when authoring a prop it's easy to waste polygon on curved surface or smaller details.
For example, I knew I wasted polygons on the handlers and wheels, but I couldn't bring myself to reduce them, as they will look "unnatural" at this distance.
While I know in game camera is never this close, I keep wanting to workaround this with LODs. (LOD0 is currently ~3000 tris, I can probably reduce it to ~1000 tris without sacrificing too much details).
Anyway this sounds like pre-optimisation to me. Have you actually hit the limit of what you can do currently? 750 tris per model is nothing. Sure it could always be faster and more optimised, but what do you care about more, performance or a finished game?
After seeing your posts here I have to say, I think you just need a bit of a kick to get on with it. These questions, while worth asking, are more like side projects to your main one. Get the prototype + art finished to the best of your ability first, then worry about sanding the edges.
Will they look unnatural once in context with everything else, with proper lighting and whatnot? I doubt it.
Another resource you have to manage is developer time - might be worth sacrificing some performance at runtime and prop detail for the sake of getting the game done.
I decide to set the soft cap at ~3000 tris per prop and test them in a scene later. By then I should be able to reduce poly in 10s of thousands per scene (if necessary).
The default camera zooming that gives you a wide view of everything, could have LOD 1 which would be just a tiny little less tricount.
Also you could do the other thing: Set a button and 3 cameras, that have fixed zoom.The player can rotate these cameras by clicking that button. This way you can control how close one gets to an object, and you can make LOD's more usefull as well as managing your scene tricount better