[2.1] MyGUI renders darker vs 1.9

[LePawel]

Hi,
I've been porting my project to 2.1 for the past few weeks, and while I'm learning a lot, I'm kind of stuck with this:
As seen in attached image, all of UI, which is done with help of MyGUI, using their default skins look much darker compared to 1.9 (which is the correct color, ignore the background, that's changed on purpose).
I have been trying to figure this stuff out on my own, but I end up either breaking the whole application, or with 0 change.

If it helps, here's my compositor setup, which is shamelessly stolen from one of the MyGUI porting threads flying around:

Code: Select all

        const Ogre::String workspaceName = "RTSWorkspace";
        const Ogre::IdString workspaceNameHash = workspaceName;

        Ogre::CompositorManager2* pCompositorManager = Ogre::Root::getSingleton().getCompositorManager2();
        Ogre::CompositorNodeDef *nodeDef = pCompositorManager->addNodeDefinition("RTSWorkspaceDefinition");

        //Input texture
        nodeDef->addTextureSourceName("WindowRT", 0, Ogre::TextureDefinitionBase::TEXTURE_INPUT);
        nodeDef->setNumTargetPass(1);
        {            
            Ogre::CompositorTargetDef *targetDef = nodeDef->addTargetPass("WindowRT");
            targetDef->setNumPasses(3);
            {
                {
                    //clear with light grey
                    Ogre::CompositorPassClearDef* passClear = static_cast<Ogre::CompositorPassClearDef*>
                       (targetDef->addPass(Ogre::PASS_CLEAR));
                    passClear->mColourValue = Ogre::ColourValue(0.35f, 0.35f, 0.35f, 1.0f);

                    //render scene
                    Ogre::CompositorPassSceneDef *passScene = static_cast<Ogre::CompositorPassSceneDef*>
                        (targetDef->addPass(Ogre::PASS_SCENE));
                    //passScene->mShadowNode = Ogre::IdString();

                    //MyGUI pass
                    Ogre::CompositorPassClearDef* guiPass = static_cast<Ogre::CompositorPassClearDef*>
                        (targetDef->addPass(Ogre::PASS_CUSTOM, MyGUI::OgreCompositorPassProvider::mPassId));                    
                }
            }
        }
        Ogre::CompositorWorkspaceDef *workDef = pCompositorManager->addWorkspaceDefinition(workspaceName);
        workDef->connectOutput(nodeDef->getName(), 0);

        return pCompositorManager->addWorkspace(mSceneManager, mRenderWindow, mCamera, workspaceNameHash, true);

Any help appreciated, I'm slowly losing my mind

[N0vember]

I had the same issue a week ago.
It's probably just about passing "gamma" = "true" in the parameters when creating the RenderWindow.

Code: Select all

		Ogre::NameValuePairList params;
		params["gamma"] = "true";

		m_ogreRoot.createRenderWindow(name, width, height, fullScreen, &params);

[xrgo]

I have no experience with guis, not sure if has to do with the problem... but all it comes to my mind is check gamma correction and vertex color of the quads

[LePawel]

I had the same issue a week ago.
It's probably just about passing "gamma" = "true" in the parameters when creating the RenderWindow.

Code: Select all

		Ogre::NameValuePairList params;
		params["gamma"] = "true";

		m_ogreRoot.createRenderWindow(name, width, height, fullScreen, &params);

It does seem to be something related to gamma, I am basing my setup on Tutorial 4 - interpolation loop, but none of the gamma changes seem to affect anything..
could the fact I'm trying to integrate it with SFML for window/input/audio have something to do with this?

[LePawel]

Ha! what would the world do without #ifdefs
switched from SFML back to SDL and its fine!
Question regarding the following params I got from here: http://en.sfml-dev.org/forums/index.php?topic=13538.0
Is there a way to configure them so Ogre can do whatever it wants?

Code: Select all

        params["externalWindowHandle"] = winHandle;
        params["externalGLContext"] = Ogre::StringConverter::toString(winGlContext);
        params["externalGLControl"] = "True";

[LePawel]

Ok, so after a play around with SDL2, it seems that I cannot enable mouse trap/grab, whatever you want to call it, basically I need the mouse to stay locked to the window (Birds-eye style camera control, cursor at edge == camera movement).
While latest SFML source has that functionality built in, 1 function and it works, I can't figure out how to do that with SDL, does anyone has any information about that?
I've tried relative mode, mouse grabs and all that, but I can't get the combo right.

[scrawl]

Ok, so after a play around with SDL2, it seems that I cannot enable mouse trap/grab, whatever you want to call it, basically I need the mouse to stay locked to the window (Birds-eye style camera control, cursor at edge == camera movement).
While latest SFML source has that functionality built in, 1 function and it works, I can't figure out how to do that with SDL, does anyone has any information about that?
I've tried relative mode, mouse grabs and all that, but I can't get the combo right.

Try the SDL wrapper from the samples, the setGrabMousePointer(true) and setMouseRelative(true) should do the trick.

[LePawel]

Ok, so after a play around with SDL2, it seems that I cannot enable mouse trap/grab, whatever you want to call it, basically I need the mouse to stay locked to the window (Birds-eye style camera control, cursor at edge == camera movement).
While latest SFML source has that functionality built in, 1 function and it works, I can't figure out how to do that with SDL, does anyone has any information about that?
I've tried relative mode, mouse grabs and all that, but I can't get the combo right.

Try the SDL wrapper from the samples, the setGrabMousePointer(true) and setMouseRelative(true) should do the trick.

Thanks for the link, I've managed to do it by manually recentering the mouse to the window at the end of every frame, hiding the cursor, and manually calculating relative movements (since all movement will be added to my recenter, I subtract half-window size to get relative movement).
For people looking for this in the future:

Code: Select all

void rts::Input::mouseMoved(const SDL_Event &arg)
{
      auto window_size = Interface::instance().getWindowSize();//<- replace with your own way of grabbing window size

      m_rel_mouse_pos.x = arg.motion.x - (window_size.width / 2);
      m_rel_mouse_pos.y = arg.motion.y - (window_size.height / 2);

      m_mouse_pos.x = util::clamp(m_mouse_pos.x + m_rel_mouse_pos.x, 0, window_size.width);
      m_mouse_pos.y = util::clamp(m_mouse_pos.y + m_rel_mouse_pos.y, 0, window_size.height);

      MyGUI::InputManager::getInstancePtr()->injectMouseMove(m_mouse_pos.x, m_mouse_pos.y, 0);
}
--------------- for the lazy, here's the clamp function ---------------
int clamp(int val, int lower, int upper)
{
    return ((val < lower) ? lower : ((val > upper) ? upper : val));
}

+ add this right after you've finished polling your events:

Code: Select all

    while(SDL_PollEvent(&evt)) {  
      ...  }
    auto window_size = rts::Interface::instance().getWindowSize(); //<- replace with your own way of grabbing window size
    SDL_WarpMouseInWindow(mSdlWindow, window_size.width / 2, window_size.height / 2);

Works like a charm.

[AshMcConnell]

Did you ever manage to fix the problem of the colours being incorrect? I'm having a similar problem: -

http://www.ogre3d.org/addonforums/viewt ... 17&t=32460



I have the gamma set, but no luck

[dark_sylinc]

Did you ever manage to fix the problem of the colours being incorrect? I'm having a similar problem: -

http://www.ogre3d.org/addonforums/viewt ... 17&t=32460



I have the gamma set, but no luck

I am not registered in the addons forums so I'll reply here:
"#231F20" is the correct value for that grey in linear space. I guess you are expecting its corresponding gamma space grey.

To convert between sRGB and linear spaces use where x is in range [0; 1]:

Code: Select all

float toSRGB(float x)
{
    if (x <= 0.0031308)
        return 12.92 * x;
    else
        return 1.055 * pow( x,(1.0 / 2.4) ) - 0.055;
}

float fromSRGB(float x)
{
    if( x <= 0.040449907 )
        return x / 12.92;
    else
        return pow( (x + 0.055) / 1.055, 2.4 );
}

In this case you need to apply toSRGB.

[AshMcConnell]

Thanks, does seem like gamma, but converting it to sRGB made it whiter

Code: Select all

_backgroundWidget->setColour(MyGUI::Colour(toSRGB(35.0f / 255.0f), toSRGB(31.0f / 255.0f), toSRGB(32.0f / 255.0f)));

I tried using the fromSRGB function and it was close (#221C1C), but still slightly off, it's a strange one, perhaps precision lost somewhere?

[dark_sylinc]

If it just made it worse, then I was wrong and you should do the opposite by using fromSRGB (trial and error!).

[dark_sylinc]

Oh I get it now... the background colour should match that of the texture?

What's the colour at the border of the texture you should match to?

[AshMcConnell]

Oh I get it now... the background colour should match that of the texture?

What's the colour at the border of the texture you should match to?

So the right edge of the texture is: - rgb(35,31,32) #231F20
I have set the background colour of the menu to: -

Code: Select all

_backgroundWidget->setColour(MyGUI::Colour(GfxUtilities::fromSRGB(35.0f / 255.0f), GfxUtilities::fromSRGB(31.0f / 255.0f), GfxUtilities::fromSRGB(32.0f / 255.0f)));

But I get rgb(34,28,28) #221C1C rendered (on the right hand side of the screen)

[dark_sylinc]

Yes. It's a precision error.

These values:

Code: Select all

35 31 32

correspond to these in [0; 1] range:

Code: Select all

0.137254902 0.1215686275 0.1254901961 //sRGB space
0.0168073758 0.013702083 0.0144438436 //linear space

If we multiply the last line by 255 and truncate the values, we get:

Code: Select all

4 3 3

If we now divide them by 255 again:

Code: Select all

0.0156862745 0.0117647059 0.0117647059 //linear space

Which when converted to sRGB space, multiplied by 255 and rounded we get:

Code: Select all

34 28 28

Which is the output you're seeing.

I'm guessing MyGUI is embedding the diffuse colour as a vertex colour in a VET_UBYTE4_NORM format.

You have three options:

• Live with it
• Modify MyGUI's vertex format so that instead of using VET_UBYTE4_NORM it uses more precision, something like VET_FLOAT4 for the vertex diffuse colour (you may have to modify other parts of the code as some parts may assume they need to write 1 byte per component instead of 4).
• Modify MyGUI's vertex shader so that the sRGB -> Linear conversion happens in the vertex shader; thus the converted values are sent with full precision to the pixel shader.

If I were you, I'd go for looking at MyGUI's vertex shader. Quickest and safest solution.

[AshMcConnell]

Thanks a lot! Makes sense . Feels close to a bug to me, it should be possible to tune the colours a little more finely. I wonder, perhaps if there is an option for more colour precision.

This was my first task of a free week of coding, I thought it would be 30 mins . I will live with it (or perhaps tint the original texture to match) as there are much bigger fish to fry at the moment. Then get back to it during my "spare time" coding

Thanks again!