Appropriate Polygon Counts for Spring

[zwzsg]

There's no compact way to show the real math without going into territory none of you guys are familiar with

[Argh]

OK, so we can all agree on:

1. Spring's usually CPU-bound.

2. For games you're working on now, the bar can be set a lot higher.

SpliFF's reasoning sounds good to me- the only question is where to set the bar at, and that depends on a lot of things, but mainly with your typical scene density. If you're building game with typical Spring maps, then the density's merely the largest collection of guys you expect to see in a major fight, whilst fighting- pretty easy to test.

3. Using an equation's a bad idea. Sorry, I figured it would be easier to understand, but I guess that it just makes it more confusing and annoys people.

4. The list of factors is OK, other than cleaning up technical terms and cutting out some exposition, and providing a really short header version for the reading-impaired.

So, what's the bar, reasonably? 5K for a game that you're starting right now, with a release date one-two years from now, if you're aiming at tomorrow's midrange hardware? I'd have to sit down and do the math, but that sounds about right to me.


Oh, and Smoth: shader cost really depends. I've written stuff that's brought GPUs to a grinding halt, simply because of the math I asked it to do. They aren't truly general-purpose, they don't like branching, and they have other issues that sometimes require workarounds that eat processor time.

For stuff like my lighting shader, practically all of the cost is CPU.

But... and this is a big "but"... to my mind, that's somewhere on the A&M checklist, unless we all think that typical games on this engine will remain graphically tied to whatever Spring can do for them. I am guessing not, in the future, but then again I am always over-optimistic about these things. I really can't imagine people not picking up normalmaps soon, though, tbh- the things you can do with Unit shaders make Spring's default rendering look really bad.

[smoth]

well the issue I draw with normal maps is also the issue that you draw with your assertion about textures/texturesize per unit.

normal maps would add a lot of textures to each unit.

[bobthedinosaur]

_

[aegis]

we require additional polygons

[bobthedinosaur]

.

[SpliFF]

2. Textures: moderate to severe impact. Smaller textures are always faster than larger ones. The number of textures that have to be submitted to the GPU are relevant- each transaction comes with a cost, regardless of size. But larger textures have an impact, due to the time it takes to cross the bus, mipmapping and the final evaluation stages, so you need to balance these things.

This statement is so general as to be misleading. While technically accurate it provides no terms of reference to determine what you mean by "moderate" and "severe".

The truth is it's highly probable, given an arbitrary set of textures and units, that the impact of changing the texture size will be close to nil.

The reasons are:

* The throughput of a typical PCIe x16 slot (most "gaming" boards have at least one of these) is 4GB/s. That's FOUR GIGABYTES PER SECOND. Even older AGP x8 systems are capable of about half that.

* Mip-maps are calculated ONCE, when the texture is loaded, not every frame.

* Textures are cached in DDR3/DDR5 VRAM; which has throughputs of 20 - 40 GB/s (that's bytes, not bits).

* Many, if not most, of Springs map/mod textures come from TA, a game nearly 10 years old, they are very low-res. I'd be quite surprised if the typical Spring game/mod can't fit all of it's in-game textures and mipmap levels in a 512MB VRAM cache with room to swing a 'virtual' cat. It's very likely the system bus is hardly being touched, let alone causing congestion.

* Spring uses texture compression so even large textures do not necessarily consume large amounts of bandwidth or VRAM.

* Most newer GPUs can do subtexture sampling which means they do not have to read the entire texture on every pass.

Anyway I'm not saying textures can't affect performance, especially in combination with shaders, but degrading your texture resolutions sounds like premature optimization until you've tested across a range of midrange hardware and graphics settings. Remember that most people can simply degrade graphics via Spring Settings to boost performance but this does not work in reverse; you cannot make a crap low-res texture or model look better than it really is.

[lurker]

I believe compression is off by default.

One more note, an *actual* equation would be nice, but if you just want to make a list then PLUS the factors, don't multiply. Addition is vague when the units don't match and more or less correct. Multiplication is specific and misleading.

And if you're UVmapping every unit and you're not careful it's actually pretty easy to eat up texture space and cripple the game on certain cards.

[Argh]

The truth is it's highly probable, given an arbitrary set of textures and units, that the impact of changing the texture size will be close to nil.

Not so. There are other factors involved. Do some experiments, and use at least 100 units so that you can really start to see the load increase, when you go from 128 to 1024 skins. It does make a difference. IDK whether it's bus issues or fillrate, it's probably fillrate, but there is definitely a difference.

Is that difference nough that you shouldn't use 1024s on modern hardware, for a game that will be out in a year or more? No, not at all. Go right ahead. Be wary of 2048, though, that's more detail than you probably need and it puts low-end systems 100% out of the running to play your game, whether or not their CPU can handle it.

But. And this is the big 'but'.

Do you need it? Can people actually see all this detail? If not, you're just wasting processing power.

It's like putting huge amounts of uv space on the underside of a robot's foot. It's a pointless waste of resources. If you're serious about game design... keep in mind that what people will see largely reflects their distance from the action and the size of the characters. If there's anything about P.U.R.E. that I regard as a problem, it's that, by forcing the POV so far out, it really detracts from the details, and I intend to fix it in future versions.

I doubt if many of the skins in StarCraft II are over 512, and we know that Blizzard isn't manned by idiots. And their polycounts aren't earth-shattering, either. And they use a fixed-position, fixed-perspective camera that can't zoom out a lot by default, last I checked. So, since we know they aren't stupid, and that they make incredibly well-polished games... it might be worth reflecting on this issue. People here want to argue about individual models' tricounts... meh, please, learn to think about your total scenes. Especially if you intend to deliver anything remotely comparable with a commercial game's level designs, where just having a plain-jane map without lots of doodads and features is totally anathema.

If players are mainly going to be zoomed-out most of the time, seriously consider your polycount in terms of how many objects you want on-screen in a typical scene, and the costs for them, and how much of it is actually visible. If you lovingly model tiny rivets on the hull of your Uber Ironclad Steamtank, but the rivets are, at best, one-pixel dots... shouldn't you have just used a normalmap? In my experience, that's an overwhelming "yes".

[smoth]

well weapon ranges do have a large effect but I find that "medium range" weapons, are what determine view distance. All games have units that can strike from off screen. However, the majority often has a specific range.

[Argh]

Yeah, I set "medium range" to about 1000 originally, and it's about twice as far as it probably should be, imo. Lowering it detracts from the "epic" feel, but after finally getting around to playing SupCom, and seeing it from a fresh perspective, I am no longer convinced it was a good goal. That, and a lower camera, plus P.O.P.S., if I can ever get it running on ATi, and a LUPS variant for ground plates with normalmaps I have half-finished, will mean a lot better total performance, and then I can raise polycount on scenery without really getting stressed about it.

[SpliFF]

I'm still not buying it. When zoomed out your mipmaps and distance filtering should be kicking in so there's no reason you can't have a high-res texture for when the player does zoom in (and for youtube movies etc.).

If your mipmaps are wrong, misconfigured or just broken then that's another issue.

I'm going for 1024x1024 myself, I just don't see textures OR polygons as being a serious issue anymore. Shaders, shadows, bumpmapping, particles and dynamic lighting/reflections on the other hand is where I expect low-end GPUs to choke; but since these can be turned off I don't expect GPU optimisation to be a high priority for me. On the other hand I'll be using Lua aggressively so I'll be watching widget/gadget performance carefully.

Yes I need to run benchmarks so I don't claim to be right. We're also talking at cross purposes because noone has really defined what GPU models we're talking about when we consider 'low-end' and 'minimum specification'. I for one won't be losing any sleep when my game croaks on a TNT, RageXL or onboard All-In-Wonder. I believe a GeForce 4MX 64M is a pretty generous minimum (should be playable with shaders off).

[Argh]

I consider my GPU, a 7800GS with 384MB of VRAM on AGP, as my "low end". I figure that if my machine's creaking, then it's probably tolerable on a 9800GTX or higher GPU, which is more-or-less in the midrange.

Anything that can't handle DirectX 9.0 spec is pretty much not worth considering, they know they can't play new games. I was told I was being a dick when I defined that as the goal 2 years ago, and people with slow machines moaned... now I sound like I didn't predict far enough ahead. That's one of the reasons I'm kinda dubious about pushing "next-gen" super-hard, tbh. If you push too hard, you build a Crysis, which nobody can really play until 6 months into its sales cycle. With a free mod, though, who cares?

But wherever you want to set your bar, go right ahead. I don't see the point in 5K guys with full shaders, myself, except for special cases like fur or whatnot, because in a RTS there's a point where the details aren't even visible anymore. If I was going to spend the extra geometry past about 2-3K anywhere, I'd spend it mainly on having sexier scenery- buildings with modeled window panes, that kind of thing. Small amounts of extra triangles per thing, big improvement in total verisimilitude.

Shaders, shadows, bumpmapping, particles and dynamic lighting/reflections

Shadows aren't a significant slowdown atm. They have borked projections, but they're fast. I wouldn't worry about them, unless you're planning to do soft shadows via GLSL or whatnot.

Reflections are just a multiple of whatever load you have up to the point you generate them.

"Shaders" is an incredibly mixed bag- they're whatever load you want them to be. Suffice it to say that no matter where you go on that, you eat CPU and GPU more or less in proportion to the triangles and textures you want to push through the equations.

Particles is a whole different topic, frankly.

I'm writing P.O.P.S. to deal with some of the issues, and LUPS can do some very nice stuff, but I think CEG is dead, and I won't be developing any more CEG if I can help it. It's a tech that had it's day, but it can't really go anywhere useful until it's no longer fixed-function and allows shaders to alter particle behaviors, but that's not big news.

Dynamic lighting's cheap for one Unit, but if you want dynamic lights that effect map geometry and everything else around, that can get expensive; there are various techniques for getting around that cost.

And I have no idea about the whole stuff about new cards and big textures. Fillrate's a problem mainly of filtering; a giant texture may have a lot of pixels that are all sharing the same texel at any given mip, so they need to be filtered, and that can't really be avoided. At any rate, I think 1024's are totally fine, I used them on a few things in P.U.R.E., and their impact on performance was totally acceptable.

[Forboding Angel]

There are people trying to play runescape in the US with 32mb of ram on machines they've just bought that are the best they can afford.

How is this not bullshit? You can't even find computers nowadays in stores with less than a gig of ram.

[Neddie]

There are people trying to play runescape in the US with 32mb of ram on machines they've just bought that are the best they can afford.

How is this not bullshit? You can't even find computers nowadays in stores with less than a gig of ram.

You can still find $400 laptops with two sticks of 256 MB as of July. Three ways screwed... overpriced, no memory, and both slots taken up by useless modules by default.

[bobthedinosaur]

.

[Forboding Angel]

I'm going for 1024x1024 myself, I just don't see textures OR polygons as being a serious issue anymore.

Believe me, if you get more than 20 units in that game with textures that large, you're asking for big trouble.

[Gertkane]

I'm currently running a GF 8800GT and it handles all modern games including Assassins Greed, Crysis, Dirt and Medieval TW2 at high settings without noticeable stutter. By the time i'm ready to release Metalstorm (sometime next year i'm guessing) this card should be available in bargain bins for less than $30 US, about half what I'll typically spend on a night out drinking or dinner at a restaurant.

Nice speculation. Even old 7800GT-s run for like 60-100$ right now, new 8800GT-s run for ~250-280$ and to say that they will be 30$ (even considering bargains) in a year is to say i do not want to do price research. At all. x800 are more or less always high end and very pricey and the average gamer usually ends up with a x600 if going for nvidia.

[aegis]

usually ends up with a x600 if going for nvidia.

thought you were talking about ATI until I re-read that a couple of times...

[rattle]

ice speculation. Even old 7800GT-s run for like 60-100$ right now, new 8800GT-s run for ~250-280$ and to say that they will be 30$ (even considering bargains) in a year is to say i do not want to do price research.

9800GT is at 90 to 150 USD, depends on make and model