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.
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. 🙂
Try to create the instance using Vulkan 1.1, but fall back to 1.0 if necessary
Does exactly what it says! Turns out that without explicitly installing new graphics drivers, most Windows installation only support Vulkan 1.0 out of the box. Vulkan 1.1 is already preferred, but in no way needed, so we can easily fall back for the time being.
– do not use blitting when copying pixel data for selection purposes – only copy the single, pertinent pixel – Convert remaining C-style enums to enum classes – Do not try to forcefully re-draw before the marker rendering data has been updated
Happy new year! This commit message may not sound very exciting, it is fixing the issue of the input not working properly on Windows though, so check this out in all its glory:
This is a binary that was produced via cross-compiling and worked out of the box on Windows. It still feels weirdly choppy in comparison to running it on Linux (same machine) or even running the Windows binary on wine using Linux, but I’ll get it eventually. This opens up the possibility of actually providing more or less regular builds using some sort of poor-man’s CI, let’s see what 2020 brings. 🙂
– specify the right shader type when setting the push constants for the model pipeline – transfer the dummy texture data to the right image layout type, even if it is unused
This fixes some Vulkan errors/warnings, nothing particularly exciting about that, besides that Vulkan is sometimes surprisingly lenient.
– use the same cmake changes as for cross compiling when doing native windows builds – make sure to always pick discrete GPUs, if available – properly initialise the maximum number of descriptor sets for the model pipeline – increase API requirement for Vulkan from 1.0 to 1.1 – properly pass device features when creating a logical Vulkan device – when allocating aligned memory under windows make sure to only pass alignment values that are powers of two – change the buffer sharing mode from concurrent to exclusive (for now, ensure there are no problems due to that)
Hello! This required to set-up a complete development environment under Windows, after throwing away the somewhat naive hope of being able to simply run the cross-compiled binary, it required a fair but of debugging to be able to run. After setting up the environment, most tasks revolved around Vulkan specific issues, that made me seriously wonder how some things worked under Linux in the first place, only one memory issue was an actual platform issue and luckily pretty quickly solved. 🙂 At the end of this we finally run OLives under Windows, albeit without any selections, besides the UI. It is also pretty crash-happy, but it starts!
– Refactor names of enum class members to camel case – Move some more existing enums into enum classes – Fix some implicit VkImage => vk::Image conversions – Do not use plain C types (ushort/uint) – Fix mingw build
A little respite before going for the finish line of the door/window project. This commit is not all that exciting sounding, but this enables building OLives for the Win32 (64, actually) target again. With some tweaking it is actually building again, however, it does crash when trying to fully initialise the Vulkan code. Hopefully there’ll be more to report in form of a screen shot soon. 🙂
– Apply the same selection colour to the portals as the surrounding wall piece – Re-work how selection states are shown on models (use the extra flags as opposed to piggy backing in another variable) – When hiding portals altogether, do it in the vertex not the fragment shader
Now, when hovering over a portal (door/window) the same mechanisms are triggered as if the user was hovering over the surrounding wall. Additionally, the hover state handling was improved quite a bit, so that the portal models now also reflect the current state. As the portals are drawn like any other model, these changes also affected how the object preview models are drawn – a nice side effect as how the selection state was brought to the shader was more than a little hacky until now. Visually it does not look like much, but a nice improvement nevertheless, check it out below:
– Implement a way to detect when an object moves from one logical tile to another – Parse and pass through vertex colour values from the IQM loader to the shader – Implement hiding of vertices with an rgb value of (255, 0, 0) which will be used to hide certain vertices in doors when an object passes through (WiP)
The TODO list about portals keeps getting shorter. This commit paves the way for hiding doors (and not the door frames) while the surrounding wall is fully drawn. This is/will be realised by hiding certain vertices, namely everything except the door frame when an object passes through them. This commit provides the building blocks for that by
Making it possible to define and use vertex colours in models
Providing these colours in the door model (turns out that was not a fun exercise in blender)
Building a mechanism that tracks when objects move from one logical tile to another
For the time being this state is currently always enabled to test the hiding mechanism, it currently looks like this:
