Fixing DearIMGUI NewFrame()/EndFrame() cycle.

[ohlidalp]

I'm getting debug asserts from DearIMGUI that NewFrame()/EndFrame() functions are not being called in sync. It only happens at certain stage of loading certain terrains. Things to know before moving further:

• our DearIMGUI integration is a port of OGRE 1.12's OgreImGuiOverlay, since we're still running at 1.11.6 (last time we checked, MyGUI didn't work with latest ogre).
• NewFrame() is invoked from main()
• Render() is called from within Ogre::RenderQueueListener::renderQueueStarted() callback implemented in OgreImGui
• OGRE's renderOneFrame() is invoked from 2 places: main() for regular gameplay frames and progress window [which itself is invoked indirectly from main] when loading things.

Original concern

Update: root cause found

IM_ASSERT((g.FrameCount == 0 || g.FrameCountEnded == g.FrameCount) && "Forgot to call Render() or EndFrame() at the end of the previous frame?"); in NewFrameSanityChecks(). This happens during loading Aspen Grove terrain. When continued with debugger, the game runs fine. See logs:
RoR-reverted-debuggerAbort.log
RoR-reverted-debuggerContinueGameRuns.log
Note that Train Valley loads without problem.

The reverted commit 627d85b

it fixed the Aspen Grove case, but introduced another in Train Valley terrain: IM_ASSERT(g.FrameScopeActive); // Forgot to call ImGui::NewFrame() in Begin(). Continuing with debugger triggers the FrameCount assert, then FrameScope again, then FrameCount again and then it hangs in Collisions::hashfunc(). See logs.
RoR-upstream-debugerAbort.log
RoR-upstream-debuggerContinue3x.log

Test PC spec:

• OS Windows 10, Version 10.0.19042 Build 19042
• Processor AMD Ryzen 5 5600X 6-Core Processor, 3701 Mhz, 6 Core(s), 12 Logical Processor(s)
• Graphics card nVidia GeForce GTX 660, driver 466.27
• Microsoft Visual Studio Community 2019 Version 16.11.3
• using Debug x64, RenderSystem_GL

Tomorrow I'll add debug checks and re-run it to see when it breaks.

[ohlidalp]

I just tried on my work laptop:

• Windows10 Enterprise, Version 10.0.19042 Build 19042
• Processor Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz, 2901 Mhz, 4 Core(s), 8 Logical Processor(s)
• Intel(R) HD Graphics 630
• Microsoft Visual Studio Professional 2019 Version 16.11.2
• running Debug, x64, OpenGL Rendering Subsystem

Same result with Aspen Grove (without 627d85b):
RoR-laptop-AspenGrove-debuggerContinue.log
RoR-laptop-AspenGrove-debuggerAbort.log

[ohlidalp]

I added debug macros and tried again (on work laptop):
RoR-laptop-NFEV-cmdlineAspen-debuggerIgnore.log
RoR-laptop-NFEF-cmdlineAspen-debuggerAbort.log
This is what I get from the logs:

11:24:11:  - NFEF - calling ImGui::NewFrame()
11:24:11:  - NFEF - calling ImGui::Render()
11:24:11: [RoR|PleaseWaitUI] <44%> Loading terrain pages ...
11:24:11: Terrain created; size=1025 minBatch=33 maxBatch=65 treeDepth=5 lodLevels=6 leafLods=2
11:24:16: Texture 'a89a5UID-aspen.dds': Loading 1 faces(PF_DXT5,1024x1024x1) with 10 custom mipmaps from Image. Internal format is PF_DXT5,1024x1024x1.
11:24:16: Texture 'traildirt.dds': Loading 1 faces(PF_DXT5,512x512x1) with 9 custom mipmaps from Image. Internal format is PF_DXT5,512x512x1.
11:24:16: done loading page: loaded 2 layers
11:24:17:  - NFEF - calling ImGui::NewFrame()
11:24:17:  - NFEF - running OgreImGui::renderQueueStarted(): overlays disabled!
11:24:17: [RoR|PleaseWaitUI] <60%> Initializing Collision Subsystem
11:24:17:  - NFEF - calling ImGui::NewFrame()

But when I set a data breakpoint to Viewport::mShowOverlays, I get no hit - the value seems to be always true. I verified the bool value is 1 byte:

+		&vp->mShowOverlays	0x000001867ba527f9 {true}	bool *
		(int)((uint8_t*)&vp->mShowOverlays)[0]	1	int
+		&vp->mShowSkies	0x000001867ba527fa {true}	bool *

[ohlidalp]

Mystery explained - for some reason, OgreRoot::GetRenderSystem()->_getViewport() gives me a different viewport object that single time. The original one still has overlays on, that's why data breakpoint didn't hit.

RoR-NFEFr2-debuggerAbort.log

@paroj Any idea why

rigs-of-rods/source/main/gui/imgui/OgreImGui.cpp

Line 137 in 404a390

Ogre::Viewport* vp = Ogre::Root::getSingletonPtr()->getRenderSystem()->_getViewport();

would suddenly return a different viewport?

[paroj]

_getViewport() gives you the currently active viewport. Depending on when you ask, this might be the shadowmap.

This is how I attached ImGui code to one specific Viewport in Ogre:
OGRECave/ogre@6ea11c9#diff-ba044a06f13f5520d6a7f71483b63942b77482b9f1c948fac74fc8159eec544a

[ohlidalp]

@paroj problem found: Checking sceneMgr->_getCurrentRenderStage() == Ogre::SceneManager::IRS_RENDER_TO_TEXTURE)
doesn't do the trick if the RTT is updated by calling Ogre::RenderTarget::update() by hand,
which we do frequently.

I fixed it by adding check against the game's viewport pointer. Your solution OGRECave/ogre@6ea11c9#diff-ba044a06f13f5520d6a7f71483b63942b77482b9f1c948fac74fc8159eec544a is'n applicable here because it requires all GUI to be drawn in RenderTargetListener::preViewportUpdate() callback, and we need it available anytime in the main loop (debug views, scripting, but also convenience).

I moved the branch with debug logging to https://github.com/only-a-ptr/rigs-of-rods/commits/archive/imgui-NewFrameEndFrame-debug and only applied the fix here.

[tritonas00]