Billboards are a means of supporting low end users incapable of rendering all the art at full effects.
Tbh why nobodies made a lua widget to generate these automatically for uber low end users....
Appropriate Polygon Counts for Spring
Moderators: MR.D, Moderators
Re: Random WIP
Automatic scaling for things such as textures or anything with details which will be reduced by more than 75% is terribly awful.
That said, the widget sounds good.
That said, the widget sounds good.
-
CarRepairer
- Cursed Zero-K Developer
- Posts: 3359
- Joined: 07 Nov 2007, 21:48
Re: Random WIP
Maybe use the radar icon and give it a small directional arrow indicating facing position.
Re: Random WIP
what like icondistance?AF wrote:Billboards are a means of supporting low end users incapable of rendering all the art at full effects.
Re: Random WIP
Indeed yes, only Im sure you can generate better imagery than those radar icons for up close
Re: Random WIP
yet the models are not where spring is tanking.
Re: Random WIP
even if they could run the models, they could not play in any game anyway. FFS af.
Re: Appropriate Polygon Counts for Spring
Wow, we're having an argument about something really stupid here.
Sigh. Sak, I apologize for providing stones to throw. I didn't understand your test conditions on the first read, and didn't realize we weren't looking at skinned geometry. After you skinned it, your numbers and mine pretty much showed exactly the same things, allowing for your much faster GPU.
For the rest of you, I'll write out how it works in a nice simple equation:
PerformanceCost = Texels * (textures * textureSize) * shaderComplexity * numberPieceTransforms
That is pretty much everything anybody needs to know, right there. There are some assumptions involved and the above is not intended to be mathematically accurate (piece transforms scale with geometry complexity, it's not simple), but unless you're a graphics programmer, it's really everything you need to be concerned about. Note that texels reflect both the number of vertexes (our obsession with polycount is well-founded, although poorly understood) and the raw screen-size of the Unit. A huge Unit with very low tricount still eats up a lot more texels than a small one with the same tricount, and will take longer to render to the buffer, although this is somewhat mitigated by depthtest, etc..
If you have a 10K triangle uber-mech with a 2048 skin and 100 Pieces by himself, it's fine. When you have 50K in assorted geometry with 30 512 skins, it's a lot slower than 5 of the 10K guys, because you're running a lot more textures through that GPU. It's just basic math, guys, no need to argue about it. What target you want to aim for is arbitrary- just be aware that there is no free lunch.
Sigh. Sak, I apologize for providing stones to throw. I didn't understand your test conditions on the first read, and didn't realize we weren't looking at skinned geometry. After you skinned it, your numbers and mine pretty much showed exactly the same things, allowing for your much faster GPU.
For the rest of you, I'll write out how it works in a nice simple equation:
PerformanceCost = Texels * (textures * textureSize) * shaderComplexity * numberPieceTransforms
That is pretty much everything anybody needs to know, right there. There are some assumptions involved and the above is not intended to be mathematically accurate (piece transforms scale with geometry complexity, it's not simple), but unless you're a graphics programmer, it's really everything you need to be concerned about. Note that texels reflect both the number of vertexes (our obsession with polycount is well-founded, although poorly understood) and the raw screen-size of the Unit. A huge Unit with very low tricount still eats up a lot more texels than a small one with the same tricount, and will take longer to render to the buffer, although this is somewhat mitigated by depthtest, etc..
If you have a 10K triangle uber-mech with a 2048 skin and 100 Pieces by himself, it's fine. When you have 50K in assorted geometry with 30 512 skins, it's a lot slower than 5 of the 10K guys, because you're running a lot more textures through that GPU. It's just basic math, guys, no need to argue about it. What target you want to aim for is arbitrary- just be aware that there is no free lunch.
Last edited by Argh on 21 Oct 2009, 07:53, edited 2 times in total.
Re: Appropriate Polygon Counts for Spring
so the bigger my textures are the higher my performance? AWESOME... so, I didn't know performance was a thing that could be quantified.Argh wrote:Performance = Texels * (textures * textureSize) * shaderComplexity * numberPieceTransforms
Re: Appropriate Polygon Counts for Spring
There, I've changed the term, since it wasn't readily apparent that we're talking about "performance" in terms of load. My apologies for being unclear.
Re: Appropriate Polygon Counts for Spring
Argh wrote:[arbitrary math symbols hot-glued to things that hurt speed]
Argh wrote:[multiplying texels by a definition of texel without clarifying]
Argh wrote:It's just basic math, guys, no need to argue about it.
Re: Appropriate Polygon Counts for Spring
1+1=-3PerformanceCost = Texels * (textures * textureSize) * shaderComplexity * numberPieceTransforms
Re: Appropriate Polygon Counts for Spring
Yes, yes, the math symbols are all just there for emphasis. There's no compact way to show the real math without going into territory none of you guys are familiar with, and I am not interested in reading quibbles about my technical jargon.
I'm just trying to build a simple, easy-to-follow rule-of-thumb here for non-technical folks, not a thesis. Even including "texels" is really questionable, tbh, because artists don't ever think about texels, they think about triangles and quads. But I thought that explaining that the raw size of the final object on-screen has a relationship with how it performs might be useful, so there you go.
If you'd like to build an alternative description of the relationships, folks, by all means do so- if the description is unclear or doesn't seem to fit, by all means, show us another theory, or re-write mine
But it's not "helping" anybody, if you're just trolling me about minor semantics. You all understand the basic concept of what I'm explaining here. If it's poorly written for newbies, then let's get it written in a simpler way, and write a good article about this, it's a lot more useful than a flame war over something that most of us understand fairly well. Then we have something that we can sticky somewhere and refer people to.
I'm just trying to build a simple, easy-to-follow rule-of-thumb here for non-technical folks, not a thesis. Even including "texels" is really questionable, tbh, because artists don't ever think about texels, they think about triangles and quads. But I thought that explaining that the raw size of the final object on-screen has a relationship with how it performs might be useful, so there you go.
If you'd like to build an alternative description of the relationships, folks, by all means do so- if the description is unclear or doesn't seem to fit, by all means, show us another theory, or re-write mine
But it's not "helping" anybody, if you're just trolling me about minor semantics. You all understand the basic concept of what I'm explaining here. If it's poorly written for newbies, then let's get it written in a simpler way, and write a good article about this, it's a lot more useful than a flame war over something that most of us understand fairly well. Then we have something that we can sticky somewhere and refer people to.
Re: Appropriate Polygon Counts for Spring
No, we're stopping you from spreading false information.But it's not "helping" anybody, if you're just trolling me about minor semantics. You all understand the basic concept of what I'm explaining here.
Re: Appropriate Polygon Counts for Spring
<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.
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.
Re: Appropriate Polygon Counts for Spring
EDIT: Crap, beaten to the post by Argh's giant wall of text.
I totally agree with smoth.
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.
I think it's fair to say anybody who is even moderately serious about PC gaming (as apposed to those who play Hearts/Minesweeper exclusively) will have a card at least this good by the end of next year. Those who don't can just crank Springs graphics settings down.
By that time DX11 games will have raised the bar again and games with low res textures and polys will quite likely be a turn-off for many new players. Keep in mind that while Spring might be free you'll probably be able to pick up a 'red hot / platinum' release of Supreme Commander for around $10 USD. That's what Spring games are competing against (at least on windows).
I started down the low poly path but quickly realised that graphics performance is not where Springs bottlenecks are. With shadows, reflections, lups and bumpwater off anybody with a GeForce FX (about $10 USD) or higher will most likely be suffering from network lag and pathfinding overhead long before overrunning the limits of PCIe (even AGP) or the GPU.
People who think crap graphics are ok should try Warzone2100. This (now free) game was written around 1994 and the dated graphics really diminish what is otherwise an excellent game.
I totally agree with smoth.
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.
I think it's fair to say anybody who is even moderately serious about PC gaming (as apposed to those who play Hearts/Minesweeper exclusively) will have a card at least this good by the end of next year. Those who don't can just crank Springs graphics settings down.
By that time DX11 games will have raised the bar again and games with low res textures and polys will quite likely be a turn-off for many new players. Keep in mind that while Spring might be free you'll probably be able to pick up a 'red hot / platinum' release of Supreme Commander for around $10 USD. That's what Spring games are competing against (at least on windows).
I started down the low poly path but quickly realised that graphics performance is not where Springs bottlenecks are. With shadows, reflections, lups and bumpwater off anybody with a GeForce FX (about $10 USD) or higher will most likely be suffering from network lag and pathfinding overhead long before overrunning the limits of PCIe (even AGP) or the GPU.
People who think crap graphics are ok should try Warzone2100. This (now free) game was written around 1994 and the dated graphics really diminish what is otherwise an excellent game.
Re: Appropriate Polygon Counts for Spring
Argh, you are trying to put in as much detail into your post to help the noobs.
This results in great big long walls of text.
Most noobs skip great big walls of text
A lot fo what you say can easily be condensed to say exactly the same thing while having a wordcount thats a mere fraction of the original. Write your post then go over it and rephrase to be more concise, it will make you easier to understand, more accurate, fewer mistakes, and more likely to be taken seriously.
This results in great big long walls of text.
Most noobs skip great big walls of text
A lot fo what you say can easily be condensed to say exactly the same thing while having a wordcount thats a mere fraction of the original. Write your post then go over it and rephrase to be more concise, it will make you easier to understand, more accurate, fewer mistakes, and more likely to be taken seriously.
Re: Appropriate Polygon Counts for Spring
While I can understand what you are saying argh about the processing steps necessary for textures, polies and the shaders applied. I am unsure if you are correct or incorrect and I generally do not take information at face value. However, your longer post is much clearer.
I do not really worry about the gpu as there are so many other areas where spring CHOKES. At the rate those issues are being addressed it will be 2010 before then. Next year pc gaming will have moved so far beyond what we have now that it strikes me as asinine to worry so much about all this shit.
The other point of concern is things like using lua to implement shader systems probably is not much slower than the current shader system due to the fact that lua works based on callins I suspect it really isn't that big a hit if at all. I would say that with confidence but I have not bothered to understand the lua system enough to go beyond conjecture.
I do not really worry about the gpu as there are so many other areas where spring CHOKES. At the rate those issues are being addressed it will be 2010 before then. Next year pc gaming will have moved so far beyond what we have now that it strikes me as asinine to worry so much about all this shit.
The other point of concern is things like using lua to implement shader systems probably is not much slower than the current shader system due to the fact that lua works based on callins I suspect it really isn't that big a hit if at all. I would say that with confidence but I have not bothered to understand the lua system enough to go beyond conjecture.
Re: Appropriate Polygon Counts for Spring
"none of you guys are familiar with" Haha, try me.
You have a perfectly fine list of various things that take power, you just need to not put it in false-equation form; that only makes it more complex and less accurate. I simply feel a need to correct that point before somebody follows it and spends time on an optimization that barely works.
You have a perfectly fine list of various things that take power, you just need to not put it in false-equation form; that only makes it more complex and less accurate. I simply feel a need to correct that point before somebody follows it and spends time on an optimization that barely works.