Royal-Tracer

Project-Setting

The “Royal-Tracer” is the product of my “Software Project” of the fifth semester in my Computer Science studies where my team and I had to develop a raytracer including an editor. As my blog post already covers a big part of the project setting, I will only focus on the technical aspects in this article and invite you to read my blog post first.

Kick-Off

From the beginning of the project, two points were clear: we wanted to use C++ as well as OpenCl (“Open Standard for Parallel Programming of Heterogeneous Systems”). With this setup, our goal was to achieve an optimal performance that supports GPU acceleration while staying independent from the user’s hardware. While these decisions already made it more or less clear what the environment for the raytracer will look like, we still had not decided about how to realize the editor. After some discussions, we chose a web editor for these main reasons:

• Backend and frontend are separable and can run on different machines.
• No installing process for the user at all.
• Editor can be used on all devices with a browser.
• Product can be showcased easily via the internet.

Nevertheless, this decision also lead to the necessity of a complex architecture for connecting the web editor and the raytracer. We will have a closer look at said architecture now.

Overall Architecture

As we already separated the editor from the raytraycing backend, we also wanted to keep this mentality for the rest of the architecture and tried to build the structure as modular as possible. Our main goal was to keep the editor and the raytracer completely independent and exchangeable from each other. Other supportive components (storage system, parsers, …) were implemented in this way as well. Our chief architect Niklas described our overall architecture like this:

The project was designed with two architectural paradigms in mind: the microservices architecture and the component-based design paradigm. Former describes that the software can be separated into two processes that run independently: the editor and the backend. Latter means that the software can be divided into components that offer their functionality independent of the architecture they are embedded in, and that system-wide functionality is achieved by connecting these components with one another. The backend can be divided into two more sections: the Middleware section and the Raytracing section. The architecture of the backend is based around a combination of the Mediator and the Facade pattern. Facades are used to encapsulate components, that is to ensure that no calls are to be made to subcomponents from outside and that no subcomponents can make calls to outside the component. This means that components can be smoothly replaced with other components as long as their facades adhere to the same interface. To further enhance the scalability of the architecture, a Mediator is placed right into the center of the design; it is responsible for mediating between the components. This means that the complexity of component-to-component communication will not increase with each new component added since components do not communicate directly but through the Mediator.

Let’s make an imaginary workflow through the architecture to make the underlying ideas even clearer.

A user would set up a scene with some 3D models in the web editor. When he wants the scene to be raytraced, the web editor sends an according request to the backend’s webserver. The webserver, which has also retrieved the necessary models, textures and settings, makes the according call to the mediator which then finally accesses the raytracer. When the raytracer is finished, the mediator will give back the resulting image to the webserver which finally sends the image to the editor.

To make this process as smooth as possible, many optimizations had to be put into place. One of them is for example that an object which is loaded into the editor will be directly sent to the backend to reduce loading times when the raytracing process is finally initiated by the user. This is where the resource storage system and the parsers come into play as well. To keep it simple, we will skip these supportive systems and have a deeper look at the editor instead.

Editor

The structure of the editor is built around the Model-View-Controller pattern which is well known and established for all kinds of software products containing a GUI. In our case, we combined the MVC with the Obersver pattern which is also quite common to keep the view updated to any changes in the model. In our web-editor, the model is in charge of storing the scene data which will be displayed by the view. As the view became quite complex pretty fast, we had to separate it into sub-classes. In terms of the inspector, which is used to edit the properties of scene objects such as 3D-models or lights, we further splitted it into a Composite. This pattern helps to reduce the complexity for the view to handle the inspector as there are different inspectors for all the different scene object types.

Overall, the architecture for the editor ended up looking like this:

Additionally, here’s a sequence diagram which depicts a typical workflow of a user interaction with the editor:

Backend Webserver

For the backend webserver, we used the C++ framework Crow. It supplies three API endpoints that are used to communicate with the editor:

• PUT /api/obj/<id>:
  • Stores the given object from the request body in the backend.
• DELETE /api/obj/<id>:
  • Deletes the object with the given ID from the backend.
• POST /api/export:
  • Initiates the raytracing and returns the resulting image in the response.

The framework also supports the handling of multiple parallel requests which came in quite handy for the realisation of our animation-system. Basically, it only needs to send a separate request to the backend for each frame.

The component that is still missing now is, of course, the raytracer itself. As there is already an in-depth documentation by my colleague Malte who developed most parts of it, I invite you to check out the architecture description of the official documentation of the Royal-Tracer. There, you can also find an even more detailed description of all the components we already discussed in this article.

Also, check out our website royaltracer.com where you can see our raytracer in action and you can test it by yourself!