The RenderGraph

The render graph is the state optimised view of the scene in my engines, in the form of a Directed Acyclic Graph. The CRenderNode class has a "render(...)" function, used to render itself. It also has an accept method, so that the Visitor design pattern might be used, for better extensibility. The render graph is ordered into rendering steps, which have Effects children, which in turn has Renderable children, such that: Step -> Effect -> Renderable.

An Effect is only registered to one Step, and a Renderable can be registered to more than a single Effect. That was the design of OctoPort, inspired by this thread at Gamedev, but this graph representation unfortunately has some weaknesses.

First, the whole graph will be travelled through even if most of its Renderables are out of sight. A trivial optimisation to avoid it, is to store a status flag in each node, so that an inactive branch wouldn't be processed at all.

That means that if only a single Renderable is active in a given branch, the engine will loop over all the other Renderables registered to the same Effect, which might be a lot, during rendering. (Although all those inactive won’t be rendered, of course.) Since the engine is generic, and so can be used in a MMO (Massively Multiplayer Online), or a RTS (Real-Time Strategy) game, capable of having dozens or hundreds of entities registered to a single Effect, it's a major issue.

The fastest operations being those that aren't performed, the RenderGraph is not appealing performance wise, even though its design is elegant. That system suffer from another problem, should the user want to have a depth first pass, to initialise the depth buffer for the frame (and save on fragment shading and fillrate), he must tweak the system, as an Effect does only register to a single Step.

I did go around that problem by using the visitor pattern in OctoPort, but it was just a hack until I could find a solution.