Mr Poc


"Mr.Poc" as we pronounced it, was the Minimal Renderer Proof of Concept for the project that would later become Dataflow. During the block another graphics student and I took it upon ourselves to learn the ins and outs of the GLTF2.0 file format and with that creating a PBR renderer that would be able to render the custom maps from our visual artist(s) in order to make them feel at ease in the heavily influenced tech environment.

Group members: 1 artist, 2 graphics programmers
Platforms: Windows
Span: November 2020 - January 2021
Software: Visual studio, Blender, Maya (Babylon export tool), Perforce, Jira.
Roles: Graphics programmer/scrum master (More on this topic is described/noted on the Dataflow project page)

My responsibilities as Graphics programmer:

- GLTF2.0 loading and scene hierarchy.
- Normal mapping.
- PBR shading.
- The art export pipeline setup for our visual artists.

My responsibilities as scrum master:

- Designing and integrating the Jira workflow, through time logging by the team, watching and managing team velocity and grooming the backlog with the product owner.
- Managing standups
- Communicating deadlines to the team and communicating these effectively with the product owner.

Image context: Mr Poc rendering a procedural environment that went through the asset pipeline from our visual artist: from Houdini, to Blender, to the custom renderer. The scene is unlit, meaning that the PBR is not really shown here.


Takeaways and processes

The main takeaway from this project is that it's best to get the project setup and running as soon as possible, through effective use of the available resources. At the start of the block me and the other graphics programmer had no clue how to setup a renderer that would be capable of PBR or GLTF, which made it hard to handle task division appropriately.

Throughout the block we tried to mitigate this through taking the most straight forward implementations on the internet, together with the lectures provided by Buas, however we still did not have the most effective workflow.

In the end we did manage to push out a working asset pipeline for the VA's, which is shown on the images of this page. The pipeline went from Houdini, to Blender, which then exported the model to GLTF for the renderer. The renderer is capable of diffuse PBR shading, using ambient/point/directional lights provided by the GLTF.

If I were to change the approach we took this block I would've changed the task division between the other graphics programmer and I. We worked together, which caused stress and task division issues at the start, since we both wanted to learn and implement the same features all the time. A potential solution could've be: one programmer does shading theory and implements those, while the other does the back-end programming. This way we would've never clashed on the same feature issues, thereby wasting time and getting stuck on each other's work. Since we still wanted to learn the same concepts we could've planned meetings in which we revised the theory/structures we had worked on.

The next step was to move this renderer into an actual engine and adding an agnostic graphics API in order to interact with the specific graphics API we were using. More on this can be read on the Dataflow page.