Appropriate Polygon Counts for Spring

[hamsate]

oh also poly count is 2693.

Just curious, does such a high polycount (or tricount) have a noticeable impact on the game? I've heard that it was best to always keep it below 1000. Does it mean we're able to go higher?

[smoth]

oh also poly count is 2693.

Just curious, does such a high polycount (or tricount) have a noticeable impact on the game?

This isn't that high. Also it is a unit that is only allowed one per player.

I've heard that it was best to always keep it below 1000.

From whom? on some simple piece of shit, sure. Most of the tanks and shit shouldn't really exceed a lot of polies no but something humanoid and that large can.

Does it mean we're able to go higher?

no one said you could not.

[Saktoth]

This is the 'Thorn'. My new unit for CA. Pretty neat huh?

Its that complex all the way through. It is 35,951 polygons. Note the FPS: 60.

This is 200 thorns, for 7,190,200 polygons. Note the FPS: 33. I chose 200 because at 100 thorns, or 3,593,100 pollies, i was still at 60 FPS. This is with reflections mind!

So i guess if you're not exceeding seven million polygons, you should be alright.

Okay, so some people will have worse hardware, but for a 1-time unit, i suspect you could afford 100,000 polygons before anyone started to suffer from it. Its no excuse for sloppy modelling though.

[Argh]

Run that test, with reflections and shadows on. No offense, but I don't develop games that have to run on Super Ugly Mode to run fast, and reflections are the killer.

[Neddie]

This is with reflections mind!

He has that, at least, though I don't see a reflectivity map reflected in the appearance of the units and thus am unsure that there would be a performance cost.

[Saktoth]

Yes thats reflections: the unit has no texture, the light/dark you see is purely reflections.

So lets try with shadows on.

15-17 FPS with 200 thorns, thats 7 million polygons.

21 FPS with 200 spherebots (1k polies each, for 200,000 pollies).

30 FPS when looking at blank terrain at max complexity, up to 60 if i lower the viewdistance.

15 FPS with 1494 janus, a unit with ~120 pollies, for 180,000 pollies.

Of course if i try and move that many units my game lags to less than 1 FPS.

Your results may vary, your hardware may be different. So test it yourself. Though i can tell you, with my old hardware i would avoid playing with reflections or shadows on even in BA. If you're making the game for someone who can play with reflections and shadows on (like me), then i would suggest polycount is not a problem.

I used to worry about polycount too, until i was reminded that at a high view distance the terrain renders millions of polygons on screen at once. When presented with such a blatantly obvious truth, i was forced to change my opinion.

[Argh]

Were shadows on?

I mean... I'm going to leave CPU load and total GPU throughput issues aside (although it's a big problem- mix 200 spherebot variants, you'll see performance is ever-so-slightly lower).

And put... hrmm... a 256 skin on the thorns, both tex1 and tex2. I mean seriously... texture throughput is not a joke, I've done some tests of that, on my decidedly non-leet hardware, and found that for common stuff, it can be a very big deal.

All that said, it sounds like your hardware's so much faster than mine that it's comparing apples with Buicks. I build my game with the expectation that if it won't run reasonably (i.e., no worse than 10 FPS) on my machine, with all the pretty stuff on, then it's not running well enough to ship to total strangers. It's a fairly loose rule of thumb, though- a couple of the city maps in P.U.R.E., especially Oceanside, kill my box once combat gets thick- even water 0 performs pretty abysmally over here (which is strange, since I've played many other games with water where it works ok, but I've never had time to look into it). But that's the goal, and tricount certainly matters there.

[Saktoth]

Of course, the numbers are half that without shadows on, so yes, thats with shadows on.

But go on, try it with a massive messy mash of polygons yourself. See if polycount is really your bottleneck or not.

Also: SURE ill uvmap that! Shouldnt be too hard.

[Argh]

My normalmap-test spheres are 8K apiece. Let's see.... 100 of them, merely performing one rotation operation and the GLSL light shader (another redraw of the triangles, because it isn't additive lighting) == 13 FPS. Don't even ask what the results are, when I turn the boomski code I built for whenever P.O.P.S. is actually done back on- it's lucky that Spring doesn't crash, it's so slow, because of the additional CPU that's getting eaten.

Put it another way: in isolation testing, P.O.P.S. ran well with 65K point objects, but began to seriously choke when it got squared again- shader instructions finally piled up.

Units are really hard to judge, because they seem to be fine until you give them orders and the CPU isn't free to deliver geometry and textures as fast, then it all gets mucky fast. A Feature with only a root Piece and 10K triangles probably performs very nicely- a 10K robot with 50 Pieces doing a walk cycle... not so much.

All that said, most of the time, P.U.R.E.'s CPU-bound. I am hoping that by the time I finally release the next version, it will be optimized enough that this is less of a concern.

[Saktoth]

Adding a texture really does change things. A 512x512 texture with a 32x32 reflection map on a 30k polygon sphere, i get 20 FPS with 60 of them. Moving them around causes no framerate drops, but they are gunships with no animation.

That IS 1.8 million polygons. I still think the lesson to take away from this is to not be too conservative with your polygon budget, especially if you are making your game for current-gen hardware.

If some mod wants to fork this properly into a polycount discussion thread that would be swell.

[Argh]

Just be aware... most people, including most gamers, don't have current-gen hardware, and won't until the economy gets better. Look at the polycounts in StarCraft II, for example- they're sitting around 1.5K per unit, not a whole higher than the standard I set for P.U.R.E., with a few exceptions for things that aren't seen a lot, like their buildings, which are probably closer to 3-5K. Buildings, especially major ones like factories, are a safe place to spend triangles, just like unique heroes or superunits. You can very safely have a 10K Krogoth model on this engine, that's not a serious problem at all.

Also, just another bit- when everybody gets into advanced Unit shader stuff, which I would imagine will be fairly soon... the extra texture throughput is a big factor there, as are the extra shader instructions. That's why I presented my results with my 8K spheres- that's a full normalmap, glow, reflectivity, TC and translucency operations, and involves three different 512 bitmaps. It gets painful fast. Spring needs better overall handling of textures at the engine level, if that's possible- it would be nice to quit re-sending textures every render cycle and just store them on the GPU if it's not already maxed out- but the bus throughput involved is just one of many factors involved (Pieces add a lot of CPU time, since they all must be transformed on the CPU in Spring atm, amongst other issues).

[rattle]

This the 'Thorn'. blah blah

are you trolling or serious?

[Saktoth]

This the 'Thorn'. blah blah

are you trolling or serious?

I am always serious. It is a new unit, the Arm version of the krow. Only it will roll around on the ground like a tumbleweed and the direction it moves will be determined by the wind direction, and the speed by the wind speed. It will shoot a laser at a fixed angle from each of its little arms with 9001 range. All at once. So its balanced because it kills everything, right. But it also kills you.

[bobthedinosaur]

,

[Saktoth]

Isn't that a lot of wasted poly? You can make the same damn thing with 1/10 or even less, you wouldn't even be able to tell the difference unless it was at point blank zoom.

Yes of course it is because this is a real unit in a really true actual game i am making and not at all obviously a stress test of the Spring engine.

[smoth]

so you make your game, which will take years to finish, and you make it with most of your consideration for what is now low end hardware.

then years from now when your project is finished, you have to redo the whole thing to look better.

Sure on a game that you plan on releasing within the year you want to have it run on current machines but you also need to be forward thinking.

Arguing that it runs poorly when running your gl code just makes your gl code sound bad. Sure it isn't an issue with poorly optimized code and/or using the gl functionality in a less than optimal manner?

Sak, the point is still proven. However, in spring games typically run from 1v1 to 4v4 to 8v8(rarely) so when you consider 16x 500~ it is pretty crazy but then again, spring has other things that tank our fps.

I am itching for beherith's roam code to be completed.

the point still stands that wise poly usage is better than just burning up your poly budget on areas of poorly optimized geomitry. Just because the budget is high doesn't mean modelers should not try and scrape for some extra polies here and there.

[AF]

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.

[smoth]

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.

that is irrelevant, such a machine cannot run spring anyway.

you cannot develop a game with the main focus being on low end hardware, it is dead from the start. Unless we are talking consoles or cellular phones which we are NOT.

[AF]

In 5 years the people playing spring on low end hardware now will still want to play your game.

You can implement shiny new graphics for better hardware but that doesnt mean you have to leave behind the lower end, if anything a scalable setup exposes you to a maximum audience and a better setup. No reason you cant swap out your 32k poly textured models and shaders for billboarded renders on quads or low poly untextured versions

[smoth]

In 5 years the people playing spring on low end hardware now will still want to play your game.

yeah all things considered, gundam rts will probably still be played at this point.

You can implement shiny new graphics for better hardware but that doesnt mean you have to leave behind the lower end

No, it means exactly that, this isn't a line in the sand. Doom can run on those machines but spring will never run on those machines. The cpu requirements alone for spring locks out said low end players. Also these low end players you talk about, the can barely play more than a 1v1. Which most of the time they lag out due to their fail machines.

if anything a scalable setup exposes you to a maximum audience and a better setup.

no, scalable doesn't exist for spring or any real modern game. C&C 3 cannot run on those machines either, so take that weak argument and drop it.

No reason you cant swap out your 32k poly textured models and shaders for billboarded renders on quads or low poly untextured versions

We are not talking about 32k models, lod can double and tripple the work. Billboards are not the realm of the artists.

drop the argument, the art we create has little to do with the high base requirements of spring. There are many other areas where spring eats power from. So no those machines are not even in the realm of consideration for runing a 4v4 with low poly shit. So no the art is not the limiting factor.