We are looking for OpenGL wizards with C++ abilities! 🧙‍♂️️

We are looking for someone who can help us to finish our portal implementation, especially the blending of portals with other textures.

The Dæmon engine is a game engine written in C++ historically based on id Tech 3 (the game engine that powered Quake III long time ago). But 20 years later, the engine is not the same and a lot of things evolved or were rewritten. On the rendering side, the OpenGL renderer was inherited from XreaL, a project that attempted to bring new technologies to Quake 3-derived engines.

The Dæmon engine is the game engine powering our game, Unvanquished, a free and open-source game mixing FPS and RTS elements in a real time strategy game shooter opposing human forces and aliens fighting for the survival of their respective species

Our greatest current need is for an OpenGL developer with C++ knowledge. For other positions, see the Join us page.

If needed, we have some less critical but easier renderer tasks that can be used as exercises to dive into the Dæmon renderer code.

Our Modern OpenGL renderer

While Quake 3 had a “Legacy” OpenGL 1 renderer, we use a “Modern” OpenGL 3-and-later renderer. An OpenGL 3 renderer is exactly the same as an OpenGL 4.6 one, the difference is just a matter of making some features required or not. So, unlike our distant Quake 3 ancestor, our engine uses current rendering technologies.

Despite the fact the name looks similar and only the version seems to differ, OpenGL 1 and OpenGL 3-and-later are very different, and renderers implementing them are very different pieces of software. To avoid confusion, we will call the OpenGL 1 pipeline (lacking programmable shaders) “Legacy OpenGL”, and OpenGL 3+ “Modern OpenGL”.

We can compare the differences between “Legacy OpenGL” and “Modern OpenGL” with the differences between Modern OpenGL and Vulkan (whose initial name was “OpenGL Next”…). One has to rewrite a renderer when migrating from Legacy OpenGL to Modern OpenGL, exactly like one has to rewrite a renderer to migrate from OpenGL to Vulkan.

That means our renderer is definitely not the one of Quake 3 any more. It’s a very different piece of software, but at the same time, we need to be fully compatible with the original one. Why? Because we want to keep the compatibility with the thousands of game levels (maps) that already exist for Tremulous. Tremulous is Unvanquished’s father, originally a Quake 3 mod. Any Tremulous map is already an Unvanquished map and we deeply want to keep that compatibility.

We maintain a list of regressions, and if we ignore some minor regressions that may even not be noticeable or that have easy workarounds, portals are among the last couple of regressions left in the list of “regressions that may make the game look broken”.

To answer to some extra questions that may be asked:

• We don’t need to migrate to Vulkan. Modern OpenGL is perfect for our needs. Not only it brings us all the features we want, but in fact with some backwards compatibility tricks the engine even runs on OpenGL 2.1 devices like the Radeon 9700 PRO from 2002, while being fully compatible with the very latest OpenGL standard and being fully supported by the very latest graphics card on the market that would require you to buy a 1000W PSU… It means that with Modern OpenGL not only our engine is compatible with two decades of hardware, but also provides all the features we want (and may provide even more). If one day someone implements a Vulkan renderer, this renderer would have to live next to the OpenGL one, so we need to fix the OpenGL renderer in any way.
• There are very good reasons why the engine moved from  Legacy OpenGL 1 to Modern OpenGL 3-and-later. Bringing back the legacy renderer for a single feature is not an option, and in fact it would bring even more regressions as our renderer also implements many new features we heavily rely on, and more than portal blending.

That’s why we are looking for “Modern OpenGL” developers to help us. Our team is currently too small to work on this task as everyone else is already busy on other tasks.

Missing portal blending

One of the last regressions we want to address is the missing portal blending. Our game engine implements texture blending in advanced ways (something Quake 3 did better than Doom 3 to be honest), meaning a material is more like a script, where multiple rendering stages are blended together with various operations and graphical effects.

Portals are simply a view of some place in the game level rendered over a surface in game. If you see in game a TV set with the screen displaying another part of the map, like a camera, you are looking at a portal. If you see a mirror and you can actually see yourself in the mirror, you’re looking at a portal.

For years, the portal implementation in the Dæmon engine has been mostly an unfinished proof of concept. We can grossly describe the current implementation as “let’s fully render the game with all features then paint the portal over it”. It works for the simplest 90% of uses cases—that’s why there was no urge to do better before.

But this is not good. It means we can’t blend a portal over a texture, nor a texture over a portal.

For most use cases, the lack of such blending feature is minor: if you want to simply blend some dirt texture over a mirror, as if the glass were not clean, well, you’ll get a very clean mirror without dirt, one can live with it.

But if you want to render a subtle reflection of the room over a clean floor, all you will see is a perfect mirror instead of seeing a subtle reflection over a floor texture. This is very bad and the rendering of the game level will be considered broken.

Besides portal blending issues, some other problems have to be tackled, like some portal sorting issues, likely consequences of the fact our current implementation is still mostly a hack.

Some work on the portal code has been done this year. This work improved the support of portals in multiple ways, like enabling recursive portals (mirrors can now mirror other mirrors). This work also finished the parsing of portal materials, but this is not enough, we now need to blend them.

By finishing the portal implementation, one may understand better how things work on portal side and maybe also help to fix our water reflection and refraction shader.

Because our game engine is based on Quake 3, it may be possible to look for friendly projects to see if some OpenGL3+ portal blending implementation exist and if there are things to reuse or port, or simply to use as a hint.

Development environment

Both Unvanquished and the Dæmon engine are free and fully open source software and are entirely maintained by volunteers. We are then looking for volunteers. This is an unpaid position, we have no money. All we have is fun!

Contributing to Unvanquished and the Dæmon engine is done entirely through the Internet, each contributor being part of a community mostly active in our chat and on our GitHub projects.

Our OpenGL 3+ renderer is very deeply tested on a wide range of hardware, systems and drivers, and it’s probably not foolish to claim it’s the most actively tested open source renderer for id Tech 3 derivative engines. Not infrequently, we find bugs in OpenGL drivers, which we either report or implement specific workarounds for. Our OpenGL 3+ renderer is also known to be strongly compatible with id Tech 3 formats, and we deeply test it against hundreds if not thousands of legacy game levels. Portal blending is among the last things we miss to claim full compatibility.

Our team is small but dedicated. All the people invested in Unvanquished and the Dæmon engine are already busy working on other tasks, that’s why we are looking for new contributors on the renderer side of things. On the topic of renderer work, new contributors would report to illwieckz, while slipher would have jurisdiction for anything related to C++ wizardry.

In addition to finishing the portal implementation, a developer would have the opportunity to explore other topics, like fixing our water shader (assumed to be related to portals),  debugging our PBR code (we don’t use it yet because we don’t trust it yet), reimplementing real time shadows for our new tiled renderer, fixing automatic cube mapping,  implementing sRGB lightmapping, implementing Warpzones like Xonotic does (it’s more a gamecode task though), or simply implementing new cool features to push the Dæmon engine forward.

After finishing portal blending, the next priority for us is finishing our PBR code. This task is assumed to be way simpler so it can be picked by someone being less confident, or as a first exercise to dive into the Dæmon engine renderer code. Finishing our PBR code will enable us to use the thousands of ready-to-use public domain PBR textures that exist out there.

Finishing the implementation of portal blending is a priority for us because that’s considered a regression by players. With time our community of players grows and hundreds of maps get ported, meaning we have now many example of played maps that suffer from the lack of that feature, both from Tremulous and newly created. So our players have frequently complained about portal bugs and would greatly appreciate a fix.

Our current greatest need is a need for an OpenGL developer with C++ knowledge. We also need sound designers, translators, etc. See the Join us page for details.

Let’s play!

The Dæmon engine is a game engine and Unvanquished is a game, so we are there to play games! It’s also a good way to meet with our community,  familiarize yourself with the game, and then understand our needs. Also, it’s fun! That’s what games are for!

Until we publish the next release (coming soon™) we recommend joining the Der Bunker and Map&Bot Testing servers since they are the most actively maintained servers and bring very useful backports and upcoming features.