Irrlicht Engine

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'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.

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...").

greenya 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...").

this sounds good... with this I need only to check the actual resolution and convert the textures to the correct width/height

Test before doing that, texture size doesn't have that big an effect unless you run out of vram.

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.

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...)

If you don't use any advanced features, it's likely your app will run well on old hardware

hendu wrote:If you don't use any advanced features, it's likely your app will run well on old hardware

Of course I would like to use newer techniques if possible, to get as most realistic look as possible...

Just I need to know, what are the possibilites? Is there a tutorial or something, showing these advanced features?

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.

All those filter options can be set in SMaterial. No shaders needed for that.

You can do very decent effects without shaders at all

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.

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.

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