Pathfinder: Kingmaker Update #47

The latest Kickstarter update for Owlcat Games’ upcoming cRPG Pathfinder: Kingmaker is highly technical in nature. If reading about how lighting, shaders, and other visual effects come together to create an aesthetically pleasant game is your thing, chances are you’ll enjoy it.

However, if things like forward rendering and deferred shading may as well be Star Trek technobabble to you and your interest in the game is of a more general nature, you should check out this update regardless, as it has plenty of work-in-progress animations and screenshots, as well as some impressive-looking artwork and a few words about the game’s new alpha build.

An excerpt:

Dear Pathfinders,

It’s time for another peek behind the curtains. Today’s update is all about lighting, shaders, floral dispersion and all those fun details and effects, which add a bit more life to our game world. Before we get all technical and start revealing our tricks, though, we have two announcements. First of all: the stage 2 alpha test is nearly here!

Our next big alpha build is almost ready and will be distributed as an update through Steam to all alpha testers today. What does this mean for you? If you’re one of our alpha testers, you’ll be getting more content, more gameplay features, more companions and more Pathfinder: Kingmaker to play. If you aren’t part of the alpha, you’ll be happy to hear that we’re well on schedule, development is steadily progressing and there should be streams and videos of the new build popping up for your viewing pleasure in the near future. Keep your eyes peeled!

Second, we have a draft of the community achievement baron bonus portrait for you! Whew, that was a mouthful. As you might recall, we had several polls on our forums where we asked you to vote on your favorite race, class and appearance options, which were to be depicted in one new in-game character portrait. You have voted for a female half-elf sorcerer of the undead bloodline, with a touch of vampire, wraith and mummy in her appearance. Based on that description, our artist came up with something – and the result sure is creepy![…]

Now, let’s talk more about graphics in Kingmaker. We’ve already told you about our water rendering techniques. Today we’ll review a few other graphics features of our project.

Strange as it may sound, graphics development starts with market research. At an early development stage, we researched the stats of video cards on the market and chose our target hardware in order to let as many players as possible experience all graphical content we produce. Then we selected rendering technologies that would be perfect for this hardware. A lighting system is the basis of game rendering, unless the game is match3 with abstract graphics. The lighting system determines the graphics pipeline architecture of a frame, so we’ll start with that.

Forward rendering

There are 2 basic approaches to real-time lighting calculations:

• Forward rendering
• Deferred shading

And of course, there are a lot of variations and combinations of these.

Forward rendering is the most widely-used (and probably the first) technique for calculating lighting in real time in games. A model consisting of vertices is fed to the vertex shader, where its vertices are transformed to screen space, and all this data is passed down the video card pipeline to the pixel shader, where lighting happens. This is called forward rendering with per-pixel lighting.

Of course, lighting can be calculated in the vertex shader as well, then it will be forward rendering with vertex lighting. Vertex lighting is less GPU intensive, because there are much fewer vertices than there are pixels, but its visual quality is also lower.

Usually shaders that perform calculations only work with one light source. But objects may be lit by multiple sources at the same time. This means the object must be rendered as many times as there are sources that light it. This is the most significant flaw of forward rendering.

Deferred shading – as the name tells us, it calculates lighting not during geometry rendering, but defers it to the end of the frame. In this case lighting works as a post-process, which allows us not to render the same object multiple times. All geometry is rendered to a special G-buffer that contains the information required to calculate lighting. Then lighting is calculated for all the light sources, using the prepared G-buffer. This means lighting calculations are decoupled from the scene complexity.

This approach might seem much more effective than forward rendering, but it has its pitfalls:

• To create a G-buffer, a video card must support the Multiple Render Target (MRT) technology. Of course, the newer video cards do support it, but until recently it has been a significant limitation.
• G-buffer usually takes 4 render textures. If we take Full HD as average resolution, it would give us 1920*1080*4*32 bits, which equals 256MB. This much memory must pass through the video card’s bus 30 times per second if we want 30 FPS, which gives us about 8GB/s. But in fact this volume is even higher, because data can be written to G-buffer multiple times (overdraw), it can also be read during writing (blending, depth/stencil test) and so on. So, this number can go as high as 15-20GB/s. And if we increase the resolution to 4k, the load becomes substantial even for top video cards. And this is just the G-buffer, but in fact lots of other data must pass through the same bus (textures, geometry, intermediate post-process textures and so on). This puts a very heavy load on a video card, especially on average ones.
• Deferred shading doesn’t work with translucent objects, such as glass. That’s why we have to use good old forward rendering to draw such objects. This leads to a large number of shader combinations.
• Deferred shading does not support multisampling. Hence there are problems with anti-aliasing.

Having weighed all pros and cons we opted for forward rendering, but with some modifications. We will talk about those later.