GSOC 2019 Final Report - The Terasology Foundation's The render DAG enhancements
Let me start by explaining what this project has been about.
The rendering pipeline of Terasology's had been undergoing major re-factoring for a past few years before this GSOC. When I got to it, it was already based on a graph of rendering nodes and consisting of a solid code-base for queuing graphics API calls, neatly abstracted data representation and centralized data management systems for working with them. Despite all this, the render graph still lacked node to node data flow concept as it only used aforementioned centralized system, hard-coded data-links and so on. Dependencies were therefore hard-coded with no way to work with them dynamically. This was one of the main blockers for moving all rendering nodes to a module so the render graph can be entirely built only from module-based nodes. This was one of the main goals - modular rendering pipeline. Hence this project was based around architectural re-factoring of the rendering.
Planned deliverables vs final product in the course of action:
After the project acceptance and some general planning the main goal had been set on "moving all rendering nodes to separate modules - BasicRendering and AdvancedRendering". In order to be able to do this, I first had to draft a way to represent data dependencies between nodes. All this (and all architectural changes - i.e. except modules) had been drafted under pull-request https://github.com/MovingBlocks/Terasology/pull/3732. So I came up with a concept of dependencyConnections. Laying foundations for these connections, reworking main classes for RenderGraph, WorldRenderer and all nodes used in this process, took me first month. Second month was dedicated to moving all nodes into respective modules and most importantly rewriting whole pipeline to run on the new architecture without any drawbacks/changes in the graphical fidelity.
Another goal we wanted to achieve was to introduce reusable nodes which would enable compositing. Though this seems like something rather useful in the future when there is a UI to mess with the rendering pipeline in the game, it turned out, during the second half of the project, that there were more pressing issues and sadly did not fit the scope. I tried to provide some generic methods for coder-friendly inserting of nodes into a specific place in the pipeline but I quickly bumped into layer of problems which will yet have to be solved. Though if you take a look at my dagTestingModule branch linked below, there is a tinting submodule that you can use to tint buffers. This is one of the areas that will require more focus in the future.
Speaking of more pressing issues, one of the things I deemed really important during the last month was configuring the rendering modules in game. Providing a working proof of concept for managing rendering modules took me most of the third month's time and is a part of the aforementioned PR.
I'm personally quite happy with the amount of working code I've ended up with. Since getting around the huge code-base was a little intimidating and every new concept required working with A) previously unseen part of the code and B) a lot of issues my mentor and I hadn't foreseen. I'm a little sad I couldn't manage to create some examples of how to use this by module creators together with a guide, but this is something that will come sooner or later when it's time.
I would also like to thank Vampcat, Cervator, eviltak and others for volunteering their free time to help me and this project.
All my changes and repos in order of priority:
New personal testing module repository:
All links for this project:
Relevant images of a Sketchboard I used to get around and a provided UI for rendering modules configuration
Last Edit by Dave2S on August 26, 2019