"Yes, but how many polygons?" An artist blog entry with interesting numbers

Yep. On the PC at "Ultra" view distance setting, which is really kill-your-GPU overboard, the same scene I just measured reaches > 6.5 mln.

Wow, that's some for a RTS and I who was going to up LODs... XD

Well a lot but my 4890/E8400 didn't have a problem on fat progress in demo so once I buy the game then LOD away! :mrgreen:
 
Last edited by a moderator:
Heh, after seeing the visuals on PC, I thought the 360 might struggle. Getting it working at all is a big enough achievement.

The struggling, and any of the deficiencies of the Xbox 360 version should be attributed to our inexperience (this is our first 360 title, and first console title ever), and the extremely short schedule. The hardware can do a lot more.

But this is not interesting in the context of this thread; my point is that the raw number of total polygons per scene is not interesting. If we had more time (and budget, of course) to spend on Tropico 3, the polygon number would have been lower, the framerate would have been higher, and the screenshots would have looked about the same. You probably wouldn't tell the number 3 million from a wireframe screenshot, and certainly not from a shaded one.
 
Heh, after seeing the visuals on PC, I thought the 360 might struggle. Getting it working at all is a big enough achievement.

Would be interesting to know how such high polygon numbers are dsitributed in a RTS games. A mix or emphasis on clutter or terrain etc. And how it relates to games functionality.

Like here in in DOWII the terrain has lots of polygons but it even stretches into non-playable areas and on non-accessible parts (walls guard rail)). I mean sure you can deform terrain but still.. :eek:
http://img27.imageshack.us/img27/4474/dow2polygons.jpg
 
Would be interesting to know how such high polygon numbers are dsitributed in a RTS games.

For us, most of the pain comes from the nearby trees - there's still a good 1000-2000 of them before they turn to billboards, and they are pretty high-poly and have no geometry LODs; and the buildings, especially in the late game when you have built up the island. Before a round of Xbox 360-related geometry trimming (aimed at reducing memory footprint, not on-screen vertex count), we had several buildings above 20k vertices, and one at almost 50k!

Also, artists love sunset lighting, with the sun pretty low above the horizon - which means a very slanted shadowmap frustum, and lots of objects in the shadowmap. We typically have more vertices/polygons rendered in the shadowmap than in the normal scene (thankfully there is little to no pixelshader when rendering the shadowmap).
 
For us, most of the pain comes from the nearby trees - there's still a good 1000-2000 of them before they turn to billboards, and they are pretty high-poly and have no geometry LODs; and the buildings, especially in the late game when you have built up the island. Before a round of Xbox 360-related geometry trimming (aimed at reducing memory footprint, not on-screen vertex count), we had several buildings above 20k vertices, and one at almost 50k!)

So lack of several LODs for trees up the polygon count quite some. Out of curiosity wouldn't this be a perfect opportunity to use tesselation for a more "sane" (;) ) polygon budget?

How many polygons would it be for the 20k and 50k vertices buildings?

Also, artists love sunset lighting, with the sun pretty low above the horizon - which means a very slanted shadowmap frustum, and lots of objects in the shadowmap. We typically have more vertices/polygons rendered in the shadowmap than in the normal scene (thankfully there is little to no pixelshader when rendering the shadowmap).

Interesting, thanks for sharing! :)
 
As far as number goes, the highest poly count displayed on screen has to be Lair, the density of the main dragon and the number of objects in the environment are simply astounding.

It boilsdown to if it is curved objects, sprite distance, terrain tesselation LOD levels etc. There being "lots" of obejcts alone aint a solid argument for high polygon levels. But looking at screenshots/videos I doubt that could be more than 2m at best. LODing is heavily used.
 
It boilsdown to if it is curved objects, sprite distance, terrain tesselation LOD levels etc. There being "lots" of obejcts alone aint a solid argument for high polygon levels. But looking at screenshots/videos I doubt that could be more than 2m at best. LODing is heavily used.
Well clearly you haven't played the game then :), some of the levels featured polygon density far superior to what screenshots are available on the net. It's a pretty old game now but the technology behind it bears great potential if ever unleashed to full.
 
So lack of several LODs for trees up the polygon count quite some. Out of curiosity wouldn't this be a perfect opportunity to use tesselation for a more "sane" (;) ) polygon budget?

Possibly, but it would be orders of magnitude harder for the artists to learn how to produce these hypothetical tesselation-based trees, than to produce a few more mesh LODs. And our main limiting factor for this project (and for all projects in the foreseeable future) is development time, not polygon throughput of the hardware.

Our artists - and most other studios, judging by the games I play - haven't yet mastered normal maps after all these years. Going to a spline + displacement map based pipeline will be a HUGE PITA.

The main attraction of tesselation, as I see it, is the promise of drastically reducing memory, not polygon count - e.g. see the lecture on the terrain system in Halo Wars, where it spared them the need to store index buffers for LODed terrain.

Nebula said:
How many polygons would it be for the 20k and 50k vertices buildings?

A quick statistics on the buildings art shows we have around 7:10 ratio triangles:vertices for buildings (lots of rectangular and box-ular elements, lots of texture reuse -> lots of duplicated vertices).
 
I don't think it's true, not sure if it is anyways.

There's actually no reason for it to be that high, until they show more info like a wire frame mesh of the new Nathan than we can say it's true. frankly, i think it's the same poly counts just with rougher looking textures.

for one, the hair in uncharted2 looks pretty much like it's not changed or increased in polys, meaning it's got the same bends to it, and the ears look the exactly the same.

UC2
http://i38.tinypic.com/282m176.jpg
UC1
http://i37.tinypic.com/20a2fs8.jpg

And the neck collar on the new Nathan in the shot also has solid bends in it.

the first uncharted had just the right amount of polygons, with the average of 15k for enemies, main characters ranging 20k+ polygons, and with the main character "Nathan" being 26k.
http://i38.tinypic.com/rmi77l.jpg

i think 80k is the model for some instances in cutscnes, but they claim to use the same assets for cutscene and in-
game clearly with LOD, differently from UC1 where the assets isn't the same.
 
i think 80k is the model for some instances in cutscnes, but they claim to use the same assets for cutscene and in-
game clearly with LOD, differently from UC1 where the assets isn't the same.

UC1 character models are the same according to Rich Diamant.

UC2 character models outside of more detailed textures look to be the same as well.

Both games use better lighting for their recorded cutscenes.
 
Here is a good ingame pic of drake with alot of detail:

94adced260151d.jpg

How do you do the hidden image tag?
 
i think 80k is the model for some instances in cutscnes, but they claim to use the same assets for cutscene and in-
game clearly with LOD, differently from UC1 where the assets isn't the same.

I think 80k is for max lod when you move camera so you are very close to the character model.

I think you can do this when you move the camera and the character is near a wall so the camera is forced to be close to the character. I always do this for 3rd person games to see character detail at max LOD.

I remember doing this first time for Ratchet on PS2 and thinking wow they put a lot of detail, even the animations are great, so the character looks great even very close at max lod in-game.
 
I have it pre-ordered, although mostly for Gio Nakpil's article. He's been a modeler at ILM for many years and is a very good artist.

As for KZ2, I wouldn't expect poly count numbers; at least the previous Character modeling book from Ballistic, that had the articles on Gears of War, had no hard data on Epic's stuff.
But if you look at this picture:
http://www.flickr.com/photos/teohyc/4079988904/sizes/o/in/set-72157614774709640/
well it doesn't look that high to me, about 12-15K.

Not to mention that those few pages actually talk about outsourcing a lot of the artwork to Massive Black, an independent art studio...

Anyway, once I get the book I can write up a short summary of the KZ2 info.
 
I have it pre-ordered, although mostly for Gio Nakpil's article. He's been a modeler at ILM for many years and is a very good artist.

As for KZ2, I wouldn't expect poly count numbers; at least the previous Character modeling book from Ballistic, that had the articles on Gears of War, had no hard data on Epic's stuff.
But if you look at this picture:
http://www.flickr.com/photos/teohyc/4079988904/sizes/o/in/set-72157614774709640/
well it doesn't look that high to me, about 12-15K.

Not to mention that those few pages actually talk about outsourcing a lot of the artwork to Massive Black, an independent art studio...

Anyway, once I get the book I can write up a short summary of the KZ2 info.
They did provide numbers actually, in character modeling 2 at least. Kevin Lanning the Epic artist mentioned the Boomer game model is 10952polys, Wretch model is 10292 and Marcus is 15k.
But yeah, didn't know Gio Nakpil is from ILM, would love to read his impressions for sure. I'll be getting it too if it reaches Down under, can't wait to hear your review if you do get it early mate:).
 
Heh, you're right, it's been a while since I've looked at that book.

Then again, I don't expect any fireworks once we get an official poly count for one of the KZ2 characters...
 
Back
Top