– 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 🙂
