<shrugs> If you, or anybody else, wants to provide actually-useful information, be my guest.
Honestly, I don't think you know enough about rendering to do so, and I'm puzzled why you flame things you don't understand. I can understand why people like jK want to holler, but frankly they aren't providing any information to the nub-level folks, so you're stuck with whoever will actually try.
At any rate, at the end of this, I'm posting whatever article results and I'll sticky it... so, if you actually want to contribute, do so. But if you want to have a flamewar with me about this stuff, forget it.
I'll just refer nubs to my article, and if people post constructive ideas about how to improve it, great- then whatever horrible Argh-isms are in it can be eradicated by Truth. Fair enough? You can't shut me up, but I certainly promise to make the article the best source of information it can be... if people have something serious they'd like to contribute.
So, if you want it to be accurate and complete... contribute something positive for a change. You can't "win" by flaming, though. It helps nobody, and just makes us look bad. If you have better information, by all means
share it. That's how to actually improve people's knowledge. Not by tearing me down. Not that I expect that saying so will help, since it really appears that we're due for another totally-pointless hate-on-Argh session no matter what I say, but hey, the door's open here, maybe we can do something new for once, instead of killing another thread without actually helping anybody at all
So... back to basics. Here are the things I have observed in many tests:
1. Raw Polycount: minimal effect on total rendering time to severe, depending on other factors.
Saktoth's demonstration shows it pretty clearly: raw geometry throughput is not what gives your GPU a workout.
However, when trying to work out what geometry limits you want in a given scene, please remember, the Spring reflection code re-draws a lot of geometry, so you're talking about everything getting re-drawn several times.
Basic rule of thumb I'd like to propose is that geometry complexity should never be more than maybe half of the capacity of the hardware you're aiming for, to allow for time for other computation to occur. Just because your GPU can do millions of triangles per render pass doesn't mean that's free and doesn't compete with other things for clock-time. Feel free to ignore that, but be aware that that may keep you tied into inferior shaders when better ones become widely available.
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.
One handy idea is to build your own atlases wherever it's practical, it's usually faster to load one big texture than 4 smaller ones. That's frequently just not practical, given our typical workflow, but it does work and I've used it quite a bit.
3. Shaders: minimal to severe impact, depending on the complexity of the shader and the Lua operations needed to get the geometry ready, if any.
Shader instructions aren't free; they can become quite expensive, depending on what you do, and how you do it.
If you're just using the ARB shaders (Spring's stock rendering system) then one handy hint to keep in mind is that that shader expects input from both tex1 and tex2, and while performance is increased by not having a tex2, the final fragment results aren't pretty. If you want a fast result and don't need tex2, use a very small tex2 instead of none at all, and re-use that texture all over the place.
4. Total texels: moderate to severe impact. You can observe this by getting really close to objects, or better yet, detonate a CEG with a huge particle that covers the screen.
Or observe what happens, in terms of rendering speeds, when you look straight down on a scene full of objects, as opposed to looking at it sidelong.
5. OpenGL setup on the engine side: minor to severe impact. Keep in mind, always, that rendering is not just miraculously happening on the GPU- the CPU's involved a lot as well. Models with more Pieces have to have each Piece oriented in world space- this takes time and additional computation. While this has no impact on the GPU side of things per se, it's an important consideration when designing your objects- sure, it may be cool to have 100 little segments that you've animated to do something, but are there better ways to do that, either with Lua and OpenGL or by re-thinking your concept?
All of the above are just rules of thumb, not absolutes.
I'm not trying to give people "rules" they must follow; that's totally pointless. I just want people to understand what's happening a bit more, and take care with their designs as they develop their game.
