CEGUI (Crazy Eddie's GUI) Forums

I think I encountered a bug in widget rotation. If the rotation value is set to "x:A y:0 z:0" or "x:0 y:B z:0", either by setRotation() or by XML property, where A and B is non-zero positive values, the widget is rotated in strange manner. When point is rotated around any axis in 3D, the component of point vector corresponding to axis is not changed. For example, if (a,b1,c1) is rotated by an arbitrary angle around x-axis, then new coordinates will be (a,b2,c2). I found that CEGUI changes the axis-component of a point, making the widget looking skewed instead of rotated. The rotation angle of 90 degrees around x or y-axis should make the widget (effectively) invisible, but the closest angle to make the widget look like line (=invisible) is ~99.35.
The image is attached. However, rotation quaternion (and rotation matrix I calculated from it) looks good to me and there are no issues with rotation around z-axis.

I use OpenGL3 renderer and played with glMatrixMode(), gluPerspective() and their friends to make sure it is not a viewport problem to no avail. This behavior occurs in v0-8 branch (v0.8.7 release 6267 (ed25a866ade7), tip 6740 (bd98855c1589)) and v0 branch (tip 6719 (fdb23c8a311b)).

Am I doing something wrong? Is this bug or expected behavior?
Thanks.

Looks like a bug, but unfortunately I have no idea about it. I never used the rotation system of CEGUI, you already know more than me

I would not say it is expected behaviour. For a 90° rotation I expect this widget to vanish, just as you said.

Do you have any guesses?

Ident wrote:Do you have any guesses?

I did quick tests, and found that the rotation in samples built with glfw2 & OpenGL3 works as expected. Moreover, glfw3 & OpenGL3 works as expected too!
Now I wonder what is wrong/different, when one (like me) use \application_templates\glfw3.cpp as a start
I will investigate further later this week.

That is extremely odd. Glfw just sets up the host window and some OpenGL stuff but this should not have any effect whatsoever on mathematical computations on the GPU, especially with OpenGL3 core profile.

Did you say the application_templates with glfw3 is always broken, already as it is in the repo?

Ident wrote:That is extremely odd. Glfw just sets up the host window and some OpenGL stuff but this should not have any effect whatsoever on mathematical computations on the GPU, especially with OpenGL3 core profile.

Did you say the application_templates with glfw3 is always broken, already as it is in the repo?

I think it is broken.

My configuration is:
MS Visual Studio 2017 Community, glfw-3.2.1, glew-2.1.0, other dependencies is downloaded as package from https://bitbucket.org/cegui/cegui-dependencies/get/v0-8.zip. Everything is built as debug version using CMake GUI 3.13.3.

********************************************************************************
* -------- START OF ESSENTIAL SECTION TO BE POSTED ON THE FORUM -------- *
********************************************************************************
---- Version: 0.9999.0 (Build: Feb 20 2019 Debug Microsoft Windows MSVC++ Unknown MSVC++ version 64 bit) ----
---- Renderer module is: CEGUI::OpenGL3Renderer - Official OpenGL 3.2 core based renderer module. TextureTarget support enabled via FBO OGL 3.2 core implementation. ----
---- XML Parser module is: CEGUI::ExpatParser - Official expat based parser module for CEGUI ----
---- Image Codec module is: SILLYImageCodec - Official SILLY based image codec ----
---- Scripting module is: None ----
********************************************************************************
* -------- END OF ESSENTIAL SECTION TO BE POSTED ON THE FORUM -------- *
********************************************************************************

Steps to reproduce:

• Create new project "Classic Windows application"
• Replace VS stub with code from cegui\application_templates\glfw3.cpp
• Change OpenGLRenderer to OpenGL3Renderer in the code (3 lines, 5 occurences)
• Add all appropriate include folders
• Add all appropriate lib folders and libs
• Build
• Copy all appropriate *.dll's to executable folder
• Copy \cegui\datafiles\ to executable folder\datafiles\
• Open application_templates.layout and replace its contents with
  

  Code: Select all

  <?xml version="1.0" encoding="UTF-8"?>
<GUILayout version="4" >
    <Window type="DefaultWindow" name="DefaultWindow" >
        <Property name="Area" value="{{0,0},{0,0},{1,0},{1,0}}" />
        <Property name="MaxSize" value="{{1,0},{1,0}}" />
      <Window type="TaharezLook/Button" name="Button" >
         <Property name="Area" value="{{0.1,0},{0.05,0},{0.2,0},{0.15,0}}" />
         <Property name="Rotation" value="x:45 y:0 z:0"/>
      </Window>
    </Window>
</GUILayout>
• Run

The output:

And setting angle to 90 does not make the button invisible.

At the same time, samples framework + hello world +
gives:

which is also skewed, but in right way (perspective). Also, renders the widget invisible, as expected.

Looks like the projection matrix is wrong.

I will check it later today

So, I figured what is wrong exactly.
Either in glfw template, or in samples framework everything is the same. Sorry for misleading.
The rotation depends on Area property. I use

and set

produce skewed. Use (as in Hello world)

produce nothing (good). Use

skewed, but if I set rotation to

produce nothing (good).

Moreover, I feel that setting the pivot does nothing or little. I will try to locate the bug.

I've built CEGUI with Directx 9 and tested rotation. The results are identical.

Ok so at least it is consistently wrong.

I don't quite get your examples with the rotation. Are you saying that the sizes on screen affects skewedness?

I reproduced your examples with prebuilt 0.8.X CEED editor:

(Converted from to quaternions, as CEGUI serialises it)

-->Skewed


And now with



--> centered window is not skewed

Yes, the size / position on the screen affects rotation in general.
For example, use intact HelloWorld example. In

set a rotation to 90 degrees around x-axis,

launch, and you will see nothing. It is right behavior, as we discussed earlier.
Now, change vertical (axis perpendicular that of rotation) size to anything except 0.5f to move center of widget from center of root element:

you will see skewed widget.
Change vertical position to return center of widget to center of root element:

Nothing renders. So the rotation center (axis-wise) should match center of root (?) frame.

If hierarchy is complex, the situation gets complicated and I can't figure if there is a way to rotate a widget properly. The complex hierarchy means even another square shaped and root-centered frame that contains rotated widget.

Also I tried to use setPivot(), but has not succeeded.

Sorry if I'm not clear enough and thank you for your help!

Yes, that is. You posted while I was writing
My thoughts for now:
The transform matrix looks good to me, checked it in OpenGLGeometryBufferBase::updateMatrix().
The bug is renderer independent.
It is connected with wrong rotation pivot.

Sorry, i was editing my post while you were writing.. this got a bit confusing now.

What I wanted to add is: what I observed there was a totally normal and expected distortion as given by a perspective projection. We do not use a orthographic projection here.

Just as an example, I went into a famous and popular proprietary game engine, which I shall not name here because it does not use CEGUI , and just rendered a quad there rotated by 45° around X and moved it sideways, while the camera was facing it perpendicularly (before rotation).
Here is a gif showing this:



Therefore: nothing wrong with how CEGUI renders this.

Back to CEGUI and OpenGL (etc.) - I did not test the pivot because there is no property for it and I personally find it insane to set a pivot per widget who is gonna keep track of the pivots and positions like this? Did you actually set one for the widget? It should work if you set one, I looked into the code and it is used properly afaik but I did not test this.

So what exactly would you have expected instead of the perspective project Cizion? Maybe you should try setting an orthographic projection matrix instead? Could you explain your expected behavior further?

You can change the projection in cegui/src/RenderTarget, look for glm::perspective. At least that is what we use on default branch. Might be a different method on 0.8.X but should be in the same area and I think you get the idea.

Suthiro wrote:Is this bug or expected behavior?

Ident wrote:..what I observed there was a totally normal and expected distortion as given by a perspective projection. We do not use a orthographic projection here.

That was the question! And my initial guess was about projection matrix, so

Suthiro wrote:.. played with glMatrixMode(), gluPerspective() and their friends..

but I have not thought that CEGUI uses its own projection matrix, and was changing things outside, after renderer initialization.

Ident wrote:You can change the projection in cegui/src/RenderTarget, look for glm::perspective. At least that is what we use on default branch. Might be a different method on 0.8.X but should be in the same area and I think you get the idea.

Thanks! I'm not sure if I will change projection matrix or use current setup, but at least I do understand now what is going on and where to look.

Ident wrote:So what exactly would you have expected instead of the perspective project Cizion?

I would expect 2D GUI system using an orthographic projection .
And may I wonder what/who is Cizion?

Ident wrote:I personally find it insane to set a pivot per widget

Nothing ventured..
I will test pivots further, I suppose everything is ok and I just used it wrong.

Thank you again for your help!