NULL render system creates no GpuProgramManager: parsing any .material/.program script asserts

[steffen-roemer]

Symptom

Under RenderSystem_NULL, parsing any .material or .program script aborts:

Assertion failed: (msSingleton), function getSingleton,
  file OgreGpuProgramManager.cpp, line 52

The script compiler reaches GpuProgramManager::getSingleton() while translating a vertex_program/fragment_program declaration, and there is no instance.

Cause

NULLRenderSystem::_createRenderWindow creates the managers a render system owns:

mHardwareBufferManager = new v1::DefaultHardwareBufferManager();
mVaoManager = OGRE_NEW NULLVaoManager();
mTextureGpuManager = OGRE_NEW NULLTextureGpuManager( mVaoManager, this );

but no GpuProgramManager. Metal and Vulkan create theirs in initialiseFromRenderSystemCapabilities:

mShaderManager = OGRE_NEW MetalGpuProgramManager( &mDevice );   // OgreMetalRenderSystem.mm
mShaderManager = OGRE_NEW VulkanGpuProgramManager( mDevice );   // OgreVulkanRenderSystem.cpp

RenderSystems/NULL/ contains no reference to GpuProgramManager at all, so msSingleton stays null for the whole process lifetime.

Why this is being raised rather than patched

It reads as a design question, not an omission with one obvious answer, and any of these could be what you intend:

1. A NULLGpuProgramManager that accepts every declaration and produces inert programs — scripts parse, nothing is compiled, and a headless run behaves like the real ones for everything above the shader tier.
2. An honest refusal — a clear exception ("the NULL render system has no GPU program manager") instead of an assert, so the caller learns what happened.
3. Out of scope by design — the NULL RS deliberately serves Hlms-only content, and low-level material scripts are simply not part of what it supports. That is a legitimate position; it would just be worth saying so, because today the answer arrives as an assert inside OgreMain.

Happy to send a PR for whichever of these you prefer.

Encountered while making the Ogre-Next backend of orkige run window-less and GPU-less for CI; the media that triggered it was the AtmosphereNpr sky's own .material/.program pair, which the engine now skips registering when it boots deviceless. (Related, from the same exercise: #587 and #588.)

[darksylinc]

NULL rendersystems are often a quick solution so that regular code can be used without invoking the GPU or creating a server that performs the entire simulation skipping the rendering part, thus NULL dummies out everything.

Meshes are often necessary to "emulate" because simulation code will often need to access triangle data.
But Gpu Programs were skipped because that its 100% GPU related and has no usefulness to such programs.

A NULLGpuProgramManager that accepts every declaration and produces inert programs — scripts parse, nothing is compiled, and a headless run behaves like the real ones for everything above the shader tier.

If this can be done with minimal RAM consumption and maintenance it may be viable. But if it is or grows too big it creates maintenance burdens we don't like to spend our time on (because it's literally a "dummy, we pretend it works but it doesn't. Don't use it"), thus in that case then a honest refusal would be better; and have the higher level skip material/program parsing.