Horde3D

I hate UI stuff. Really hate its fiddly crappy fiddlyness.

So I was glad to hear that one of the more useful UI libs has gone properly open source. Librocket (www.librocket.com) has its roots in HTML/CSS which of course means its obscure and alien to right thinking programmers, but on the other hand, it does the job of creating a UI that doesnt suck and is pretty damn flexible (which is why the HTML/CSS crap is still around).

I wouldnt necassarily use it for all my in-game UI requirements. But it will do the job for the menu system at least. Which was frankly starting to become a pain and thats BEFORE I got into the meat of list boxes and such.

So sometime, probably end next month, I'll get LWGL, Horde and Librocket to play together and will happily release whatever I can. Once thats done I'll migrate my engine to the new system (if it doesnt completely suck) and continue on.

Thought I'd share the news that librocket is open source, it feels like it might be a good system for flexible UI design.

That's pretty cool - I always wanted to give LibRocket a spin, but the old licensing terms put me off.

_________________
Tristam MacDonald - [swiftcoding]

Did you release that already? I couldn't find anything in the wiki or on the librocket forums (and they seem to be pretty eager to push examples like that), but there is something Horde3D-related on the frontpage of librocket.
I'm having some performance trouble with rendering librocket - probably because I'm doing it wrong.

Hi,

I have done it.
I have created a render interface for libRocket using Horde3D.
I have it working using Overlays (but the overlay limit needs to be increased).

I am playing with scene nodes now to get it working that way, as Overlays don't have a color per vertex and also because of the overlay limit.

I'll be uploading it to libRocket by this weekend.
I'll put a link to it here, later...

Regards,
vikingcode

This is very good news, vikingcode.

Looking forward to your interface.

I spoke too soon.

I have discovered that libRocket geometry cannot be rendered properly by using the Horde3D API alone.

I was able to get it partially working with Overlays and partially working with scene nodes.
With Overlays the geometries were drawn in the correct order but I was having problems with small geometries, which were not aligned perfectly (slightly rotated).
I was able to correct this problem by using scene nodes, but that then gave me the problem of z-ordering. Once I worked out how to fix the z ordering so that the libRocket geometries would be rendered in the correct order then I really discovered the fundamental problem that will not allow libRocket geometry to be rendered correctly with Horde3D.

The problem is clipping. Even though I could get the geometries rendered using scene nodes, the clipping is unable to have any effect on the rendering.
libRocket calls the methods EnableScissorRegion and SetScissorRegion to define the clipping area, and then calls RenderCompiledGeometry to render.
So the problem is that Horde3D renders everything in the pipeline, which is long after the scissor regions have been set for every libRocket geometry.
Hence it is impossible unless the libRocket render interface changes the render method to include the scissor region, even then, would it be possible? Can it be done in the shader?

Anyway...
So I am re-implementing it using openGL VBO's for the actual rendering and Horde3D to load textures and keep original geometry.
Basically I will be showing how to implement libRocket rendering partially using Horde3D combined with openGL VBO's.
It will also demonstrate how to use GLFW with libRocket and how to (post)render with openGL in a Horde3D application.

It would be nice if openGL and it's extensions could be accessed via Horde3D.

Would it be feasible and useful to add new functionality to Horde3DUtils for creating and destroying VBO's?
If so, can the openGL commands (and extensions) be accessed internally from Horde3D API?

Regards,
vikingcode

PS. .. Nearly finished ..

As soon as you need a more complex interaction with the rendering pipeline, I would definitely recommend to create an extension (see the terrain as example). From an extension you have full access to the Horde internals including the device layer (OpenGL). Having an extension helps to keep all the rendering code in one place and will also make things a lot easier for users that want to take advantage of the librocket integration.

I was wondering if you succeeded integrating libRocket with Horde3D. If you did, could it be possible for me to have the code? I am currently trying to do it without much success... Thanks!

While that would be great, a half-finished, hacked-in demonstrator would be great as well for now.
The only real option for a GUI is to use this and while I certainly appreciate it, it's not really all that great. Librocket looks nice.

Like marciano said it's probably best to put librocket at the extension-level for greater access to Horde's internals. Maybe use that GUI extension code to study how it made the extension but replace it with librocket, that would be rocking...

_________________
-Alex
Website

Do you want code? Or just a demo screen with some rocket GUI rendered on top of the Knight sample?
If you want code, I need this week to finish off my latest re-implementation. I don't really want to release the code that I have using scene nodes or overlays because it won't work properly this way.
I started to hack in my own openGL implementation but decided to work on making an extension instead. With an extension I can use the geometry resource VBO's.



Yep, working on it. It is the only way it can be done actually. Otherwise you can't get hold of the VBO data from the geometry and texture.
Sorry for taking so long.. Every time I have discovered obstacles, I have had to make quite dramatic chabges to my code structure.. I have some personal dramas too that have limited my time during the last few months.

I cannot see a way to render the libRocket geometry in the (a) pipeline. (Can anyone else?)
As I said before, Rocket internally calls the scissor methods to set the clipping, and then directly makes a call to the render method.
It may be possible to setup some hackish way of doing it, such as every time the scissor method is called I could set some variable, and then every time a geometry is rendered I could assume that the previous scissor region is for the current geometry. But is it actually possible to attach a clipping region to a geometry? From what I understand, Horde3D only clips to the window, not per geometry or mesh.

Since starting this project I have learnt so much and taken so many turns! I'm beginning to understand pipelines and shaders.

Regards,
vikingcode

Hi vikingcode,

To make it work for the pipeline, I would make my own XML tag <DrawLibRocket> or just <DrawGUI> and add specifications to it, I guess study how the different rendering calls work in egRenderer and adapt a libRocket-specific draw. Shadow map rendering heavily uses glScissor to set up the different cascades as an atlas onto a single texture so I guess you'd use this approach with libRocket... I'm not sure if Horde's extension mechanism is flexible enough to add your own render methods and pipeline stages, you'd have to ask marciano or Volker on that one...

_________________
-Alex
Website

No it is not. The pipeline is predefined. It is part of the core.
But if I am wrong, someone please explain.


I looked at the pipeline already and realised that it would have to be hard-coded, hence it would not be an extension.

Regards,
vikingcode

For a simple first integration, you could do the following:
- Create an extension which provides a "RocketNode", e.g.
Use the terrain extension as a template.
- Now decide, if you want to have several RocketNodes in your scene graph which all belong to some UI element or if you want to have only one RocketNode which renders all UI in this single call (maybe to textures/render-targets or on-screen)
- Renderer::drawRenderables will call your RocketNode::renderFunc. You then loop over the queue and fetch all RocketNode nodes and render them
- If you want to have one specific point where RocketNodes should be drawn, add a stage into your pipeline like this
and make sure that you check for the correct class "RocketNode" inside RocketNode::renderFunc. This way your nodes will be ignored during the normal opaque-stage drawing or the translucent drawing.
If you decide to have only a single "RocketNode" inside your graph then RocketNode::renderFunc could render the complete Rocket UI with SFML (make sure you push/pop render states) and would then be orthogonal to Horde's normal rendering.
We used this approach for our own debug drawing nodes (e.g. for bullet physics).
We created a DebugDraw extension, added only one real DebugDraw node to Horde's scene graph.
Then we have functions like h3dextAddDebugDrawSphere(..) or h3dextAddDebugDrawCoordSys(..) which then register themselves at the DebugDraw node as new debug element.
We also added a rather hacky h3dextAddDebugDrawCallback function where you register a custom callback inside your application.
This way we could re-use Bullet's GLShape/DebugDrawing code using normal GL calls instead of trying to fit all this into Horde's (rather static) geometry setup or mess with VBOs.

I know I would be happy with a proof of concept hack like that. I haven't touched my horrible implementation in months.

Meanwhile at the librocket forums