Maximum Polygon Limits

[Sonic TH]

Forgive me for being lazy but I found myself wondering something and couldn't find the exact answer in the forum, so I thought I'd just ask:

What is the MAX polygon limit for vegastrike? I know "use good LODs" but I mean just how many polys can be rendered at once engine wise.

Now as opposed to when the ogre port is finished?

And what is the limit of what the code can handle? I know it depends on hardware of course but assume you have unlimited hardware, what are the internal limits of the game/graphics engine?

[klauss]

And what is the limit of what the code can handle? I know it depends on hardware of course but assume you have unlimited hardware, what are the internal limits of the game/graphics engine?

None.

If you assume infinite hardware capabilities, you can have infinite polygons onscreen at once, at an infinite framerate.

[Sonic TH]

Well I meant graphics card wise but ok. So you don't know then? Like in wing commander for example, after a certin number of ships are in the same area the game starts to slow down. I have way surpassed the specs that game was designed for but there are still internal limits.

[klauss]

No... those are still hardware limits.
Slowdowns are always hardware limits.
Whether an engine is designed efficiently enough to make the most of a certain hardware setup is a different matter.

Engine limits are... for example... when the engine can't and won't handle more than N ships, and will crash if you force it to - or when its systems can't be bigger than X, and trying to place a unit outside those bounds creates unexpected behavior or crashes. Those are design limits, and not performance related.

The VegaStrike engine has none of those - there are lots of design limits in many aspects, but not in system sizes or unit numbers.

Now... if you want to know how performance decreases with increased number of units, the physics simulation is the key in that aspect - not graphics.
Graphics rendering increases linearly with the number of visible ships on screen. You can't do better than that, so in that aspect you can say the engine has no limits (well... it's a tricky issue, because each asteroid in an asteroid field counts as a unit, but it could be done otherwise and further increase efficiency - but... theoretically proven... linear is as fast as you can get - you can only do minor tweaks... more or less efficient in certain conditions).
Physics, however, do not always increase linearly. Right now, I think, simulation time grows mostly as O(N log N) in the average case, but worst cases tend to go to O(N^2), which is bad. Experimentation, though, has proven that the average case is indeed significant (ie. - that it happens most of the time), making the engine able to work with close to 5000 units at a sutainable framerate of 4FPS in bad conditions (all units close together and mostly visible), with performance increasing to much more acceptable levels (20FPS last time I tried, but may have changed) in better (and more realistic) circumstances.
So... although there is much room for improvement, again, there is no limit, if you don't specify a subjective "quality standard" - how bad a performance in what kind of hardware are you willing to accept. If you suppose unlimited hardware, you can always improve performance, and so you don't have any true limitation - if you want limits, you'll have to specify hardware specs, because otherwise it is a provably unlimited engine.
All that, actually, means: do the test - I did the test on my machine, and got acceptable performance with 5000 units spread around the entire system - probably some left the system as well (20FPS).

[Sonic TH]

What I'm wanted to do is a story based on asteroid mining and thus would have alot of objects around the player at all times. Mainly I just wanted a "don't make things over this number of polygons" rule of thumb. I would say at the moment things are between 4000-10000 for complex objects. Of course it's fine at a low LOD but I'd rather the roids looked as real as possible. I guess it would depend on ogre itself aswell as vegastrike but I didn't know how much VS would take advantage of memory.

I didn't mean to bother you, I didn't phrase my question very well.

I guess I'll aim for 4000-6000 (for ships and bases) and let the textures and normal mapping do the work.

[Ryder P. Moses]

Asteroids don't take much to look passably realistic and detailed. They're all texture.

Around 1000 (polys, not tris) is the standard I've been using for small ships and detail stuff like that, and about 4000 for larger ones (small capships, say). Supposedly there are ships ingame now that run as high as 20,000 polys, and if you're not having much else around 200,000 is doable- if you've got that high, though, you're either going epic or really wasteful.

[klauss]

I didn't mean to bother you, I didn't phrase my question very well.

No prob. It's just that your question, phrased as it is, is rather impossible to answer. There's no strict limit, it all depends on the expected FPS on a certain system. The best you can do is do benchmarks yourself, on your own system.
There are some rules to follow, to make the most out of your models (you have to follow them, not the engine) - they're in the wiki, but apart from that...
Also, pay attention to what Ryder said. Asteroids, for instance, can look amazing with proper use of texturing (including normal maps and special shaders). You don't need that much geometry, but the problem you'll encounter is batching: having many units visible at a time will kill your GPU drivers, because that'll make the driver work harder than the hardware itself to send the commands. You may either make one mesh with many asteroids in it, so that they're not discrete units, and so are sent to the hardware all at once (or maybe we can do that automatically in the engine - but that's not done right now).

[Zeog]

Just a remark:

..., but worst cases tend to go to O(N^2), which is bad.

O(N^2)? Hahaha... O(2^N), this is worst case! Everything that scales polynomially is good.

[klauss]

@Zeog:
It is actually pretty bad for this kind of thing.
Well... there's no method that I know with a worst case <O(N^2), but there are some where they have to be in pretty much impossible situations to get to the worst case.
But if you sistematically reach the worst case often, yes... O(N^2) is really bad. Because with 5000 units, N^2 = 1351*(N log N) (that's 1351 times slower!). So, if you're happily at 30FPS, and suddenly enter a bad state of things where the algorithm performs badly, you find yourself with a large hiccup (.01FPS). Actually, it doesn't have to reach the worst case, though. With approaching it, is enough to make things unacceptably bad.

Now... if it were a number factoring algorithm what we're talking about, I would be more than happy with polynomial time

[Sonic TH]

That's a good idea having the roids as one object, hmm.