Irrlicht Engine

For my part dx11 and instancing are both missing from the trunk so until both are ported i'm stuck on the shader-pipeline

Nadro wrote:I think that we should set 8/16 textures by default for v1.9).

We had a thread about that recently and there had been two problems.

First it turned out that many modern graphic cards still don't support 8 textures, but have a 4 texture limit. We could still allow 8 in the engine, just users should be somehow made aware that this means their game won't run correctly on a surprising high amount of modern cards. Which was something I didn't know about (I suspect this applies only to fixed function pipeline as GL3.0 seems to require a minimum of 16 textures per shader stage).

Second problem is that it might have some cost. Resetting textures currently seems to show up in profiling with a non-trivial amount of time for some reason. Not quite sure yet why that's the case (haven't found time to dig into that yet, just was confused when I noticed it). So before increasing to 8 please make some real-life tests about the effect on speed. It could be we have to change some more stuff first or we add a serious speed hit for people not needing that (which I suppose is most users as I don't think we have that many users with the art resources to create models with more than 4 textures per polygon).

edit: Note that I still aggree that we should increase it. I try to I find time to run some tests about the affect on speed when just increasing the define.

CuteAlien wrote:First it turned out that many modern graphic cards still don't support 8 textures, but have a 4 texture limit. We could still allow 8 in the engine, just users should be somehow made aware that this means their game won't run correctly on a surprising high amount of modern cards. Which was something I didn't know about (I suspect this applies only to fixed function pipeline as GL3.0 seems to require a minimum of 16 textures per shader stage).

All GPUs compatible with Shader Model 2.0+ (GeForce FX+, Radeon 9500+) supports 16+ textures. 8 or sometimes even 4 textures limit, like you said is related only for fixed function pipeline path, but in custom materials we force users to programmable rendering pipeline, where 4/8 textures limt doesn't exist.

CuteAlien wrote:Second problem is that it might have some cost. Resetting textures currently seems to show up in profiling with a non-trivial amount of time for some reason. Not quite sure yet why that's the case (haven't found time to dig into that yet, just was confused when I noticed it). So before increasing to 8 please make some real-life tests about the effect on speed. It could be we have to change some more stuff first or we add a serious speed hit for people not needing that (which I suppose is most users as I don't think we have that many users with the art resources to create models with more than 4 textures per polygon).

Yes, you're right, however without modifications related for SMaterial / SMaterialLayer we can't easy fix that issue.

Nadro wrote:Yes, you're right, however without modifications related for SMaterial / SMaterialLayer we can't easy fix that issue.

Maybe we can handle it with an additional per-material max-textures parameter. That could either default to the max-textures define (and users can reduce it for optimization if they know they don't need that many textures in the material), or it could maybe be updated once per rendering or so based on the number of texture-pointers used. Or maybe just going over texture-pointers quickly and caching the last state would already be sufficient (but tricky as same pointer doesn't mean same texture necessarily).
But I'll have to do some better profiling tests for that first, not sure yet if increasing the define really even matters.

Nadro do have a ball park time for your changes?