Comments

Cognitive orbit

Taking a break again from picture math and from being a weather god. Never a dull moment around here.

Here’s a little part of a feature we call Sense Overlay. The gist of it is, the world will have interactable objects marked by outlines and in some cases orbs. While interactions with visible objects are placed within world space, other senses (smell, hearing) that do not have a pinpoint location are placed in an orbit around the player’s head. Because if you happen to be a humanoid, that’s where most of your sensing happens.

This concept art depicts your sense of smell being a bit… saturated by your surroundings.

Here’s a very early go at programming it, along with a bit of clipping. Devlogs are never complete without a bit of involuntary clipping.

You press Tab to call up your Sense Overlay which includes the selection ring becoming an orbit of sense orbs (affectionately named Hula and Halo by the programmers). This was a quick update, more on those bad boys later.

Also. After a motherboard crash in the studio, I got to work on my crappy little laptop for a while and decided to give up my beautiful render-to-mask highlight system. Rendering the whole scene with replaced shaders and edge-detecting the result in post-process seems to hog up a bit too much GPU time, even after several optimizations.

We are aiming the game for oldish hardware as well and thus might have to make do with the good old mesh extrusion method. Will have to review the asset creation pipeline because those sharp edges are going to be a pain.

Any ideas on efficient silhouette highlighting when your model has split vertex normals?

Comments

Picture math

Hi there! While the background renders are coming along, I’m taking a break from being a weather god to explain the Glorious MulTan Map (® ™ etc).

Everything in this post is black, white and red because it’s raining and I’m feeling particularly noir today. Cool

Baking the background for a pre-rendered game isn’t as straightforward as it used to be. For instance since we want to use real time lights we can’t just bake shadows into the background. Say if you illuminate an area in shadow with a flash light a render with baked in shadows will not have enough colour information to properly light up.

So. We have to split our background up into separate colour and shadow components. This is actually great because it will give us a chance to swap shadows based on the time of day. To do this we render our background map at three different times of day and with a very neutral overcast light. All together 4 versions.

Here’s our overcast render (neutral map) vs a moody morning map.

We render these into floating point EXR buffer files to keep as much information as possible for shadow map extraction. The following is how we extract the shadow component from our morning, noon and evening renders.

Stand back and hold onto your hats, we are going to do…

P i c t u r e   M a t h ! My Word!

Since our goal is an image of only shadow information we need to take one of our daylight renders and remove from it all information about geometry and texture (which in our case is the overcast neutrally lit render). We tried to do this step via subtraction to get an additive shadow map but the maths gave us an image with a whole lot of (mostly inverted) colour information in there as well. This is bad because we want to keep all colour information only in the neutral map since that’s where the final colour correction and brush strokes paintover pass happens.

Dividing the renders instead of subtracting gave us exactly what we wanted. A mostly colour-agnostic multiplicative shadow map. Beautiful.

Here’s the resulting map featuring the main problem in red:

All pixels in this image illustrated in garish red are values above 1. Pretty much every surface facing the sun is lit up into super high values because we’re dividing the daylight map by the darker (smaller) value of the neutral map. If we were to just clamp values at 1 we retain shadows but lose all information about anything that’s brighter than the neutral map. This would essentially work but look super bland. We can do better.

Here’s A/B between the clamped shadow map multiplied by our neutral map versus the original morning render. Should look similar but all the sunlight is grayed out by our clamp. Not nice at all.

This is how multiplicative maps work. They only make colours darker.

In order to not lose shading information in the range above 1, we would either need to use a floating point file format (no thanks, let’s stick to png), misuse the 8 bits of png channel as a floating point value or somehow squeeze it nonlinearly into the 0 to 1 range. Since the last two are virtually the same, let’s just avoid the brainhurt of bit juggling and go with the squeeze.

Looking at functions that could pack our (0 to possibly infinite) values into a 0 to 1 range, arctangent function looked like the most obvious choice. It starts out as a one to one (0 equals 0) accordance and loses resolution as values go up.

That’s exactly the kind of squeeze we need. Except for the poor little pi in there but that’s nothing a little math can’t get rid of.

More picture math!

Here’s the tangentified shadow map in its full grayed out glory.

Looks as flat and dull as the neutral color map but that’s because our mortal eyes can’t process infinity. Blink

The above is what is going to be used in engine. The game takes the map and does reverse math to unpack it to its full infinite range before multiplying back onto the neutral map.

Picture math galore!

Images in the above calculation are two blindingly uninteresting maps that, using a single function of trigonometry, combine to form our juicy clear morning sunshine.

To my surprise, from the tests I’ve run so far, the loss of arctan map resolution in the upper values has yet to manifest itself in any form. Highlights are fine, dark objects are fine, in light or shadow.

Oh look, it stopped raining! I can snap out of noir now.

We repeat the above process for all three times of day and get three separate shadow maps which we combine into the R, G and B channels of a single image file. Here’s what our shadow map looks like after being packed with morning, noon and evening shadows.

On the left is our old method which just took Cycles’ shadow pass (just plain binary soft shadow/light without bounces) and on the right the method described above. The former might look bright and clear but the new method carries much, much more subtle lighting information from render to engine.

I love picture math. Picture math makes pretty. Hand Shake Left Hand Shake Right

Comments

Peculiarities of Eastern European game development

Time for an update. Also, hi.  Gentleman

I am the programmer who is kept busy by the needs of the writers. I make the dialogues tick. If I had a card, it would say “Systems Designer”, but it is a made-up name. I’m a university-grown systems administrator/lecturer-turned-programmer (I still work in TUT). At some point I’m probably also show our rules system and then I get to talk about my background with D&D and larp.

Bootstrapping the Writers

I have been working on the project since August, but a lot of it has been what I’d call explorative programming: you hack on something, get something working and at the same time develop ideas of how they should work in reality.


This is how a writer likes to work (and yes, this a fragment of our office in warmer times; I just burned wood to make it slightly warmer as there’s still a winter outside and we burn wood to make it warm). Note that due to Articy being Windows-only, the visible laptop has been replaced with a less Mac one.

My current goal for the past three months has been bootstrapping the writers. We need a way of testing and playing through the mass of dialogues while building an engine. So: for the writers to be productive they need both a way to import them into dialogues and also a finished-looking dialogue windows which behaves like they expect. So they can see when their own dialogue does not behave expedtedly.

Articy: Draft 2

During the early days of the project we understood that we have neither the time or resources to create our own dialogue producing program. We dreamed about Obsidian’s tools; looked into Chat Mapper, Twine and then settled for Articy:Draft 2 from Nevigo.

Chat Mapper had severe interface problems (it’s extremely “clicky” program and it requires you to click around a lot while lacking keyboard fluency); it also looked slightly uneappealing like it could break at any minute — it meant that we met some resistance with selling it to the authors.

Twine was interesting, yet it wasn’t exactly forthcoming — we needed something else.

We went for Articy: Draft 2, since the writers liked it and we as programmers also liked it — it has a strong templating system, has support for cooperative editing with its lock/unlock logic and seems stable enough for our needs. The interface of the program has been designed to be flexible; there are annoyances like when invisible dialogue windows appear and lock it up, but all in all it’s a solid piece of software. It is also really graphic-heavy: your small mobile graphics-processor will not zoom out your full-sized dialogue tree.

If I was a single-person programmer/writer I’d recommend the program highly since its solo license for an indie is absolutely adorably well priced. For slightly larger dev-teams and text heavy rpg-s I’d be extremely cautious, as currently I have three writers an occasional editor and occasional myself, who share the trio of lower-priced floating licenses and it’s getting rather crowded, as you might imagine. If you are well-funded I think the software is the way to go: Think of the full price per seat at your max cast before commiting to the software.

On the image above you can see a smallish dialogue. From Articy we export to .xml. We tried and looked into Articy:Access and it is a nice thing for what it does, but since our import pathway goes through a Unity tool called Dialogue System, we passed on the opportunity of spending more (remember our frugality: I burn goddamn wood to keep my fingers flexible). That brings us to the:

Dialogue System

Made by Pixelcrushers; it is a tool for Chat Mapper and Unity integration and maintains feature parity with it, but since it imports well from Articy and the dev is one of the most friendly-helpful support persons you can meet, I think that this choice is solid. You can trust Dialogue System to show dialogues for your custom RPG. It even includes the source, but so far I have only read it to understand some of the intricacies of its inner workings.

After importing from the Articy, we had to make some adjustments to the behaviour of some dialogue lines: in essence, and this will be a separate text, we have some new ideas of how an RPG check system should work and this means that there is some processing that is done on every dialogue line to see if the line is seen by the user and if the line has some side-effects on the stats or story. Basically any ability checks are handled using a custom interpretation of Dialogue System’s lines. For the technically inclined: we use and abuse OnDialogueLine and OnConversationResponseMenu to their full potential.

Writers Tool

This is what I have been building for the writers so that they can import their .xml into the game without ever running Unity. It has a list of dialogues which you can run. Currently it also contains an amount of testing-out-stuff and Estonian comments. It also shows our dialogue window, as it stands as of now. From this tool we, at some point, will change the dialogue variables.

You can also see the current in-progress state of our dialogue UI. There will be an eerily cool dynamic background to it which has been programmed, but still needs some integration.

So now the writers have begun playing through their dialogues and I occasionally laugh myself to tears when reading what they have made.