Oups, too many Poly's?

[Peet]

[[Krogoth86]]

I think this has become the right place to ask...
When considering the polycount shouldn't you also consider if it's going to be a tank or a KBot? The reason behind this is that as I see it there is no real Hardware T&L in Spring as it was developed towards OTA. This way the animation is done via a ... well kinematic approach that is done via script and I think in the end it's the CPU which has to do the real animation. Usually this all is done via keyframing or using bones (in more modern games). So this way I could imagine that if you have a KBot that has to move his legs all the time will eat up much more CPU power than a tank who is just moved around like a brick and just has a moving turret on top...

At least I believe the animation script is not converted into actual keyframes as if this would be so you wouldn't be forced to use such scripted animation in the first place. But as this is the case I believe the animation work is done by the CPU and if you now are going to push the polycount higher and higher this might become a bottleneck pretty fast. Maybe someone can do a statement on this...

[KDR_11k]

The reason behind this is that as I see it there is no real Hardware T&L in Spring as it was developed towards OTA.

Do you have any idea what you're talking about? Hardware T&L means the matrix ops and the lighting calculation are done in the GPU, skeletal animation is not part of the GPU fixed function pipeline and is usually done by the CPU, you can use a vertex shader but with Spring you'll have many users without the prerequisite shader hardware.

[rattle]

When considering the polycount shouldn't you also consider if it's going to be a tank or a KBot?

Remember: there are no kbots outside of TA. And no, you shouldn't.

All the tanks I've done run as many endless loops as any bipedal units I wanted to do but never got to. It will be a constant stream of object movement on either end.

[[Krogoth86]]

Do you have any idea what you're talking about? Hardware T&L means the matrix ops and the lighting calculation are done in the GPU, skeletal animation is not part of the GPU fixed function pipeline and is usually done by the CPU, you can use a vertex shader but with Spring you'll have many users without the prerequisite shader hardware.

Since the introduction of Hardware T&L you are able to do keyframe interpolation on the GPU (found an old german article HERE). As this is just scripted in Spring it's not done this way but via the CPU. That's the whole point I made...

In order to do skeletal animations on the GPU you'll need shaders - that's why I said that this is done by modern games...

Remember: there are no kbots outside of TA.

Well just anything with moving legs or something like that...

[Zpock]

You can use shaders with LUA, with a lot of work you could probably do skeleton animation.

[[Krogoth86]]

Well I'd prefer the ability to use good old vertex keyframe animations. That wouldn't just be faster than the scripted method but also easier to do as you have a visual feedback on what you do and even can use bones in order to actually to the animation and then convert it to a vertex animation...

Enginewise this also should be a more or less easy task - I don't know how OpenGL works this way and also only have extremely little knowledge about DirectX but there might exist a pretty basic command for this. I think modders really would like that but well - this is another topic I guess...

[Snipawolf]

Have you ever used upspring to animate, we have keyframes, but for objects only, not for verts.

[[Krogoth86]]

Well I was told that besides Servo which I digged up from old TA sites there is no animation tool at all and thus I thought the Upspring functions were not functional. But if you say they are I'm gonna test them - thanks!

Edit:
OMG - it really seems to work (though I haven't tested it in the engine yet). Thank you very much for this little hint!

[rattle]

Upspring has issues with certain angles. I do them manually anyway.

[Snipawolf]

Well, remember, you can't have negative speeds, and you have to delete the < and > off of turns. Moves are borked, I think, so you will have to experiment with your own settings there.

[Zpock]

Here's an example of when using more polygons can sometimes be wise, considering how shaders work, and vertex normals. It's about beveling, wich I think some people mistakenly think of as only a sign of the n00b.





When making flat surfaces if you use smooth shading you get the result of the furthest away cube. It looks like shit since the normals don't work out. One option is to set the edges to hard in wings, or split the polygons in blender. The final result is the same, you pay a hefty price, that is getting 3 vertices instead of one. This means that the second furthest away cube, using this method, isn't as efficient as you would think with a simplistic "as few pollys as possible" mindset. It uses 24 vertices, not just 8 like the original cube.

The next cube uses smooth shading again, with one simple wings bevel applied to the edges. The result actually uses exactly as many vertices as the flat shaded cube, 3 times as many, or 24 vertices. However it suffers from the same problems as the first cube, only much less.

To solve this you need to introduce extra cuts that only serve to fix the normals like in the closest cube. This again quadruples the amount of used vertices to 96 however. Depending on your specific geometry you may get away with less. Considering that flat surfaces don't need that many polygons to begin with, and that the result looks a lot nicer then flat shading in some situations, it's often worth it. You might also want to consider the added difficulty of UV mapping.

[Snipawolf]

Quite an interesting study.

[KDR_11k]

Zpock, careful, you can't just count the mesh vertices to get the vertex count. UV seams duplicate the vertices (and if you want to get a decent UV map of a cube you'll cut almost all edges anyway) and tristrips duplicate the vertices along their edges (it gets worse if the engine doesn't even do tristrips). There's no way to get the vertex count that goes through the bus to be the same vertex count you have in the object file.

[Zpock]

Zpock, careful, you can't just count the mesh vertices to get the vertex count. UV seams duplicate the vertices (and if you want to get a decent UV map of a cube you'll cut almost all edges anyway) and tristrips duplicate the vertices along their edges (it gets worse if the engine doesn't even do tristrips). There's no way to get the vertex count that goes through the bus to be the same vertex count you have in the object file.

Yeah good points. Of course the cube is just an example that has lots of corners and have to be UV mapped with seams all over, a real model would usually have lots of edges within the UV islands.

If the engine does lack tristrips you might as well flat shade everything, true. The question is then, if spring lacks tristrips?

My main point is that using smooth shaded rounded objects with more polygons isn't always as much less performance efficient as using flat shaded objects as you would think, considering the realism you get. There's no hard edges in the real world after all and the bevel often catches a distinctive highlight. Then you may factor in paying pretty much the same performance in fragments, and they could very well be taking up most of the GPU anyway.

[smoth]

that is all fine and good in an fps or in a rendered scene but spring is a game where most of the time our details are lost in the super high level zoom outs over battles

[Zpock]

I might add that beveling should probably only be done to the most prominent edges of the model, not so much details (except for exceptions), such as the main hull of a tank could very well use the double beveling I shoved to good effect. It is quite a lot of work to get it right (notice that you have to manually cut the inner squares, not use the bevel function) and UV/texturing is harder too so I really don't recommend overdoing it, not just for performance reasons. We should have LODs soon, then there is really no reason to not use more polygons within reason, as long as it makes the model look better.

Here is were I got the ideas, should be a bit more clear:

http://vegastrike.sourceforge.net/wiki/HowTo:Bevel

http://vegastrike.sourceforge.net/wiki/HowTo:Weld

Lots of great tutorials there, I recommend very much.