Texturing and impact on performance...
Moderators: MR.D, Moderators
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
Texturing and impact on performance...
Would someone go into detail as to how much s3o textures affect performance?
Well for starters, I can tell you that by using a tileset where many units share the same textures, it saves space, and alot of memory.
S3o just like any modern format, by using dedicated "per-unit" textures takes up alot more memory, even if you're using 128x128 or 256x256 textures per unit at 48kb, or 96 kb, you multiply that by how many units and you end up with typically much more loaded textures in memory as long as they're being drawn on screen.
As far as anything else goes, I'll leave it up to sombody with the "know"
S3o just like any modern format, by using dedicated "per-unit" textures takes up alot more memory, even if you're using 128x128 or 256x256 textures per unit at 48kb, or 96 kb, you multiply that by how many units and you end up with typically much more loaded textures in memory as long as they're being drawn on screen.
As far as anything else goes, I'll leave it up to sombody with the "know"
yea
Well, the texturing very well could be larger, but you are dealing with the fact you could use png, jpg, or dds for textures, versus only bmp's in 3do, with no triangle support. :O
Do 200 bmp's[32x32 to 512x512, max 2048x2048 of all textures]take more power then 200 png's[max 2048x2048 per unit.]?
Do 200 bmp's[32x32 to 512x512, max 2048x2048 of all textures]take more power then 200 png's[max 2048x2048 per unit.]?
Gfx's can't handle PNG natively, so DevIL converts PNGs into a RGBA struct, so it doesn't safe memory at all (also it stress the vram bandwidth). Only dds can be loaded as is into the vram, so those save memory. The best way would be if spring would compress all none dds textures on loadDo 200 bmp's[32x32 to 512x512, max 2048x2048 of all textures]take more power then 200 png's[max 2048x2048 per unit.]?
-
Forboding Angel
- Evolution RTS Developer
- Posts: 14673
- Joined: 17 Nov 2005, 02:43
With textures the problem is not slowdown due to content or size, but rather slowdown due to shifting textures in and out of video memory because the video card can't hold it all at once.
Once your dealing with regularly shifting texture data from video ram to system memory and back again it slows everthing down tremendously and holds up any other graphics commands beign sent across at the time.
So really memory space is the deciding factor. Detail etc are somewhat irrelevant save for how they affect memory usage. DDS textures would still be preferable as they remain compressed in video ram, and should be quicker to move between system and video ram due to their decreased size.
Once your dealing with regularly shifting texture data from video ram to system memory and back again it slows everthing down tremendously and holds up any other graphics commands beign sent across at the time.
So really memory space is the deciding factor. Detail etc are somewhat irrelevant save for how they affect memory usage. DDS textures would still be preferable as they remain compressed in video ram, and should be quicker to move between system and video ram due to their decreased size.
I agree, that it would be good if users could manually set which mipmap level was highest, for games using DDS textures with mipmaps pre-built. However, I think all RGBA stuff is being handled purely through OpenGL calls to MipMapNearest, not being handled by Spring in any really direct way. Therefore, it'd probably be a royal pain to get working.
As for performance... here are the factors...
1. Polycount.
S3Os are half the tricount when turned into tristrips than the equivalent 3DO, because they aren't rendered double-sided. However, that's less-meaningful than you'd think, because of the extra render passes, which require the engine to redraw stuff every time.
2. Render passes.
3DOs go through three render passes: 1 for diffuse, 1 for reflectivity, 1 for teamcolor. Reflectivity is user-controlled, so you can just have 2.
And 1 more if an object's geometry qualifies as being "round"- I'd have to go look up the default breaking angle to see when things are being made "round", but it's something like 45-30 degrees.
S3Os go through many more passes, being forced to use multiple rendering methods with "advanced shaders" on than they really should:
Diffuse
Reflectivity
Glow
1-bit alpha transparency
Teamcolor
Rounding
This is irregardless of whether the object has any transparency (i.e., objects with a pure ON / OFF state still go through that loop, IIRC) ... same with glow and teamcolor and reflectivity, and I forget whether rounding is checked per-pass, or when the object is first loaded....
At any rate, S3Os are a lot less efficient, and the size of the texture map makes a very big difference in how they operate. Every time your object runs through the engine, the texture's coordinates need to be projected onto the surface normals, and IIRC (OpenGL peeps, feel free to correct my ignorance) that's a pixel-based grid search. Then the pixels need to be displayed on the triangles. In short, the bigger the texture, the longer it takes to do the searches, which is why all of the experienced modelers are somewhat obsessed with keeping the size of the texture as low as possible.
For everything in PURE, I use 512 or 1024 skins. I should probably keep everything 512, but for some of the bigger objects, with a lot of details, it just didn't work out- in most games, they fudge around this problem using multitexturing, which Trepan said he'd deliver months ago... but based on the LOD post, he doesn't understand why it's important, because he doesn't know jack about modeling, or the crazy tricks we can do with multitexturing, and are currently forced to emulate in Spring with brute-force methods (uv cloning and mirroring)
As for performance... here are the factors...
1. Polycount.
S3Os are half the tricount when turned into tristrips than the equivalent 3DO, because they aren't rendered double-sided. However, that's less-meaningful than you'd think, because of the extra render passes, which require the engine to redraw stuff every time.
2. Render passes.
3DOs go through three render passes: 1 for diffuse, 1 for reflectivity, 1 for teamcolor. Reflectivity is user-controlled, so you can just have 2.
And 1 more if an object's geometry qualifies as being "round"- I'd have to go look up the default breaking angle to see when things are being made "round", but it's something like 45-30 degrees.
S3Os go through many more passes, being forced to use multiple rendering methods with "advanced shaders" on than they really should:
Diffuse
Reflectivity
Glow
1-bit alpha transparency
Teamcolor
Rounding
This is irregardless of whether the object has any transparency (i.e., objects with a pure ON / OFF state still go through that loop, IIRC) ... same with glow and teamcolor and reflectivity, and I forget whether rounding is checked per-pass, or when the object is first loaded....
At any rate, S3Os are a lot less efficient, and the size of the texture map makes a very big difference in how they operate. Every time your object runs through the engine, the texture's coordinates need to be projected onto the surface normals, and IIRC (OpenGL peeps, feel free to correct my ignorance) that's a pixel-based grid search. Then the pixels need to be displayed on the triangles. In short, the bigger the texture, the longer it takes to do the searches, which is why all of the experienced modelers are somewhat obsessed with keeping the size of the texture as low as possible.
For everything in PURE, I use 512 or 1024 skins. I should probably keep everything 512, but for some of the bigger objects, with a lot of details, it just didn't work out- in most games, they fudge around this problem using multitexturing, which Trepan said he'd deliver months ago... but based on the LOD post, he doesn't understand why it's important, because he doesn't know jack about modeling, or the crazy tricks we can do with multitexturing, and are currently forced to emulate in Spring with brute-force methods (uv cloning and mirroring)
TBH, I don't know what to call it- it's the "fragment program" stuff that handles reflectivity, which also tesselates objects where vertex angles < Y. Gourad shading is just a drawing method- this is actually re-tesselating things.
I'd need to look at the code again, though, to see whether it does it only once, when the S3O of whatever type is loaded into memory, or every render pass, or whatever. The long and the short of it, though, is that the reflective shader, which also turns on the rounded effect on S3Os and 3DOs, is using far more triangles than the object had originally- it's SJ code (I think- then JC ported it to S3O, correct me if I'm mis-attributing), and insofar as I can tell, it's related to the tesselation methods used for the dynamic water, where a low-poly mesh is tesselated and made more "round" around areas of disturbance in the water- which is why it's always been the ultimate stress test of Spring rendering
I'd need to look at the code again, though, to see whether it does it only once, when the S3O of whatever type is loaded into memory, or every render pass, or whatever. The long and the short of it, though, is that the reflective shader, which also turns on the rounded effect on S3Os and 3DOs, is using far more triangles than the object had originally- it's SJ code (I think- then JC ported it to S3O, correct me if I'm mis-attributing), and insofar as I can tell, it's related to the tesselation methods used for the dynamic water, where a low-poly mesh is tesselated and made more "round" around areas of disturbance in the water- which is why it's always been the ultimate stress test of Spring rendering
(fragment programs cannot tesselate, you're thinking of vertex programs)
Those "passes" are texture layers, they are not necessarily rendered in different passes, depending on the multitexturing capabilities of the graphics card.
The grid search you're talking about goes the other way around, it looks through the pixels covered by the polygon, projects its position into UV space and calculates the pixel value from the texels using the filtering defined by the engine (bilinear with mipmaps).
BTW, don't confuse the devs with wrong terminology, multitexturing means using multiple texture units to calculate the texture of a single surface, I think you want to have multiple materials per s3o. Or at least I want those so I don't have to cram everything into the same UV space
.
Those "passes" are texture layers, they are not necessarily rendered in different passes, depending on the multitexturing capabilities of the graphics card.
The grid search you're talking about goes the other way around, it looks through the pixels covered by the polygon, projects its position into UV space and calculates the pixel value from the texels using the filtering defined by the engine (bilinear with mipmaps).
BTW, don't confuse the devs with wrong terminology, multitexturing means using multiple texture units to calculate the texture of a single surface, I think you want to have multiple materials per s3o. Or at least I want those so I don't have to cram everything into the same UV space
.Argh, you should read up on OpenGL normal co-ords and making a low poly sphere look smoother. There's no need for a smoothing/rounding pass if you're just using the simplest smoothing openGL provides which is specified at the same time the vertexes are specified using glNormal and glVertex.
3do textures are all shunted onto a 2048x2048 texture, which holds all the textures 3do units can use. Spring then takes the 3do units and maps their uv co-ords onto these textures on this uv map.
A set of uv co-ords maps directly onto the co-ords of a texture image in memory. The whole business of texture mapping has been in video cards for quite a while and has been hardware accelerated and optimized for the last decade.
This is something that's been made somewhat irrelevant, just like those brand new cards that can do several billion triangles on screen at once. The geometry and the colours are not the bottleneck here.
The real bottleneck is in moving things back and forth and pushing them onto the GL pipeline, all that communication between the gpu and the cpu/ram, and all those shaders and effects applied ontop of whats being rendered. Thats why thigns like display lists and vertex bfufer objects are such a performance boost because they push thigns onto the video card and minimize back and forth communication. Things like shadows and alpha distortions and bloom and more fancy effects all layered onto each other are what really slow things down, ever wonder why newer video cards have so many shader units of ever increasing numbers and complexity? That 8800GTX is a 124 core shader gpu.
Argh I would recommend OpenGL Super Bible to you.
nonsense. 3do objects suffer the same flaw because the graphics card has to map the uv co-ords to the uv map in memory. The difference here is that spring generated the uv map not the suer, and spring generated the uv co-ords not the user.At any rate, S3Os are a lot less efficient, and the size of the texture map makes a very big difference in how they operate. Every time your object runs through the engine, the texture's coordinates need to be projected onto the surface normals, and IIRC (OpenGL peeps, feel free to correct my ignorance) that's a pixel-based grid search. Then the pixels need to be displayed on the triangles. In short, the bigger the texture, the longer it takes to do the searches, which is why all of the experienced modelers are somewhat obsessed with keeping the size of the texture as low as possible.
3do textures are all shunted onto a 2048x2048 texture, which holds all the textures 3do units can use. Spring then takes the 3do units and maps their uv co-ords onto these textures on this uv map.
A set of uv co-ords maps directly onto the co-ords of a texture image in memory. The whole business of texture mapping has been in video cards for quite a while and has been hardware accelerated and optimized for the last decade.
This is something that's been made somewhat irrelevant, just like those brand new cards that can do several billion triangles on screen at once. The geometry and the colours are not the bottleneck here.
The real bottleneck is in moving things back and forth and pushing them onto the GL pipeline, all that communication between the gpu and the cpu/ram, and all those shaders and effects applied ontop of whats being rendered. Thats why thigns like display lists and vertex bfufer objects are such a performance boost because they push thigns onto the video card and minimize back and forth communication. Things like shadows and alpha distortions and bloom and more fancy effects all layered onto each other are what really slow things down, ever wonder why newer video cards have so many shader units of ever increasing numbers and complexity? That 8800GTX is a 124 core shader gpu.
Argh I would recommend OpenGL Super Bible to you.