[2.1] Missing environment map when a PBR material has too many texture inputs

[zxz]

Hello,

I have noticed an issue for PBR materials that use many textures. When the number of textures bound exceed a certain number, the remaining texture units are not bound. The texEnvProbeMap sits at the end, and ends up unavailable in the shader.

Here's a list of texture slots from RenderDoc:

1: f3dGrid
2: f3dLightList
3: texShadowMap0
4: texShadowMap1
5: texShadowMap2
6: texShadowMap3
8: texturesMaps[0]
9: texturesMaps[1]
10: texturesMaps[2]
11: texturesMaps[3]
12: texturesMaps[4]
13: texturesMaps[5]
14: texturesMaps[6]
15: texturesMaps[7]
16: texturesMaps[8] <-- unbound
17: texEnvProbeMap <-- unbound

This happens mainly for materials with multiple detail maps. If I remove one detail map with its two textures, the environment map comes back, as the number of bound textures is reduced. The problem happens even more in scenes with more shadow maps. I can use atlases for them, but I still easily run into this limit.

What's going on here? Where does this limit come from, and can I overcome it somehow?

[xrgo]

yes, its a limitation, but one that you can easily overcome:
1) use shadow atlas, you can pack all your shadows in only one texShadowMap, see the compositor shadow nodes of the samples
2) use same size and format for the rest of your textures so the HlmsTextureManager pack them together in the same texture array texturesMaps

[zxz]

I tracked down the cause of this, which seems to be a bug:

https://bitbucket.org/sinbad/ogre/src/b ... em.cpp-272

Code: Select all

        GLint units;
        OGRE_CHECK_GL_ERROR(glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, &units));
        rsc->setNumTextureUnits(std::min<ushort>(16, units));

This caps the number of texture units to 16, while more might be available on the system. My system reports 32 for GL_MAX_TEXTURE_IMAGE_UNITS, but it gets reduced to 16 as the rendersystem capability.

If I change this to std::max, the textures are bound as expected and everything works.

[xrgo]

I read somewhere that this was some kind of forced limitation to maintain hardware compatibility, not sure... if that's the reason I think its good for you to reduce your texture count like I said, or some players would have graphics glitches with your games if they have hardware with 16 as limit.
I would like to see what dark_sylinc have to say about this =)

[zxz]

Seems like a very artificial limitation. It should be up to the one who compiles the library to decide the limits.

There's a macro OGRE_MAX_TEXTURE_LAYERS, which is also 16, that might be applicable. Maybe it should be exposed as a CMake parameter in case artificial limits are desired. Otherwise it seems quite unnecessary for the render system to report untruthful system capabilities.

In our case, this is not an issue as all, as we control the hardware used by our users. In the general case I suppose most GPU's have at least 32 these days anyway.

[dark_sylinc]

Hi,

Like xrgo says, you can workaround this limitation by having more textures match the same resolution and format (so they end up in the same texture array), and shadow map atlases.

In most cases detail maps should end up sharing the same texture array.

If you need a quick hack, on top of what you've written you'll need to increase OGRE_MAX_TEXTURE_LAYERS, otherwise you'll have memory corruption.

The source of this limitation comes from several places:

• In OpenGL, for a long time the limit has been 16. Modern cards now report 31-32, but this is mostly a workaround (trying to use more than 16 in OpenGL could cause issues if the driver doesn't handle it right).
• Direct3D11 separates samplers from textures. Direct3D11 mandates a minimum of 16 samplers, and 128 textures. The problem is that Ogre ties samplers with textures (like OpenGL), so the maximum we support ends up being 16.
• Metal is in a similar boat to D3D11

Ogre 2.2 separates samplers from textures which allows us to significantly increase this limit (obviously for GL this limit would still be in 31-32 on most cards today, due to API limitations), but there's no ETA on 2.2.

More than 16 is not something we can just allow because HW doesn't really support more than 16 samplers, or does so by taking a bigger performance hit (32 samplers requires 128 scalar registers on GCN!!! something like that decimates performance).

[zxz]

textureMap[6] and textureMap[7] already have the same dimensions (2048²) and both are RG8_SNORM. They contain only 2 textures each. What's the reason for these not being fit into the same array?

It feels like a lottery to hope that textures will always end up perfectly in the same arrays in order to get a low enough number of texture units.

The texture types also use different formats by default, I believe. Some have compressed formats, some are SRGB while some are not. Normal maps have two channel textures only. This means that the minimum number of units needed is quite high even in the best case. Any resolution mismatch will also make it worse.

[dark_sylinc]

It's likely an issue with HlmsTextureManager::DefaultTextureParameters.

Putting too many textures in the same array can cause memory issues, so the defaults are a bit conservative. The parameters are meant to be tweakable but the interface was never written (i.e. you need to modify the source code to tweak the defaults when you shouldn't have to).

These texturing problems are known issues Ogre 2.2 is addressing, so I get your frustration.

Users who absolutely need this, modify OGRE_MAX_TEXTURE_LAYERS and move on, you're not the only one.

[zxz]

Sorry if I come off as too grumpy The workaround is simple enough. I was just trying to argue that the limits are perhaps too conservative.