– Ensure light sources are spawned at the right elevations – Limit navigation to tiles of a certain level height differences (<= 0.5) – Refactor some height map function to get rid of code duplication
Hello! This relatively quick commit further fleshes out the height map mechanics, it pretty much is simply what it says in the commit message. Prior to this the light sources were always spawned at the same height, which made things looks more than a little wonky as soon as different elevations came into play. As you can see below things work more or less as expected now though:
Besides that an upper limit was introduced in what is still deemed a valid tile candidate for navigation. Next up will be limiting tiles (and edges) and which objects (and walls) an be placed. So far, the height map progressing nicely. Byeee 🙂
– Ensure that objects are drawn at the right elevation – Ensure that preview models are drawn at the right elevation – Ensure that portal models are drawn at the right elevation
Hi! This latest commit is really about replacing the existing code to determine the exact elevation at an arbitrary point, as the code in place never quite worked as intended. While doing so I already fixed some other problems that I noticed while testing that, namely handling the (vertical) positioning of models and portal (door/window) models. Check out the final result:
Obvious problems with the animation that is clearly meant for flat terrain aside, I’m pretty happy with the result! If that doesn’t put a smile on your face, you may want to check out the video below which would belong on a blooper reel if there was one.
Next up is modifying the pathfinding to ignore inclines deemed too steep as well as properly positioning light sources when adding/moving objects that spawn one. Byeeee. 🙂
– Change the height map from a tile based to a vertex based approach – Refactor the get/setElevation in various classes accordingly – Refactor the tile drawing code accordingly (and have it generate actual normals) – Move more elevation related code from the World to the HeightMap class – Add stubs for some of the more high-level elevation functions – Fix usage of the ambient light direction in model and wall shaders
Hello! This commit gives us quite a bit to talk about. It was a bit dragged out as some of it was quick and interesting to do, other parts of it boiled down to extremely annoying off-by-one bugs, but in the end it worked itself out.
To give this whole endeavour (once again, a “milestone” in GitLab parlance) some context, the idea and partial implementation of a height map happened more or less exactly three years ago. Ever since then the whole topic was not exactly very high on my priority list, so it remained in its half implemented limbo. In preparation for some upcoming topics it was probably for the best to finally elevate (get it? get it?) its priority and get down to it, which included touching some code which, at this point, was basically as old as it gets in OLives.
So far, the only thing that is working is actually drawing (and hard coded manipulating) the vertices, while stubs for higher level methods do exist, they’re unimplemented as yet, let alone being exposed through a UI. To give you a better idea where this is at, check out this screenshot:
The astute reader might also notice that the “human” model is now looking a bit more three dimensional. This is due to a fix to in some shaders for a regression that was introduced during the “le there be light” milestone, so with this commit the couch model is no longer an amorphous blob, but once again recognisable as an actual object. Small victories and all that.
Next up will be properly handling these elevations when placing objects, walls and build markers. After that, the UI will be built and finally the code to actually do those manipulations. Hopefully the next few tasks will bring a bit more visual fidelity, so stay tuned. Byeee 🙂
Hi! This commit adds the last big building block of the temperature milestone (in GitLab parlance). While at first heat pumps are a fairly technical concept, in the concept of temperature in OLives they also make a lot of sense, if you put an aircon unit somewhere, that exhaust heat has to go somewhere:
What made this tricky is that so far, the temperature modifiers operated under the assumption that there is an absolute target temperature. The exhaust temperature modifiers however need to work with a relative value. With every object that is marked as heat pump, not only one, but two temperature modifiers are being created. The first (primary) is created for every temperature modifying object (like the radiator), the second (exhaust) is marked as inactive as long as the first is not responsible for any actual temperature changes and its value gets updated as soon as the primary modifier is causing a different effect on its own tile. This fit rather neatly into the existing concept, so even cases like the one below look weirdly nice:
I’m pretty happy to have this task behind me and I’m fairly happy with the result, next on the agenda is, probably, fleshing out the height map concept, which kind of exists in OLives, but hasn’t been touched in two years and is not exposed to the user at all right now. Stay tuned for more, bye. 🙂
Hello! This is the second of two quick fixes that really annoyed me while testing. Due to a unfortunate chain of circumstances the object navigation was sometimes reset in a way that caused a code branch to run that was trying to pop off an element from the upcoming navigation candidates when it was already empty, implicitly creating a new node with X and Y values of 0 respectively. What happened next is that this was assigned as the next position and magically the object was teleported to (0, 0). Not anymore. Time to get to the last ticket regarding the temperatures, which might be a bit more complicated than the previous ones, but let’s see. Bye 🙂
Hi! This is just one of two (hopefully) quick commits to fix some issues which got a little annoying while developing. This fix in particular addressed a regression which was recently introduced as I added a new stating buffer for room tile information. The buffer itself worked just fine, it just so happened not to get applied once the new room information was determined after adding new walls, which in the visually resulted in fully-drawn walls, even though they should have been lowered, as they were covering up a newly created room. Anyway, that’s fixed now, bye. 🙂
Hello! This commit wraps up the enabling/disabling and “changing settings” mechanics, mostly by adding actual animations for that. Also, some code in Python that will select the correct animation depending on the object type that is interacted with was added. You can see what it looks like now below:
Please take special note of the excellent editing at the end of the video
This almost brings the whole temperature saga to an end, the only still missing are the heat pump mechanics. After that it will be time for some bug fixes and then it will be time for the next bigger topic. Which one that will be I am still deciding, I have thought of same rather exciting (at least for me) candidates already, so stay tuned. Byeee. 🙂
– Make the same changes to the enabling/disabling logic for temperature modifiers as for light sources – When determining the logical tile from model vertex data, make sure to apply the animation to the vertex
Hi! This commit was mainly about applying the same more generic approach to disabling/enabling as was already implemented for light sources in the previous commit. While doing so I had a bit of a minor epiphany about a lighting issue which can be observed in this screenshot:
What happened here is that when trying to determine the light situation in a vertex’s environment, the animation(s) was/weren’t applied to the current position yet. Since the “neutral” position for the vertices which are way too bright here is actual further away from the model’s torso, they are actually on a different tile, at least as far as the lighting logic is concerned. Luckily, fixing this was as simply as applying the animation. 🙂
Speaking of animations, next up on the never ending todo list is fixing the still-looping animation when enabling, disabling and changing settings on an object. Bye. 🙂
– Extend the AbstractObject and AbstractLight python classes to support enable/disable events. – Extend the LightInfo class (+ Python counterpart) and the LightInfo struct in GLSL with an active/inactive flag – Based on that, implement enabling/disabling light sources for togglable object types
Hello! This commit is basically self-explanatory, it is now possible to turn light sources off and on. To be more precise, that means objects which are both marked as togglable and have a script that implements the AbstractLight class. While implementing that, I realised that this generic approach makes a lot more sense, so I will also move the “setting the temperature” action to something very similar before moving on with the actual animation for both. Once that is all done, it might even make sense to post a quick video again. Who knows. Byee 🙂
Hi! This rather innocent looking commit changes the way the internal mapping of objects to their respective temperature modifiers works. As has been previously mentioned, so far that was only supporting a single object that has a temperature modifier per tile, which would probably lead to complications and made calling some functions a bit awkward. This has been rectified now, the real star of this commit though is changing the text on enable/disable buttons to “Turn on” and “Turn off” respectively, as that rather sounds like what an actual person might say. Byeee 🙂
