Royal-Tracer Product Release

One of my modules this semester was the software project. It’s a module where there is a new software project each semester which is then solved by multiple groups of approximately 7 people. I was very lucky and managed to get in the group with my best friends and some other students I knew from other projects. The project for this year was to build a raytracer together with a corresponding scene editor.

One of the first tasks was to choose a fitting process model for organizing this project. As all the groups, we chose Scrum for this purpose. My team members appointed me as the Scrum master. Additionally, we used two other roles from the feature-driven development model: the chief architect and the domain expert. As we had the whole semester for it, we ended up with 8 sprints of two weeks each.

For further information about the design decisions please have a look at this conceptional description which we had to create for our documentation:

Our Mission

Our journey began with a clear goal: to go beyond the realm of basic prototypes. We aspired to create a tool that integrates seamlessly into everyday workflows, akin to the reliable and functional products already present in the market. Our mission was to bridge the gap between advanced technology and practical usability, ensuring that our tool is not only innovative but also user-friendly and applicable in various settings.

Choosing the Programming Language: Prioritizing Speed and Efficiency

One of the cornerstones of a successful software product is its performance. Recognizing this, we selected C++ as our programming language of choice. Renowned for its efficiency and close-to-the-metal nature, C++ allows direct interaction with the underlying hardware. This characteristic enabled us to optimize our tool for speed and power, ensuring that it can handle intensive tasks without compromising on performance.

Balancing GPU and CPU Rendering: Ensuring Broad Accessibility

At the heart of our project lies ray tracing, a technique that requires substantial computational resources. Typically, this is managed by GPUs, known for their ability to accelerate such processes. However, we acknowledge that not every user has access to top-tier GPUs. Thus, our design caters to both GPU and CPU capabilities. By utilizing OpenCL, we ensure dual compatibility, making our tool accessible and efficient for a diverse range of users with varying hardware configurations.

Utilizing the GPU

At the heart of our project lies ray tracing, a technique that requires substantial computational resources. Since graphical processing units (GPUs) are known for their ability to accelerate such processes due to their unparalleled multithreading capabilities, leveraging this potential was an important to-do for our project from the start. On the way we faced several hurdles like GPU-vendor specific configuration necessities or CPU utilization, which was discarded at a later point. But, using OpenCL, a framework for device-independent software, we achieved utilizing CPU-integrated graphics chips as well as top-tier graphics cards in our software.

Developing a Modular Architecture: Emphasizing Flexibility and Customization

Flexibility and adaptability were paramount in our architectural development process. We designed our system with modularity in mind, allowing for various components such as the editor, ray tracer, and storage management to be interchangeable. This modular design not only facilitates maintenance and upgrades but also provides users with the freedom to customize or enhance the tool with their unique modules or features.

Transitioning to a Web-Based Editor: Enhancing Accessibility and Convenience

Our initial approach involved a C++ and QT toolkit-based editor. However, with a commitment to enhancing user accessibility, we transitioned to a web-based editor. This strategic shift enables users to access our editor from any location, eliminating the need for complex installations. Although this move presented challenges, particularly in terms of file access and integration, the resultant increase in convenience and accessibility was a significant step forward in aligning with our mission.

Implementing Path Tracing: Elevating Realism in Rendering

To achieve visuals that closely mimic reality, we integrated path tracing into our ray tracer. This sophisticated technique significantly improves the realism of rendered images by accurately simulating complex lighting and shading scenarios. The incorporation of path tracing marks a significant milestone in our quest to deliver high-quality lifelike renderings.

Conclusion: Realizing Our Vision with a Dynamic Final Product

Each strategic decision and development phase has culminated in a tool that embodies our initial vision. What we present now is a fully-functional, real-world application, poised for continuous improvement and adaptation. Our dedication to delivering a user-centric, adaptable tool remains the driving force behind our ongoing development and future enhancements.

Even though this was only 1 of 6 modules this semester, we all were extremely motivated and basically used every free minute to invest in this project. As a consequence, we started to see progress very fast. Additionally, the team harmonized extremely well as we were not just colleagues but friends and therefore spent all of our time together hyping one another up about the project.

Overall, the project structure is too complex to present here completely but to give you an overview of my contribution to it, have a look at this excerpt of my experience report:

Scrum Master activities

In my role as Scrum Master, I was responsible for organizing the Scrum processes during the project. This included preparing for and following up on various meetings and managing the corresponding documents. Among other things, this work resulted in a detailed set of rules that can be found in the Impediment Backlog.

One of the main focuses of my work as a Scrum Master was organizing the sprint retrospective, as the team also benefited the most from this meeting. The meetings always had the following structure:

1. Iteration: What didn’t go so well in terms of Scrum/organization in the previous sprint?
   • Every team member lists their impressions in turn.
   • I noted down the points.
2. Iteration: Working out solutions to the collected points
   • Points were grouped into similar categories.
   • Together, we worked out solutions for the collected problem areas.
3. Iteration: What went well in this sprint?
   • To motivate the team, we then verbally listed everything that went well in the sprint.

Afterwards, I added the collected problems to the impediment backlog as rules.

The daily scrums also took place under my guidance. These also always had the same structure:

1. Basic regulation:
   • Daily Scrums always took place on weekdays at 8 pm on Discord.
   • If you were unable to attend, you had to sign out via Discord and write down what you would have said in the meeting.
   • In the event of an unexcused absence, a points system applied which can be found in the Impediment backlog.
2. Daily Scrum Meeting:
   • Everyone present answered the following questions:
     1. What have I achieved since the last meeting?
     2. What am I planning to achieve by the next meeting?
     3. Are there any problems?

The organization of the other two meetings, the review and the planning meeting, was handed over to the product owner after the first two sprints.

Of course, I was also the contact person for all questions relating to the project organization and Scrum processes throughout the entire project.

Overall, apart from the bureaucratic duties, the work as Scrum Master was very limited, as the team followed all the rules very well and there were hardly any conflicts to resolve.

Backend web server

My work on the backend is essentially limited to the basic implementation of the web server in the backend, which is used to communicate with the editor. This included the selection of the Crow library and the basic implementation of the API endpoints, which delegate the corresponding commands via the “middleware” to the raytracer. The web server was later expanded, in particular by our chief architect.

Editor

After our domain expert implemented the basic MVC structure of the editor, especially Timo Pfaff and I concentrated on the further development of the editor. As a number of features have accumulated here over the course of the project, here is just an overview of some of my activities:

• Lights:
  • In addition to the basic support of point lights and directional lights in the editor, this also includes the display of emmissive objects using a “bloom effect” in the editor.
• Scene import:
  • This describes the import of a scene from a YAML file. The file is parsed and the objects are created accordingly in the editor. Another option for importing a scene is to import a ZIP file. The YAML config is also read and the scene is then created using the other objects in the ZIP file.
• Refactoring and cleanup:
  • Halfway through the project, the entire code of the editor had to be refactored, as an enormous amount of code had accumulated over time for which the original structure of the editor was no longer enough. The key points were the implementation of the inspectors as a composite, the extraction of the individual page elements as separate classes and the finer encapsulation of methods that had become too large.
• Numerous quality of life features and bug fixes:
  • These activities are easiest to take from the backlogs in Jira.

Build

To create an executable build, I took care of bundling all of our JavaScript files, including all of our libraries, to reduce the complexity of the deployment. Moreover, I implemented a Python HTTP server, which then makes the editor available via a local port. Finally, I created a star script that starts both the backend and the editor.

Miscellaneous

In addition to the explicitly assigned tasks, I also was involved in the following points:

• Working on important overall design decisions
• Reviewing and testing pull requests
• Working on documentation
• Joint debugging
• etc.

Last Thursday, we then finally had our product release with a very satisfying result. Apart from satisfying all the base features, we ended up with an efficient, modular multiplatform raytracer and a web editor which even supports animations.

If you want to learn more about our product, I encourage you to visit our website royaltracer.com. You can find all the available information there.

Overall, this project was the best part of my studies until now. Apart from the newly learned technical know-how, I gained very valuable experience in working on a large project with a real process model. As already stated several times, we had incredible fun during this project and are already looking forward to continuing with it in our spare time!

I hope I can give you an update on our further progress anytime soon! Until then, have a nice time!