I am also wondering about this as I am working on a couple story building design which has arched windows on the top floor, which has ballooned my tri count up to around 30,000. More then likely it will be double that once the whole building is done.
Depends on the game, how it's played, what angle and distance the model will be seen from.
Only model what you need for the exterior, based on the angles it will be seen from by the player. Windows can be much simpler for the exterior, with most of the details in the texture instead of mesh.
Interiors are usually modeled separately from exteriors, and the exterior is hidden as soon as you enter the building.
Well, modular parts look fine. Polycount is fine as well, as long as the modular parts have proper LODs and LOD away most of the detail.
Especially if you have decent culling in the game as well, then that could mean that half of the building wouldn't even be showing if you're on one side of it. Or most of the building can't be seen if you're inside of it.
This way also means that you'd have more drawcalls of course, but it's something you have to balance. Sometimes it's better to put together a building using modular parts in Maya, then combining chunks of the building and export it as chunks and put it together again in your game engine of choice.
Chrisradsby: When you say combine the chunks in Maya then export as one model. Those chunks would have to use the same texture though? Otherwise it would have to be a multi-material object?
I'd say you actually went a little overboard on your modularity. If you have 590 windows alone, are we looking at close to 1000 separate meshes for that building?
Performance optimization is always tricky and always a balancing act. Modularity mainly saves on memory footprint, but going overboard will mean taking a hit in other areas. For every instanced mesh, the engine has to do an occlusion and frustum check to see if that mesh should be culled, and those can add up to a significant amount of frame time, especially if you're going into the 4000+ range.
Like chrisradsby mentioned, start merging and combining those meshes into bigger chunks before placing them in game.
Also, in terms of triangle counts, current gen hardware tends to have an upward limit of ~300k rendered triangles before you start to get vertex bound. Granted, that number is very much a ballpark estimate because the true limit is based on way too many variables, but it is a good rule of thumb number to shoot for.
I am currently running into a similiar problem. How do you deal with losing light map resolution when you start combining all the windows? Each window will still needs it's own lightmap space on the UV layout because you can't have over lapping UVS on lightmaps.
Would you just crank up the light map resolution really high to compensate?
You can overlap the UVs if you know the lighting will be the same, for example they'rthey're all on the North side in shadow. But that's a pain to deal with in practice. Usually you just accept the lower resolution and use automatic lightmap UVs.
Replies
As Chris said, would be so much easier to give you advice if you posted images.
Only model what you need for the exterior, based on the angles it will be seen from by the player. Windows can be much simpler for the exterior, with most of the details in the texture instead of mesh.
Interiors are usually modeled separately from exteriors, and the exterior is hidden as soon as you enter the building.
Especially if you have decent culling in the game as well, then that could mean that half of the building wouldn't even be showing if you're on one side of it. Or most of the building can't be seen if you're inside of it.
This way also means that you'd have more drawcalls of course, but it's something you have to balance. Sometimes it's better to put together a building using modular parts in Maya, then combining chunks of the building and export it as chunks and put it together again in your game engine of choice.
Performance optimization is always tricky and always a balancing act. Modularity mainly saves on memory footprint, but going overboard will mean taking a hit in other areas. For every instanced mesh, the engine has to do an occlusion and frustum check to see if that mesh should be culled, and those can add up to a significant amount of frame time, especially if you're going into the 4000+ range.
Like chrisradsby mentioned, start merging and combining those meshes into bigger chunks before placing them in game.
Also, in terms of triangle counts, current gen hardware tends to have an upward limit of ~300k rendered triangles before you start to get vertex bound. Granted, that number is very much a ballpark estimate because the true limit is based on way too many variables, but it is a good rule of thumb number to shoot for.
Would you just crank up the light map resolution really high to compensate?
Thanks!
You can overlap the UVs if you know the lighting will be the same, for example they'rthey're all on the North side in shadow. But that's a pain to deal with in practice. Usually you just accept the lower resolution and use automatic lightmap UVs.