Widget-based rendering back end

(Using Dear ImGui to dynamically configure my own widget framework)


During the last few months, I’ve also redone how rendering should work. The crux is still the same though: rendering is widget-based. It’s all OpenGL 3.3, as that’s all that my decrepit laptop can handle.

An application state controls a root widget. The root widget is the root of a hierarchy of containers, buttons, text boxes, list boxes and tile grids. Each widget stores “renderables”: the description of how to render themselves. Typically, one for widget body, one for widget margin, and one for the text layer. So, when an application state needs to be rendered, it asks from the root widget to be rendered, and the rest happens organically.

Renderers and Renderables in the framework

A renderable is a description of how something should be rendered. Like a “material” in UE/Unity. It stores a reference to a renderer that knows how to render it. Widget renderables have access to the widget for vital parameters, and also know where they should be rendered. For example, tilegrid and tilegrid selection renderables both use the tilegrid widget to access the size of the grid displayed, the pixels per cell, etc.

A renderer is the object that contains the logic for rendering a single type of renderable. A renderable type can be rendered from many renderers, while a renderer type can process a single renderable type. For example, a basic renderable can have information about a texture and a colour, and we could have several renderers that can generate an image using different shaders and parameters.

There is also a group renderable with the associated group renderer: A group renderable contains a map< layer , renderable> and the associated renderer processes the layers in order. This allows adding multiple passes, for example for post processing effects or multiple render layers for the tilegrid.

Now what?

Well, what I’m doing with the above is effectively preparing a rendering framework so I can easily write tile grid based shaders at will, to try all sorts of different effects and visualizations 🙂 But there’s still framework work to be done (obviously)

Leave a Reply

Your email address will not be published. Required fields are marked *