Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Tetzlaff

Number of polygons?

Recommended Posts

Just for comparison, what is the avarage number of polygons on a high poly character model which is used for the bumpmap rendering, and the lower poly model you actually see in the game (Doom3)?

And what is the avarage polycount of a Quake3 player model, and of a UT2003 / Unreal2 player model?

Share this post


Link to post
Tetzlaff said:

Just for comparison, what is the avarage number of polygons on a high poly character model which is used for the bumpmap rendering, and the lower poly model you actually see in the game (Doom3)?

And what is the avarage polycount of a Quake3 player model, and of a UT2003 / Unreal2 player model?


Don't know... Quake3 maybe 500-1000 polygons and UT2003 2500-4000 and U2 the same...

I forgot that Nintendos Ethernal Darkness is using 5000 polys on the characters and the monsters have around 2500 to 5000 polys...

Share this post


Link to post

The reference models are between 100,000 and 300,000 polys (a rough estimate), while the in-game characters are between 2,000 and 6,000. The average Quake3 model has about 500 to 800 I think, and I don't know about UT.

I believe John Carmack said a while ago they were looking at about 100,000 to 150,000 polys in a typical complex Doom III scene. That's 15 times the geometry of a complex Quake 3 map.

Share this post


Link to post

After doing a quick and sloppy google search I found some contradicting comments about the U2 character polycounts, some say 3000-5000 like Ultimate Demon, some say arround 8000, or even 10,000 for the U2 character Aida... on the official Unreal Engine News site they only are talking about the poly increase of the level geometry in comparison to UT.

Share this post


Link to post

Apparently Call of Cthulhu's characters are made up of 10 000 polygons each. The engine's shadowing looks great, almost as good as Doom 3's per-pixel lighting system, as does the physics engine. I don't like the structure of the model's heads in CoC though

What you do with the polygons matters the most in my opinion, how many there are isn't as important if you can't make a good model out of them.

Share this post


Link to post

Heh, today at polycount Epic made this comment about UT2K3 :

The models will have a rough limit of 3000 with 512x512 being the default texture size. Getting player models into the game is going to be very similar to what current UT modelers will be familiar with.

Share this post


Link to post
Tetzlaff said:

..what is the avarage number of polygons on a high poly character model which is used for the bumpmap rendering, and the lower poly model you actually see in the game...


Bumpmapping isn't used only on the hi-res models. Bumpmapping is used everywhere.

The hi-res models are used in the cutscenes, I don't know how many polys they are. The ones you see while playing are just a few polys more than the Quake3 models (~150 more).

In the legacy video, Fred explained that they make an extremely hi-res model first, then they make an extremely lo-res version of the same model and use the hi-res to generate bumpmaps for the low-res. Once it's all ingame, the model looks comparable to the original hi-res model that was made (the "John Carmack magic"). The original hi-res model isn't used at all after that.

They actually create two low-res models from the hi-res. One higher res than the other, used for the ingame-cinematics. The cinematics are still rendered by the engine in realtime, but because the player isn't interacting during the cinematics they can sacrafice some processing power to draw the extra polygons.

:)

Share this post


Link to post

Doom3 will have around 2500-3000 per character.
To increase the polycount isnt a good solution.
Take a look at doom3, it will have definitly less polys than unreal tournament 2003 (ive played the leaked demo) or unreal2 (played the leaked e3 techdemo). But it will look much better by using bumpmaps.
Ive youre close to a unreal model it looks like plastic and flat, thats all.
More polys doesnt make a more realistic look without bumpmapping.
I think ids way is the right way.
Epic just incresed the amount of polys and size of textures theres definitly NO new technologie used. And they bought the physiqs engine instead to create a own like id has done.

Share this post


Link to post

Epic are simply lazy by using so many polys without using efficient ways to cut them down with no loss in detail as in Doom 3. Licensing a physics engine is another example of bone-idleness.

Share this post


Link to post
Burzum said:

Doom3 will have around 2500-3000 per character. To increase the polycount isnt a good solution. Take a look at doom3, it will have definitly less polys than unreal tournament 2003 (ive played the leaked demo) or unreal2 (played the leaked e3 techdemo). But it will look much better by using bumpmaps.

Well, no. You're right in that the bumpmaps make relatively low-poly models look like they have more detail than they really do. But Doom 3's characters will NOT be lower poly than Unreal's in general - as I said at the top of this thread, according to John Carmack the models are between 2000 and 6000 polys.

Share this post


Link to post
GiXeLz said:

In the legacy video, Fred explained that they make an extremely hi-res model first, then they make an extremely lo-res version of the same model and use the hi-res to generate bumpmaps for the low-res. Once it's all ingame, the model looks comparable to the original hi-res model that was made (the "John Carmack magic"). The original hi-res model isn't used at all after that.


The high-res model is *used* in the way you described it, it just isn´t rendered in-game because it´s translated into bumpmapping. But the model surfaces are that detailed because of the high-poly model, so when someone is asking "how many polys can the Doom3 engine show" you should tell him about both polycounts (the high-res and the actually rendered in-game).

Share this post


Link to post

Tetzlaff: I just realized you knew what you were talking about when you started this thread.

I don't know the polycount numbers, but I read somewhere that the Doom3 models aren't a whole lot more detailed than the Quake3 models.

Share this post


Link to post
GS-1719 said:

Epic are simply lazy by using so many polys without using efficient ways to cut them down with no loss in detail as in Doom 3. Licensing a physics engine is another example of bone-idleness.


I think Epics focus was different from the start-- Doom3 was mean to be revolutionary, while the new Unreal engine was meant to be a fancy upgrade for todays accelerators. Also, bumpmapping a model takes about 2-3 passes on a GeForce3, where Unreal2's will probably just take 1 pass in the basic case.

Basically, Unreal2 will be much faster than Doom3, I think.

Also, licencing a physics engine is probably the "better" way, in broad concept, to integrate physics. It's a waste of time to re-invent the wheel, and it's admirable of Epic to just admit that all the physics they need has already been done, and be willing to use that.

To put it another way, while code was being written for the physics at id, Epic was probably coding gameplay...

Yes, Doom3 is extremely increadible, but it's not correct to assume that just because everyone else isn't Doom3 graphics, that the programmers or artists are "lazy". Graphics aren't everything, and people just make very different types of games.

Share this post


Link to post

But Epic as a company HAS SHOWN very lazy politics. theyve outright COPIED ideas from other developers since 1993 to today! So i understand why people would be skeptical of their ability

Share this post


Link to post

Let's not see anymore Epic/Unreal bashing, please.

Share this post


Link to post

Its not "bashing", i think its a perfectly valid complaint. theres diminishing returns on polygon counts, at some points the speed tradeoff isnt worth it. Id rather 3000 polygons with the bumpamapping, shaders, curved surfaces and lighting tech id is going for than double that without any of those applied

BUT ALL OF YOU FORGOT THAT ID WILL BE USING CRUVED SURFACES/DYNAMIC GEOMETRY SO POLYCOUNTS ARE IRRELEVANT, some people will have a LOT higher polycounts than others!

Share this post


Link to post
Xian said:

BUT ALL OF YOU FORGOT THAT ID WILL BE USING CRUVED SURFACES/DYNAMIC GEOMETRY SO POLYCOUNTS ARE IRRELEVANT, some people will have a LOT higher polycounts than others!

They're not using any kind of Bezier curves like Q3 or anything. It's all pure polygon geometry.

Share this post


Link to post
Lord FlatHead said:

They're not using any kind of Bezier curves like Q3 or anything. It's all pure polygon geometry.


You tell 'em. If Carmack ever came to these forums and heard someone using the word "parametric surface" in conjunction with one of his games, he'd probably have the forums closed down on the grounds of technical defamation...

I never understood the technical reasons behind his dislike for parametric surfaces in games... Does anyone here know? He said that you could get more "detail" be explicitly specifying vertices, but that's a huge memory footprint compared to simply generating (possibly cheaper) vertices, and using an intellegent displacement mapping scheme. With the new engine, of course, this is impossible, but he really seems to not like these surfaces in general...

Personally, I'm all for them. When the hardware gets to the point where you can generate micro-polygons, we won't need bumpmapping anymore in every case to get per-pixel detail-- you won't have those funny "flat plane" artifacts that you have when stuff moves in Doom3. I think tesselation and deformation of parametric surfaces down to sub-pixel levels is a good stepping stone towards a fully voxelized technology. Yes, you could (possibly) get more explicit detail by specifiny polygons explicitly, but there's a lot of memory there, and a lot of surfaces really do just need to be rounded. For example, a large space dome-- it's a waste to specify the worst case number of polygons just to maintain the apparent curvature over fluxuating view distances. It would be much more reasonable and clean to specify some Tru-Form surfaces, and let the engine do the curvaure for you. His argument that "you can't tell the difference" between a high tesselated curved surface and a low tesselated curve suface is just wrong-- you can tell, just not in a fps game. Slower games, where you have close interactions with chacters and objects (as opposed to just blowing them up from a distance) would achive a noticable boost in quality. The idea that you "won't notice" the curvature is akin to staying with 16bit color because you won't notice the change to 32bit. It's effect and usage is subtle, perhaps, but once you're there, you won't want to go back to the "polygon era".

Sorry about the rant, but I just read Carmacks .plan, and, well, yet another annoying dig at parametric surfaces that might (wrongly, I think) push hardware vendors to drop this interesting direction of technology.

Share this post


Link to post
Lord FlatHead said:

They're not using any kind of Bezier curves like Q3 or anything. It's all pure polygon geometry.

yah, i just saw the videowhere carmack specificaly states "all static geometry" my bad

Share this post


Link to post
Guest
This topic is now closed to further replies.
×