Gorilla - minimal hud and overlay replacement for OGRE

[betajaen]

Gorilla? Isn't that a monkey?

Nope, Gorilla's are primates.

Gorilla is a 2D drawing engine for Ogre, which can be projected into 3D space, or onto the screen as a 2D overlay, it comes in two files Gorilla.cpp and Gorilla.h. Gorilla is intended to substitute the Ogre overlay system, and to provide a good framework and basis for any Ogre programmer to build their HUD or GUI system upon.

Screenshots and Videos


[youtube]e78Hfo5rIyU[/youtube]

Features

Gorilla is designed for speed, thus it uses Texture Atlases, Caching and tries to render everything in one batch. Gorilla screens can be either in an overlay form (2D), or attached to a SceneNode (3D).

Gorilla can draw the following types of shapes:

• Filled (Solid, Gradient or Sprite-based) Rectangles (Canvas Rectangles)
• Outlined Rectangles (Canvas Boxes)
• Lines with n-thickness (Canvas Lines)
• Sprites (SpriteLayer Sprites)
• Plain and formatted text (Canvas Captions and Text)

Gorilla only uses Ogre as a dependency, and is developed with Ogre 1.7 in mind; but should work with any 1.x version. It works on Windows, Linux and OSX, and even iOS with the provided shader based material files.

Gorilla is released under the MIT licence.

Hand it to my primate hands!

Gorilla comes in two files, but also comes with a sample image and gorilla file called "dejavu". Which you can download in a neat package.

Gorilla is hosted and versioned by GitHub.

I'm learning to walk!

Using Gorilla is really easy and straight forward to use.

Information can be read in the very short readme file and gorilla schema., as well as reading the header file. There is also a few examples that come with it.

There is also a mini-tutorial series by Tom Koole

Any other Gorilla's about!?

Yes! I've been converting some of the Wiki articles to use Gorilla instead, they come in that nice zip file up there.

Ogre Console

This is a port of the OgreConsole code presented by PixL in the Ogre Forums then later added to the Ogre Wiki.

This is a straight port replacing all the Overlay code with Gorilla code, some changes have been added but they are minor and do not add to the actual functionality of the class.

console_example.jpg

[haltendehand]

I don't actually need it, but it looks great - also, I really like gorillas, so...

Edit: The example text is great

[jacmoe]

Wow - I like that colour.

GUI revolution 2, anyone?

[betajaen]

GUI revolution 2, anyone?

I shudder to think what would happen if it did; We'd end up with some bizzare twisted version of Compviz in OGRE at the end. KungFooMasta would be adding fire shader effects to closing windows in QuickGUIX.

[DanielSefton]

Wow, you have no idea how much I've needed something like this!

- Can it animate?
- Is a 3D widget possible? (aka rendering a 3D viewport on the top)

Thanks!

[Rambus]

Hello Betajaen,

A very interesting library- something I could see myself using as it matures.

I have some issues with the library though, hopefully my feedback helps.

e.g.
- "vpH" as a setter for view port height. Hard to understand meaning right away, and in other portions of the code you use a more standard "setValueType" convention (setMarkupColour).
- The use over Silverback as the name of the main class (I know its a Gorilla )
- a single instance of mixed case class names, e.g. buffer vs Silverback
- Stretches overlay/canvas on screen size change (probably on purpose?) for my application I need the resolution of the overlay and the ogre window to remain 1:1. I don't see an option to do this.
- The text item gets its own class, while adding things like lines are handled by id's. It's just a little strange to have to methods of accessing objects. I'm guessing this is because you are trying to optimize objects like lines for speed of rendering.
- Not much inlined documentation in gorilla.h, but seeing as this is a first release so I wouldn't have expected much.

Now for some positives!
It took me about 45 seconds to include this library and build it into my project! The rendering speed was indeed fast. Access to simple line drawing commands is a very nice feature
Example files are very quick to build also- no need to play around with includes/libs.

[betajaen]

Wow, you have no idea how much I've needed something like this!

- Can it animate?
- Is a 3D widget possible? (aka rendering a 3D viewport on the top)

Thanks!

1. Sort of, you can move things around, change images of sprites and things. But you'd have to do it yourself, there is no system in place that does it for you, since Gorilla does a render once (not continuous renders each time you move a sprite), you can do massive changes and there shouldn't be a performance hit. I was thinking about having an option for sprites to switch to the next sprite each frame though.

2. No strictly 2D at the moment I'm afraid. If your having a weapon (for example), then you could do what I do. Is have another SceneManager/Viewport and overlay the viewport over your main one. There is an option somewhere that makes the background of the second view port transparent, so it's all seamless. But as for Gorilla doing 3D stuff, afraid not.

[betajaen]

e.g.
- "vpH" as a setter for view port height. Hard to understand meaning right away, and in other portions of the code you use a more standard "setValueType" convention (setMarkupColour).

It's an internal function. It should be protected. But if you see the amount of times I use those functions, you'd understand why I made it three characters long.

- The use over Silverback as the name of the main class (I know its a Gorilla )

It's fun. Not everything needs to be Root.

- a single instance of mixed case class names, e.g. buffer vs Silverback

Blame NxOgre for that, I stole the buffer class from it. I hear the NxOgre author is a bit mad though.

- Stretches overlay/canvas on screen size change (probably on purpose?) for my application I need the resolution of the overlay and the ogre window to remain 1:1. I don't see an option to do this.

It should be 1:1, I check to see if the viewport size has changed each frame, if has it recalculates and redraws. Everything is in pixels so it should be 1:1 regardless of the size.

- The text item gets its own class, while adding things like lines are handled by id's. It's just a little strange to have to methods of accessing objects. I'm guessing this is because you are trying to optimize objects like lines for speed of rendering.

The text is a big thing, I felt it needed it's own class. Besides if you have a large amount of text, and you need to change the smallest character then everything needs to be recalculated and changed. If I lumped it in the rest then, everything else would have to be redrawn as well. I realise there is a text option in Canvas, but it's for small things.

Either way; I want to do more things to the text class, and if I merged Text into Canvas, all the other bits of Canvas would be overshadowed by Text.

As for IDs. I have a much faster solution in mind. It does involve some C trickery, and everyone would scream bloody murder if I did do it.

- Not much inlined documentation in gorilla.h, but seeing as this is a first release so I wouldn't have expected much.

Ahh. I did all the documentation in the Readme file, I need to copy that over though.

It took me about 45 seconds to include this library and build it into my project! The rendering speed was indeed fast. Access to simple line drawing commands is a very nice feature
Example files are very quick to build also- no need to play around with includes/libs.

Yep; Speed is the number one goal.

[Rambus]

It's an internal function. It should be protected. But if you see the amount of times I use those functions, you'd understand why I made it three characters long.

They appear to be public members of Screen (In the zipped version).

It's fun. Not everything needs to be Root.

Come to think of it, I don't have a better suggestion for the name

Blame NxOgre for that, I stole the buffer class from it. I hear the NxOgre author is a bit mad though.

Lawsuit!

It should be 1:1, I check to see if the viewport size has changed each frame, if has it recalculates and redraws. Everything is in pixels so it should be 1:1 regardless of the size.

I'm talking about resolution rather than screen space (which is working).
Here is an example: http://www.g0dsoft.com/forum/scaledimagescreen.png
The resolution of the overlay doesn't update with the viewport. (in this example I increased the resolution when I scaled the size).


I don't think I said it enough in the first post- I really like the ease of use of this library and appreciate the effort you are putting in Good work!

[betajaen]

It's an internal function. It should be protected. But if you see the amount of times I use those functions, you'd understand why I made it three characters long.

They appear to be public members of Screen (In the zipped version).

I've changed it now; they are _getViewportX, _getViewportY, _getViewportX1, _getViewportX2.

It's fun. Not everything needs to be Root.

Come to think of it, I don't have a better suggestion for the name

He's the head Gorilla, of course it's going to be Silverback. If there was a name for an Ogre King, I'm sure Sinbad would of named Root to something else!

Blame NxOgre for that, I stole the buffer class from it. I hear the NxOgre author is a bit mad though.

Lawsuit!

He's been sent to bed early.

It should be 1:1, I check to see if the viewport size has changed each frame, if has it recalculates and redraws. Everything is in pixels so it should be 1:1 regardless of the size.

I'm talking about resolution rather than screen space (which is working).
Here is an example: http://www.g0dsoft.com/forum/scaledimagescreen.png
The resolution of the overlay doesn't update with the viewport. (in this example I increased the resolution when I scaled the size).

This is the "render" function, I'm pretty sure I did it right when checking for viewport changes:

Code: Select all

void  Screen::renderQueueEnded(Ogre::uint8 queueGroupId, const Ogre::String& invocation, bool& repeatThisInvocation)
{
 if (queueGroupId == Ogre::RENDER_QUEUE_OVERLAY)
 {
  
  if (mViewport->getActualWidth() != mViewportWidth || mViewport->getActualHeight() != mViewportHeight)
  {
   
   mViewportWidth = mViewport->getActualWidth();
   mViewportHeight = mViewport->getActualHeight();
   mInvViewportWidth = 1.0f / mViewportWidth;
   mInvViewportHeight = 1.0f / mViewportHeight;
   
   _redrawAll();
  }

  // Check to see if redraw needed here.
  if ( mLayerRedrawNeeded == true)
  {
   for (size_t i=0;i < 16;i++)
    if (mRedrawLayerNeeded[i])
     _redrawLayer(i);
   mLayerRedrawNeeded = false;
   _copyToVertexBuffer();
  }
  
  if (mRenderOp.vertexData->vertexCount)
  {
   _prepareRenderSystem();
   _render();
  }
 }
}

I don't think I said it enough in the first post- I really like the ease of use of this library and appreciate the effort you are putting in Good work!

Absolutely, I'm surprised how quickly I managed to develop BetaGUI with it. And Ogre Console, I did that in an hour. I spent more time thinking up witty responses to that make thing.

[betajaen]

Okay, just for you. I added this function:

Code: Select all

Screen::_forceViewportChange();

When you resize your viewport in your GUI, call this for every Screen and it should redraw itself to the new size.

[Rambus]

[s]Hello, I appreciate the patch but it looks like the bug was on my end. I tried to replicate the bug in the sample application framework but your code works flawlessly. The odd part is a resize my window with identical code in the sample framework :O. It must be something to do with the way I create my window that is not notifying the viewport of the resolution change, although it is clear the viewport does undertake such a change. Edit: Nope the viewport has the correct resolution- doubly weird

Sorry about making you extra work, as it appears your library functions correctly. test[/s]

Final Edit:
I fixed the bug (sort of) I need to for each my my canvases to do a redraw (previously a private function). Not sure why I need to do this or why it is not automatically happening when I resize my window. The regular update size code bit is being called and using the correct values for resolution.

[Rambus]

Just to show what things look like now...

I was able to easily design a widget to put DeusEx style brackets around objects + display the objects name using gorilla.


Please note:

I needed to add the following function

Code: Select all

Canvas->removeAllLines();

void Canvas::removeAllLines(void)
{
	mLines.clear();
	_redrawNeeded();
}

And on window resize I force the canvas and text item to redraw. (As it is currently not happening automatically).

[pratty70]

Love it! Gonna play with it later.

Personally I like the quirkiness of the naming convention, brings some humour into it.

As always, good work betajaen.

[Wolfmanfx]

Great! But have you considered to make it more serious and start an Canvas component which could make it in the ogre core? I mean that would be a nice starting point to add more html 5 canvas features

But that would mean more than one header and cpp file for this project iam not sure if you like this at all

Anyway nice work!

[Ockonal]

Wow, lol!
It's great, especially the name And FPS over 5000.

[KungFooMasta]

GUI revolution 2, anyone?

I shudder to think what would happen if it did; We'd end up with some bizzare twisted version of Compviz in OGRE at the end. KungFooMasta would be adding fire shader effects to closing windows in QuickGUIX.

Very cool! I'm almost ready to release something myself, but still have some issues to work out. Gorilla is a really great library because its opposite of mine and serves different needs. I think with all the GUI solutions available all users will have something that suits their needs.

(BTW if you want 3d UI you should wait for the QuickGUI post. )

[betajaen]

Thanks KungFooMasta, I'm looking forward to what your next project could be. Reading between the lines; QuickGUI 3D?

I also personally want to thank you for QuickGUI. Your brush code helped me a lot when I first learned about directly using the Ogre RenderSystem, than using a SimpleRenderable or ManualObject which was my original intention. Anyway, I wanted to give my thanks.

[Shockeye]

This looks great. Nice work.

First Beastie collision, and now this. You've been busy!

So, what accent should we say Gorilla in?

[betajaen]

Queen's English of course.

I need Beastie and Gorilla for something I'm working on, hence the releases.

[toglia]

Great! But have you considered to make it more serious and start an Canvas component which could make it in the ogre core? I mean that would be a nice starting point to add more html 5 canvas features

Seriously, I think ogre definitely needs this on the core, maybe integrating it with the overlay system? like having an option to pack an overlay atlas? Should be way cool.

I have been using ajs15822 "Canvas" lib for quite a while, I'm suspecting its the same technique? Would there be a reason for using Gorilla instead of Canvas?

Anyway! Its always nice to have many options!

I'm definitely playing with it sometime. Thanks betajaen.

[betajaen]

I'm pretty sure ajs15822's Canvas/Atlas classes just draw onto a single texture then use BSP packing, then probably uses quads like I do, but each texture is created at runtime. I was initially did this with Gorilla, and use rectangle box packing. Jacmoe inspired me to go a different direction with pre-defined texture atlases.

The only differences is between the two is Gorilla doesn't modify the texture at all, and Canvas/Atlas does.

[betajaen]

Just something I'm working on with the new Canvas code:

Code: Select all

Gorilla::Rectangle* rect = mCanvas->createRectangle(1,1,200,400, "coco");
poly = mCanvas->createRegularPolygon(500,400, 100, 8);
poly->sprite(mScreen->getAtlas()->getSprite("coco"));
mCanvas->createTile(400,10,64,200, "coco");

cocos.png

[KungFooMasta]

Code: Select all

poly = mCanvas->createRegularPolygon(500,400, 100, 8);

What do the last 2 parameters represent? I'm assuming 500 is width, 400 is height.

[betajaen]

Left, Top, Radius and number of sides.

I'm having a bit of a problem with Gorilla now. The UV and all text is rendering very horribly now, I think it's down to the texel offsets given by the RenderSystem but I'm not sure why. I need to see if OpenGL has the same problem too.

[Edit]

The moment I post this, I figure out why.

Let's join in....All together now.... "BETAJAEN'S A STUPID IDIOT!"

I forgot to clear the vertices of the text buffer every rewrite. All day I've been trying to fix this problem. Gah.