numberof faces/polygons for BA models
Moderators: MR.D, Moderators
numberof faces/polygons for BA models
how many faces/Polygons are usually used for BA Units?
Re: numberof faces/polygons for BA models
I looked up a few with upspring...
polygons, vertexes - bar polygons, bar vertexes:
armspid: 63, 136 - 1422, 2901
corstorm: 85, 163 - 1166, 1965
cortron: 93, 129 - 500, 839
cormort: 116, 186 - 1428, 2633
correap: 124, 174 - 796, 1298
corthud: 136, 242 - 1061, 1787
armcom: 186, 302 - 3250, 5533
corafus: 254, 365 - 2596, 3699
corcat: 316, 403 - 2852, 4977
corbats: 319, 768 - 1363, 2482
polygons, vertexes - bar polygons, bar vertexes:
armspid: 63, 136 - 1422, 2901
corstorm: 85, 163 - 1166, 1965
cortron: 93, 129 - 500, 839
cormort: 116, 186 - 1428, 2633
correap: 124, 174 - 796, 1298
corthud: 136, 242 - 1061, 1787
armcom: 186, 302 - 3250, 5533
corafus: 254, 365 - 2596, 3699
corcat: 316, 403 - 2852, 4977
corbats: 319, 768 - 1363, 2482
Re: numberof faces/polygons for BA models
thank you very much Floris. there is a big difference between OTA and BAR. Why is BAR not significantly slower with more polygons (or is it and i didnt notice?)?
Re: numberof faces/polygons for BA models
OTA models are ancient, BAR models have maybe 10x more on average? Even low-end gpu's dont have much issue with rendering this. The issue they might have would rather be in the sense of having lots of shaders and/or high resolutions and other quality effects outside the models themselves.
Also the game is mostly CPU botlenecked due to 'simulation' calcs overshadowing everything else when there are lots of units in play.
Also the game is mostly CPU botlenecked due to 'simulation' calcs overshadowing everything else when there are lots of units in play.
- Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Re: numberof faces/polygons for BA models
About 12 years ago, Caydr (who created AA which was the precursor of the BA fork) got in an argument with someone over whether polycount mattered. At that time, most ppl we're still culling unseen faces and going to extremes to optimize their models.
Caydr went so far as to make a new game with stupidly high polycounts. Caydr asserted at one point that even shitty integrated gfx cards could take a trillion polys without choking, and he was largely correct. The way he went about proving it was probably over combative (however, I likely would have approached it exactly the same way), but it was effective in creating a lasting memory that is occasionally referenced 12 years later.
In part, caydr's experiment made Kaiser's Legos possible. On any given Evo model there are probably 50-100 wasted faces (because you're throwing a bunch of fully textured models together), but it doesn't matter for several reasons. First reason is what we have been talking about. Modern shut tier gfx cards can handle stupid numbers of polys and not bat an eye. Second reason is that according to my napkin calculations done a while back, at 27 models, Lego becomes BRUTALLY efficient. Iirc Evo has about 72ish individual models (consisting of over a hundred actual different units (because upgrades, and etc)).
So even though BAR might seem a bit wasteful in some areas, in actuality, it is a super efficient use of assets. OTA models have the underside of model faces culled because the camera was strictly isometric top down. As a result, in 1997, reducing that poly count matter a great deal because at that time the rendering was being done at the software level. Dedicated gfx cards at that time were few and far between. Iirc, fxglide was popular at that particular time.
Anyway, fun little blast from the past. I might have gotten some of the more fine details not 100% correct, as most of this is from sheer memory, but it should, in general, be pretty spot on.
Caydr went so far as to make a new game with stupidly high polycounts. Caydr asserted at one point that even shitty integrated gfx cards could take a trillion polys without choking, and he was largely correct. The way he went about proving it was probably over combative (however, I likely would have approached it exactly the same way), but it was effective in creating a lasting memory that is occasionally referenced 12 years later.
In part, caydr's experiment made Kaiser's Legos possible. On any given Evo model there are probably 50-100 wasted faces (because you're throwing a bunch of fully textured models together), but it doesn't matter for several reasons. First reason is what we have been talking about. Modern shut tier gfx cards can handle stupid numbers of polys and not bat an eye. Second reason is that according to my napkin calculations done a while back, at 27 models, Lego becomes BRUTALLY efficient. Iirc Evo has about 72ish individual models (consisting of over a hundred actual different units (because upgrades, and etc)).
So even though BAR might seem a bit wasteful in some areas, in actuality, it is a super efficient use of assets. OTA models have the underside of model faces culled because the camera was strictly isometric top down. As a result, in 1997, reducing that poly count matter a great deal because at that time the rendering was being done at the software level. Dedicated gfx cards at that time were few and far between. Iirc, fxglide was popular at that particular time.
Anyway, fun little blast from the past. I might have gotten some of the more fine details not 100% correct, as most of this is from sheer memory, but it should, in general, be pretty spot on.