Commit 3ddf1620

Show picked device and some further debugging output to the renderer

Resolves #54


Hi! Unfortunately I noticed some issues trying to start the Windows build that it dies when trying to allocate a buffer. Without doing some proper debugging however it is basically impossible to say what is happening, as such I add some more debugging output to the renderer.

Riveting stuff. Let’s hope it will help to narrow the problem down!

Commit 7ca8a863

   Apply local light levels to objects (WiP)

   Relates to #45


Hello! After doing the same for both the floor tiles and wall pieces, the same technique is now applied to generic models. As is visible in the video below, this is done on a per-vertex basis and not for an entire object, as otherwise models that are in-between two tiles with substantially different lighting information would look more than a little odd (looking specifically at you here, door and window models).
The whole thing comes with the big caveat, that this still only supports a single set of light information per tile and obviously the calculation of these light values per room is still little more than a stub.
Be that as it may, it still is a nice step forward and doesn’t look too bad either 🙂

Commit e6c7919a

Apply the tile local light information from the storage buffer to wall tiles (and simplify some of wall vertex draw code)

Relates to #46


Hi! Continuing the work on the previous commit, now not just the floor tiles, but also wall pieces properly use the globally available lighting data. The tricky part here was to map the vertex data to certain logical world tiles, as this is somewhat more complicated case than the floor tiles, which in their very nature are exactly that.. tiles. 🙂
Anyway, here’s wonderwall a short video of what that looks like in action:

Next up: doing the same for models, as they would still get the same global lighting information, even when standing in a room right now.

Commit 46754ef8

Introduces shader storage buffers to make world (lighting and temperature) information available on shaders and uses the information

Relates to #44, #45, #46


Hello! While the commit message does not sound super exciting, this is actually the basis of any upcoming work for light/temperature visualisations, as a proof of concept this has been now implemented for a very narrow case: just for the floor tiles and not taking any artificial light sources into consideration.
What hasn’t changed since the last commit is the temporary implementation of the light calculation for rooms, which is just applying a static offset to whatever the “outside” value is.

As you can see here, as soon as a room is closed up the lighting of the floor tile changes, as well as changing back to the “outside” value as soon as it is opened back up again.

As mentioned above, this is only a proof-of-concept for now, so the next steps will be also applying the same data for wall tiles and models, both of which will require a different way to map them to to a given tile, in order to take lighting information from it. Once that basic functionality is working in all three cases (walls, floor and models), I will look into support artificial light sources, which should result in a single implementation for all three cases.

Not mentioned in the commit message were fixing a bunch of smaller bugs and some linting warnings. 🙂 Hopefully the next commit should be a matter of days, not weeks, like this one since a fair share of research and trying went into this one. I for one can’t wait to see this topic through to finally get some sorely needed visual improvements. 🙂

Commit 7ce10c22

Add mostly dummy implemenation of per-room light and temperature calcualtions (adds most required variables and functions), the actual calculation per-room is the dummy part

Relates to #43

Hello! This pretty verbose commit message is basically saying just that, the proper “framework” of functions to introduce these new values (and update them) was added, values are also already calculated but their main characteristic is currently just to be “different from the outside values” in order to see if they update properly.
That being said they are obviously not used anywhere yet, so the next step is to actually make use of them, see what needs to get changed for that in the rendering process and finally do the proper calculations. 🙂

Commit 33f39c39

Make wall auto hide mode depend on room detection

Resolves #41

Things appear to be moving quickly today, as mentioned in the previous post, the logic that decides whether a wall should be drawn in a “lowered” state has been changed from checking if a tile behind a wall is, well, not grass to check if it is actually in a room, meaning “not outside”.
While the initial approach worked “well enough” in most cases, the before and after screenshots below illustrate the crucial difference:

Before
After

So before that change, you better did not forget to put tiles down on every outer tile or you would be unable to see what is behind. All better now. 🙂

Commit 18c957eb

Complete the room detection code (for building walls only, removal is WiP)

Relates to #22

Hi! This fully implements (at least after testing it for a few minutes and everything looked fine) the logic necessary to handle room detection after building new walls.
Below you will see three different scenarios, the first one is how it handles a room that was built on its own, the second case uses one of the existing walls and in the third, arguably most interesting, case is a new wall which separates the existing rooms (at once), which turns two detected rooms into four.

The text below each picture is just a screenshot taken from the log output. Next up, handling the removal of walls, which should be relatively quick and easy with this logic in place already. 🙂