Ogre halts rendering when window is deactivated

[Borundin]

This post concern Windows operating systems only I believe.

I want to design a tool for editing collision proxies for ODE, using Ogre to render both proxies and the actual mesh. Anyway, it seemed rather difficult for me to integrate MFC/wxWindows with Ogre so I eventually came up with another idea. Why not use my favourite GUI tool Visual Basic instead? So I wrote a simple VB app that writes down GUI input as commands to a file. That file is also polled and read by Ogre and then parsed by Lua (which I would had to integrate anyway for game object scripting). So I have two windows up. One is the Ogre rendering window and the other is the VB app (see screenshot). Collision Tool

Works like a charm, almost... It seems Ogre will not render anything when its render window is deactivated. I came up with two solutions (see code below) and I dont like either of them. First is a hack in RenderSystem which work by calling update even if window is not active. The other solution is to not deactivate a window when it loses focus. I think the first solution is best because its closer to the real problem. The other solution might cause other troubles.

Now to my question. Is there another better way to solve this problem?
If there is none, then would it be in the interest of the community to add an option for rendering even if window is not active (as part of RenderWindow maybe)?



OgreRenderSystem.cpp

Code: Select all

    void RenderSystem::_updateAllRenderTargets(void)
    {
        // Update all in order of priority
        // This ensures render-to-texture targets get updated before render windows
		RenderTargetPriorityMap::iterator itarg, itargend;
		itargend = mPrioritisedRenderTargets.end();
		for( itarg = mPrioritisedRenderTargets.begin(); itarg != itargend; ++itarg )
		{
			// Ignore active state --- if( itarg->second->isActive() )
				itarg->second->update();
		}
    }
 

OgreD3D9RenderWindow.cpp

Code: Select all

		case WM_ACTIVATE:
			if( WA_INACTIVE == LOWORD( wParam ) )
				// Ignore deactivate --- win->mActive = false;
				win->mActive = true; // Always active!
			else
				win->mActive = true;
			break;

[cTh]

Other option is to use a non standard rendering loop (ie. not using root-:startRendering()) and update when u want, I'm doing this all the time and it works OK.

[zeroskill]

To make this abundantly clear.
These methods of rendering will not work if the Ogre app does not have focus:

Method 1: Root->startRendering();
Won't work, but provides its own Message Pump.

Code: Select all

Root->startRendering(); 

Method 2: Root->renderOneFrame();
Requires a Message Pump loop, but won't work.

Code: Select all

while(1){
    while(PeekMessage(&myMsg,myHWND,0,0,PM_REMOVE)){
        TranslateMessage(&myMsg);
        DispatchMessage(&myMsg);
    }

    Root->renderOneFrame(); 
}

Method 3: Root->_updateAllRenderTargets();
Requires a Message Pump loop, but also won't work.

Code: Select all

while(1){
    while(PeekMessage(&myMsg,myHWND,0,0,PM_REMOVE)){
        TranslateMessage(&myMsg);
        DispatchMessage(&myMsg);
    }


    if(!Root->_fireFrameStarted())
        break;
    Root->_updateAllRenderTargets();
    if(!Root->_fireFrameEnded())
        break;
}

All of the above methods will all fail to update the window if it is not focused. However, this method will work:

Method 4: RenderWindow->update();
Requires a Message Pump loop, but it WORKS!

Code: Select all

while(1){
    while(PeekMessage(&myMsg,myHWND,0,0,PM_REMOVE)){
        TranslateMessage(&myMsg);
        DispatchMessage(&myMsg);
    }


    if(!Root->_fireFrameStarted())
        break;
    RenderWindow->update();
    if(!Root->_fireFrameEnded())
        break;
}

On a more personal note, I think its a little odd that a render engine would care that much about the focus state of the render target window. I've always felt the application is responsible for using its resources correctly in cases like that. This work around is just that. A hack. Honestly, it shouldn't have to be. Hopefully in the next version of Ogre, it won't care if the window has focus.

[Will Bricknell]

I had the same problem a few days ago but found a thread where NFZ explained how to modify the Ogre rendersystems to automatically update the renderwindow whether it has focus or not, i linked to the thread here:
http://www.ogre3d.org/phpBB2/viewtopic. ... ight=focus

[zeroskill]

Oh absolutely, if you want to simply crack open the source code every time you find one little problem, anything is fixable. But, that's kind of the reason I have for using Ogre. I have no interest in writing a render engine. I just want a system that I can easily feed input, and get expected results. Ogre fills that need quite well.

I only have 2 major problems with Ogre thus far:
The window focus issue in this thread, which has a workaround. And, the issue of Ogre taking over the DirectX input as it does (stealing the mouse entirely, no hardware cursor support), for which thus far I have found no work around. But, the window focus issue was my first priority, I haven't looked that hard at the input issue yet. Having found the workaround for the focus problem, the input problem is now my main concern, so hopefully I'll find a way around this one too. I really do hope these problems are solved in the next version of Ogre.

Aside from all of that, this is still one of the best thought out generic render engines I've seen. My thanks to the developers for making such a useful render engine! =D

[jacmoe]

I only have 2 major problems with Ogre thus far:
The window focus issue in this thread, which has a workaround. And, the issue of Ogre taking over the DirectX input as it does (stealing the mouse entirely, no hardware cursor support), for which thus far I have found no work around.

Just don't use the Ogre input - it works well for what it is intended for: quick input for the demos. It is not meant to be a full-fledged input system. In fact, if it weren't for the demos, Ogre wouldn't have any input "system" at all.
You are free to use your own nifty input library.

As for the window focus issues you are having: It is really quite common to pause the rendering engine when the window is minimized, and it makes sense (after all: why render something you cannot see!)

You are free to create your own window, and do what you want.
Like you just did.

[zeroskill]

As for the window focus issues you are having: It is really quite common to pause the rendering engine when the window is minimized, and it makes sense (after all: why render something you cannot see!)

Well, that is the problem though. It doesn't stop the rendering just when the window is minimized. It stops when it simply loses focus. Which means if you have 2 windows open at the same time, not necessarily even overlapping one another, you can switch your focus to the 2nd window and Ogre will stop rendering. If it only affected the rendering when the window was minimized I wouldn't care, since I likely would have never noticed.

I just wanted to clarify that this happens even if the window is maximized just not on "top".

[jacmoe]

I see. I misinterpreted what you said.

[zeroskill]

No big deal. As I said though, I did find a fix for it, which I posted way up near the beginning of this thread.

So either way, I can get around it. But I do hope that line of code gets changed in the next Ogre release so that this doesn't happen. From my understanding, this pause in rendering only occurs on the Windows port, which to me indicates that it is not the intended functionality. (And hence is a bug.)

As for the input stealing, I've found that if I simply never initialize an InputReader class, Ogre doesn't steal away my mouse cursor. Alternatively, I can initialize an InputReader, and just tell it to only get keyboard events.

Input routines are so very basic, I'm really having a hard time understanding why the input classes in Ogre aren't more supported. Well, at least they are very basic in Windows. (DirectInput handles a LOT for you...) I was hoping to avoid having to compile my app against both Ogre and the DirectX SDK, but now that I need to access direct input, I have no choice. (SDL is bloatware if all you want are the input routines, and GII seems more unix oriented than anything else, so DirectInput is the only reasonable choice)

Ah well. It's all good. Even if I do have to sling out a new input reader class for my application, at least I don't have to deal with all of the annoying D3D calls. And for that, I'm still very greatful!

[:wumpus:]

Yes, the ogre input system isn't fully flexible. LIke said a lot of times, it's only there for the demos. We don't support it better because that is not the task of a rendering engine, and we're wound up in rendering-oriented things.

We plan on completely seperating the input system from the main ogre core in the 1.1.x branch, and will also make it easier to use your own input system or widget system with ogre.

[_lkoikm]

NOTE:

other thing that ogre is lacking is ready projects in VC6 , VC7... which present windowed application, fullscreen application , windowed dll control built onto MFC, __gc Forms ( which i beleve on VS2003 would be most popular ). I have spent much time developing quite stable control which i am using in couple apps. CODE reuse is ... time.

[jacmoe]

@_lkoikm:
We have all that already.
Ogre is rendering in FLTK, QT, MFC, .Net Forms (__gc), WX, ...
Some of these things can be found by hanging around the forum, use the search facilities, others can be found in the ogreaddons.

[_lkoikm]

i did indeed search for this while i worked on this case, without it i would fail or leave this matter, either way on forums you get scratches of code (sniplets) often spiked with global or elswere declared variables of which type and importance you could think for hours.

[:wumpus:]

Well, if you want to make a generalised library for binding widget toolkits to ogre, please do so, it would be very welcome

[jtarbox]

well, back to the original thread issue, here's the post showing what I did to solve this..

http://www.ogre3d.org/phpBB2/viewtopic.php?t=12283