Preparing for performance issues (textures)
Preparing for performance issues (textures)
Hi,
I would like to ask you, how to manage the quality part of the development? I mean, how can I prepare to a user with an older PC and lower screen resolution (1024x768) vs newer PC with 1920x1080. If I use a big size of textures with big resolution, maybe the program will run only with 3-5 FPS, but when I use small size of textures, it will not look nice on a high screen resolution monitor...
Should I create the textures in two sizes? And decide in the program, which one to use?
I would like to ask you, how to manage the quality part of the development? I mean, how can I prepare to a user with an older PC and lower screen resolution (1024x768) vs newer PC with 1920x1080. If I use a big size of textures with big resolution, maybe the program will run only with 3-5 FPS, but when I use small size of textures, it will not look nice on a high screen resolution monitor...
Should I create the textures in two sizes? And decide in the program, which one to use?
Re: Preparing for performance issues (textures)
I've seen different projects handle such problems in different ways. But the by far most common solution was to set minimal requirements and simply ignore systems below that. I'm also not sure how much the texture-size really affects speed (you have to test that stuff with concrete scenes), but I guess using a detail-texture on a lower-resolution base-texture might have better effects. And enabling/disabling that will also be easier and have probably have some noticable impact on speed.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Preparing for performance issues (textures)
I would suggest to have most detailed textures (say like 1920x1080) so the look good on hires monitor. But when you run app you check system capabilities and if you found low resolution (say like 1024x768) you can resize them before using them actual at runtime (so you start process like "optimizing textures please wait...").
Re: Preparing for performance issues (textures)
this sounds good... with this I need only to check the actual resolution and convert the textures to the correct width/heightgreenya wrote:I would suggest to have most detailed textures (say like 1920x1080) so the look good on hires monitor. But when you run app you check system capabilities and if you found low resolution (say like 1024x768) you can resize them before using them actual at runtime (so you start process like "optimizing textures please wait...").
Re: Preparing for performance issues (textures)
Test before doing that, texture size doesn't have that big an effect unless you run out of vram.
Re: Preparing for performance issues (textures)
It is more important to have good art assets that balance well the usage of textures. That allows you to have good looking graphics with really low resolution textures. After all, the most important thing of a texture is the amount of screen it covers and its pixel/texel ratio (being 1 the ideal), First create good assets, and later, prepare for texture optimization, maybe you don't even need it. Also, it is convenient to note that filtering is an important issue to keep in mind because an old video card probably won't "enjoy" as much as a new one things like anisotropic filtering, or even trilinear mipmap interpolation. Anisotropic requires more memory, and trilinear filtering is slower than bilinear. So, on older hardware (GeForce7 or 8 for instance) it is more important to keep the filtering low than using large textures to gain performance. Of course, smaller textures are faster, so, reducing the resolution is a good idea. 256x256 is a recomended texture size in the directX SDK, for instance.
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Preparing for performance issues (textures)
Thank you for the valuable information.
I will check these things (anisotropic filtering, trilinear filtering, bilinear filtering), because I never used them before...
Are these supported by Irrlicht? Is there a tutorial somewhere, how to set up this correctly?
(However, I will google for it...)
I will check these things (anisotropic filtering, trilinear filtering, bilinear filtering), because I never used them before...
Are these supported by Irrlicht? Is there a tutorial somewhere, how to set up this correctly?
(However, I will google for it...)
Re: Preparing for performance issues (textures)
If you don't use any advanced features, it's likely your app will run well on old hardware
Re: Preparing for performance issues (textures)
Of course I would like to use newer techniques if possible, to get as most realistic look as possible...hendu wrote:If you don't use any advanced features, it's likely your app will run well on old hardware
Just I need to know, what are the possibilites? Is there a tutorial or something, showing these advanced features?
Re: Preparing for performance issues (textures)
Not really, that's why they're called advanced features heh
Sure there are tutorials showing how to use shaders, but then what you do with that (fully programmable pipeline) sky's the limit.
Sure there are tutorials showing how to use shaders, but then what you do with that (fully programmable pipeline) sky's the limit.
Re: Preparing for performance issues (textures)
All those filter options can be set in SMaterial. No shaders needed for that.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Re: Preparing for performance issues (textures)
You can do very decent effects without shaders at all
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt
Re: Preparing for performance issues (textures)
Certainly, but talking about realistic looks you do need more than the fixed pipeline.
On topic: I have no issue using 4k and 2k textures on mobile X1600 (r500). OP should define what he considers his minimum target.
On topic: I have no issue using 4k and 2k textures on mobile X1600 (r500). OP should define what he considers his minimum target.
Re: Preparing for performance issues (textures)
Are big texture atlases (how big?) and maximal batching the route to minimize frame draw times? I know you should minimize draw calls, meaning batching, but also context switches, which I assume translates into minimizing the number of materials.
Can somebody break down for me the best practices for maximizing the power and speed of the GPU, and also for avoiding becoming CPU bound on draw calls?
Thanks.
Can somebody break down for me the best practices for maximizing the power and speed of the GPU, and also for avoiding becoming CPU bound on draw calls?
Thanks.
Re: Preparing for performance issues (textures)
Yes, renderstate changes (materials) are expensive relatively. But there are worse things, like switching rendertargets
The less draw calls, the better
The smallest amount of material CHANGES (textures, transparency...), the better
The largest amount of static meshes, stored in hardware, the better. This is a DX8 level feature, so it is pretty normal even for old hardware to support this
The less draw calls, the better
The smallest amount of material CHANGES (textures, transparency...), the better
The largest amount of static meshes, stored in hardware, the better. This is a DX8 level feature, so it is pretty normal even for old hardware to support this
"There is nothing truly useless, it always serves as a bad example". Arthur A. Schmitt