CEGUI (Crazy Eddie's GUI) Forums

Hiya folks. I've just started using CEGUI for my project and I've reached a point where I'm not sure how to proceed and was hoping for some guidance from more experienced users. What I'm trying to create is a node graph like system where the user had the ability to connect nodes together however they want. To give you a visual example of the kind of thing I'm aiming for, here is a screengrab from filterforge which uses the kind of system I'm trying to create:



So far I have a master frame window which contains the graph (in the example image above this is the equivalent of the grid background) and then each node in the graph is a child frame window of the master, and each node can contain various other child windows/widgets depending on its function. So far so good. Where I'm stuck now is the best way to go about creating the node links (the lines that connect the different windows together). Does anyone have any good suggestions on how I could go about doing this?

I am trying to achieve something similar and whilst it's possible in 0.7.x with some custom drawing code and/or workarounds, it's not ideal (everything from your list is easily achieved except the connecting links).

We are improving rendering capabilities of CEGUI for 0.8 to make this painless.

What render system are you using? You could perhaps draw the links yourself.

Thanks for the reply Kulik. I'm currently rendering with OpenGL, well SFML 2 really but that is an OpenGL wrapper and I'm not shy of doing stuff directly in OpenGL. Is it possible then to grab the main frame windows render target and draw my links directly into that using OpenGL between the CEGUI doing its own render and being displayed to the screen? Could you give me some pointers on the correct way to do this? Also how easy is it to relate points on child windows into co-ordinates within their parent window so I can correctly place the links? Thanks for the help, I appreciate it

Yesterday evening I did a proof of concept demo of one technique that would enable the kind of thing you are after.

Basically what it entails is using a custom Window subclass (for my test I used FrameWindow) and a custom GeometryBuffer subclass that you can use to perform rendering at an appropriate time. The code and such is pretty simple, though perhaps not something that's easy to come up with initially. What I intend to do is to write it up as a Wiki article, so that the information is readily available for all who need to use such techniques.

One thing to note is that the article will be solely about the rendering mechanics, and not for example about how to manage the links between windows and such. But I get the sense that this is not an issue for you, once you get the rendering side up and running.

In the mean time, here is a video of my test / demo app in action.


CE.

Thanks for the feedback Eddie. Your vid shows pretty much the exact type of thing I'm trying to create so I'm looking forward to your wiki article . I'll keep an eye on the wiki and do some looking into geometry buffers and such in the mean time since I'm not familiar with that part of the SDK. Cheers.

Ok, for yourself and anyone else who comes across this thread, the related Wiki article is here:
http://www.cegui.org.uk/wiki/index.php/ ... right_time

HTH

CE.

Thanks a ton for this, I really appreciate it. I've just tried it out and it works brilliantly. There's just one minor issue though which is that if the linked windows are children of another window, then the link lines get drawn behind the parent window and so are obscurred. It's not the biggest problem and I can probably use a work around for this but if you have any ideas for a solution that would be cool.

The issue you describe is caused by the z-ordering of the windows, and the fact that the lines are drawn at the same layer as the 'source' window, which means when you later interact with the target of that 'source' window, it is given higher priority in the z-ordering and hence overwrites the line.

There are some solutions / work arounds, though as with all things, none will give 'perfect' results in all cases - it's actually hard to think what perfect would look like due to the nature of the windows. For example, if the line crosses another window, should it be above the window, below the window, or perhaps the line should deviate around the window? It all depends...

Anyway, the couple of ideas I will give here basically play with the z-ordering of things so that the lines get drawn at least on top of what they should be (and perhaps on top of what they shouldn't be, but that - IMO - is another issue ).

The first - and for my money - 'best' option is to manually manage the z-ordering of the windows. What this means is that you disable z-ordering on the windows, and then arrange (or create) in such a way that what I refer to as 'source' windows are always 'above' their target windows.

To disable the z-ordering, you call Window::setZOrderingEnabled with false, and to arrange windows in the z-order, you use the Window::moveToFront, Window::moveToBack, Window::moveBehind and Window::moveInFront functions (or you could create the windows in the appropriate order, from back to front, but this is highly prone to error!). In the code from the demo app, we would put dst1 right at the bottom, with main above it, and then src1 and src2 above that.

I think this gives good results, with the trade off that certain windows will always appear above others when overlapping - this said, I think that in a lot of cases that actually makes sense from a UI perspective anyway.

The second approach involves rendering the lines to a different queue on the RenderingSurface. The main change to make this happen is to substitute the ctx.queue in the Window::drawSelf override with, say, CEGUI::RQ_OVERLAY. With this done, lines will be drawn over the top of all windows - which in my opinion, makes this slightly less 'nice' than the first approach, however, depending on your exact needs, you might prefer it.

HTH

CE.

Thanks again for the feedback and sorry its taken a while to get back in touch.

CrazyEddie wrote:The issue you describe is caused by the z-ordering of the windows, and the fact that the lines are drawn at the same layer as the 'source' window, which means when you later interact with the target of that 'source' window, it is given higher priority in the z-ordering and hence overwrites the line.

I dont think this is the issue. In my setup I have a FrameWindow which acts as the main editor window which contains nodes which are LinkWindow's that are children of said main editor window. The nodes can then target other nodes within the same main editor window and thus draw lines between each other. If I was to move a node over an already existing link, or another external window over the main editor window, then I understand how z-ordering would obscure the lines. However using the LinkWindow setup you suggest what actualy happens is that the link lines are drawn behind the main editor window itself even though the LinkWindows and their targets are all children of the parent main editor window and thus should all have a higher z values. Do you know how I could go about getting the link lines to render correctly when contained within a parent window since at the moment I've resorted to rendering them in the Overlay which isn't ideal.

There's also a second problem too. In my setup, if I then select another window such that the main editor window looses focus then the link lines dissapear until I give the main editor window focus again. I imagine this is due to the main editor window render surface getting cached which hans't included the link lines (this could be due to me having moved the link lines to rendering in the overlay, I'm not sure whether this caching artifact would still happen otherwise). To get around this I'm having to invalidate the main editor window each frame to ensure the link lines get drawn but this obviously has a performance penalty so isn't ideal. Do you know of a better way to get around this?

My appologies, please disregard the above post. Almost immediately after posting I've realised what my issue is. Although I've turned off the AutoRenderingSurface on the LinkWindows I hadn't done it for the parent frame window. This solves the issues above without having to use the overlay or explicitly invalidating the gui.

Whilst I'm posting though there is one remaining issue. When used within a resizable or scrollable parent window like I'm doing, the link lines will continue to be drawn outside the surface of the parent window if the child link windows scroll off the side. At the moment my plan is to clip the lines against the parent window before rendering in the geometry buffer. Just thought I'd ask if you had any better ideas for how to solve the issue.