Herb wrote:A few things I'm scratching my head at.... This example's new Hlms inherits from Ogre::Hlms, but Pbs and Unlit inherit from both HlmsBufferManager and ConstBufferPool. Is there a reason why, and what one should I use?
In one of those posts it's explained in detail, but the short story is those two classes are helper functions useful for desktop APIs (or even
modern mobile APIs, i.e. not GLES2) that help managing reusable const & texture buffers per frame (HlmsBufferManager derives from Hlms btw).
While ConstBufferPool is also a helper function for maintaining an array of materials up to date GPU side; i.e. in the shader we do (simplified):
Code: Select all
struct Material
{
float4 diffuse;
float4 specular;
};
uniform Material materials[256];
uniform uint materialIdxBuffer[]; //Not valid syntax, for explanation purposes.
in uint drawId;
uint materialIdx = materialIdxBuffer[drawId]
Material material = materials[materialIdx];
This selection is done GPU side. In DX9 this didn't exist. In DX9 we would set materialDiffuse and materialSpecular from the CPU every time it needed to change, which added a lot of CPU overhead. In Ogre 2.1 we just swap materials[256]'s pointer every now and then. Note that this GPU-side selection isn't free (i.e. on GCN it requires more VGPR registers instead of SGPR register). But it's an acceptable trade off, at least for us.
ConstBufferPool is an utility class for keeping materials[256]'s GPU pointers up to date with the CPU data. That's basically the point of
this thread.
You don't
neeeeed them, but they're useful (particularly for Pbs and Unlit which need to support lots of different materials and work be applied to lots of different meshes). For example, I didn't need them for my sky shader. Nor for a terrain shader.
Coming from Cg/DX9/Ogre 1.x; you had a mentality where a shader was a "thing" where you set a couple of switches, and fired it off. If you needed a different setting, you flipped those switches again, and launched another shader. And do so on.
DX11/GL3+/Ogre 2.1 treats shaders with the mentality that a shader is just a program running in GPU, and manipulates pointers to GPU memory. Instead of flipping switches each time we needed to make a change, we just write all our parameters to a pointer in memory, and when we've ran out of memory, we change the pointers.
I explained this in detail in
Performance Questions thread (note: I'm adding this to recommended reading post).
but I'm getting TONS of incomplete types and undeclared types from OgreHlms.h and OgreHlmsCommon.h and a few other files....
I find this strange.... Am I missing something?
C++ Forward declarations. You're probably missing one or two include headers, once you include them these errors will be gone. Without some hint of the errors I can't guess which files you're missing to include.
