Jump to content
  • Advertisement

Project: Project Taival

Dev Diary #037 - Amūńe, The Old One



Hello and welcome to this weeks Dev Diary!

Today I would like to continue where I left off last week and that is texturing of the created heightmap. As it happens every so often, I had to redo the heightmap for two reasons;

  1. In order to get a more precise heightmap of the area and...
  2. To have the texture implemented as easily as possible.

After all, this is just an initial map for the game, where I can study the following; 

  1. How to make and define water 
  2. How to implement vegetation in a most efficient manner (most likely procedurally generated)
  3. How to optimize big maps for high frame rates, with as little sacrifices to quality as possible
  4. Unit styles, movement and animations etc.
  5. Building systems in general
  6. Test out multi-level camera systems

More on those on later Dev Diaries.


The New Map

This new perspective of the area is roughly 4 km² (or in miles; 1.544409mi²) in size, but the heightmap's precision is 2 meters, compared to the last weeks example's 30 meters. In other words, it is 15 times more accurate than the previous one, but there seems to be a problem still - when presented as a one huge map, Blender crashes if I try to make it as accurate as possible. This means, that I can't use all the accuracy that the heightmap has to offer with a single monolithic map. This is why I most likely need to try and divide the map into 1 km² chunks at the very least and combine them in the game engine. I'm currently planning to try this on Unreal, Unity and Godot engines to see which one is the most intuitive and easy to use. I kind of like the Godot Engines GScript language (based on Python), but the vidual programming functions make the Unity and Unreal engines more desirable currently. It will also be coming to Godot Engine, but we'll see on what timetable.

Here is a preview of the current map;

Preview 3D map from an angle.

And from a top view;

Preview 3D map from top view.

Despite not being able to use all the detail that the heightmap makes possible, it does look kind of nice. Still, I haven't touched the shaders at all, which makes the ground reflect lights like it was some kind of plastic.

To help make sens of the map and it's size differences, I'm using the Blender's grid as a tool of measurement. Many tutorials are there to just show how to make something, but most often everything is done without precise measurements, which should be taken into account when actually making the assets for your game. This ensures that you have some hard points to measure your world and characters towards, to make sure that 1 meter or foot is consistently 1 meter or foot within the game world. Command and Conquer is one example, where the scaling of buildings and units were not so accurately measured and even though it didn't bother me personally, I like to keep close tab on scales from the start to ensure that there is good fundamentals for higher immersion at a later point of development.


Tip Of The Week - For Beginners

When I first tried to implement the ground textures for the map, the color image was misaligned in Blender, even though the heightmap and the color image were perfectly aligned in the images them self. This is how the map looked before aligning them in Blender;


Last week I shared a link to the simple tutorial that I used to create this map also. The video showed, that the person in question aligned the map texture by hand in the UV editor. I found another, more precise way to align the texture to the map. Bare in mind, that this might have drawbacks that I don't currently even know.

Once you have added the texture like instructed in the video, you can align it by left clicking "Vector" on the side-panel and select "Texture Coordinate". This simple adjustment aligned the textures perfectly with my heightmap.



How does the title of this week's Dev Diary correspond to this weeks topic? You can hunt for answers or find out the answer on the next weeks Dev Diary. 

Thank you for tuning in, and I'll see you on the next one!

You can check out every possible mid week announcements about the project on these official channels;

• YouTube • Facebook • Twitter • Discord • Reddit • Pinterest • SoundCloud • LinkedIn •


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement
  • Advertisement
  • Blog Entries

  • Similar Content

    • By acerskyline
      When ever another window gains focus (the most simple way is to press Alt + Tab) on the same monitor, the game window will be forced into windowed mode. I already called MakeWindowAssociation with DXGI_MWA_NO_WINDOW_CHANGES and DXGI_MWA_NO_ALT_ENTER. And it returned success. No Alt + Enter works as expected, the default handler is gone. But the forced fullscreen state change seems can't be turned off completely. Does anyone have any better idea about this issue?
    • By bandages
      So, in real life, incoming dot normal at the silhouette is always 0.  With smooth shaded meshes, it never is, not naturally, not outside of contrived situations.  (Not with flat shaded meshes either, I guess.)
      And incoming dot normal is one of the bedrocks of CG.  Probably the equal of 4x4 matrix multiplication.  Problems with silhouette normals show up in Fresnel, in diffuse lighting, in environment mapping....  everywhere.  But I can't really find anybody talking about it.  (Maybe I'm not Googling the right terms.)
      Obviously, the problem decreases as poly count goes up, eventually reaching a point where it's dwarfed by other silhouette problems (like translucency or micro-occlusion) that CG doesn't handle well either.  But, if I'm reasoning correctly, normal maps don't improve the problem-- they're as likely to exacerbate it as improve it, and the exacerbations are, aesthetically speaking, probably worse than the improvements are better.
      I've tried playing with crude fixes-- basically, rotating normals toward incoming by a percentage, or of course clamping incoming dot normal (like we all have to do) to prevent it from bending behind the mesh.  Nothing I've tried looks good.  I suppose the best option might be to rotate normals to perpendicular to incoming at the silhouette and then interpolate to the nearest inflection point  of something like screen space depth to preserve curvature, but the math for how to do that is beyond me, and I'm not sure it would look any better.  Or maybe, instead, somehow, adjust the drawn silhouette to match the silhouette defined by incoming dot normal?  Not even sure how that would work, not if the normal was pointing away from incoming.
      I don't know-- is this a solvable problem?  Has anyone tried other stuff and given up, pursued anything that was promising but too expensive, anything like that?  Are there any papers I'm missing?  It's really surprising to me that I can't find anyone else talking about this.
      (Apologies if I chose the wrong subforum for this.  I considered art forums, but I felt that people frequenting the programming forums would have more to say on the subject.)
    • By vinibiavatti
      Hi there! I have one issue for now. I'm creating a RayCasting application, and for my floor and ceiling I'm trying to use Mode7 for rendering (I think this is easier to understand). but, I cant align the RayCasting walls with the mode7 floor. I use a rotate matrix to make the rotation of floor. Do you know what a need to think in the implementation to fix that? Or do you know if there is some tutorial explaining about it? Thanks!!! (Check the image below for understand)

      Here is my mode7 code:
      function mode7() { let _x = 0; let _y = 0; let z = 0; let sin = Math.sin(degreeToRadians(data.player.angle)); let cos = Math.cos(degreeToRadians(data.player.angle)); for(let y = data.projection.halfHeight; y < data.projection.height; y++) { for(let x = 0; x < data.projection.width; x++) { _x = ((data.projection.width - x) * cos) - (x * sin); _y = ((data.projection.width - x) * sin) + (x * cos); _x /= z; _y /= z; if(_y < 0) _y *= -1; if(_x < 0) _x *= -1; _y *= 8.0; _x *= 8.0; _y %= data.floorTextures[0].height; _x %= data.floorTextures[0].width; screenContext.fillStyle = data.floorTextures[0].data[Math.floor(_x) + Math.floor(_y) * data.floorTextures[0].width]; screenContext.fillRect(x, y, 1, 1); } z += 1; } }  
    • By DiligentDev
      The latest release of Diligent Engine combines a number of recent updates (Vulkan on iOS, GLTF2.0 support, shadows), significantly improves performance of OpenGL backend, updates API, adds integration with Dear Imgui and implements new samples and tutorials. Some of the new features in this release:
      GLTF2.0 support (loader, PBR renderer and sample viewer) Shadowing Component and Shadows Sample Integration with Dear Imgui library and Dear Imgui demo Tutorial13 - Shadow Map Tutorial14 - Compute Shader Tutorial15 - Multiple Windows Check it out on GitHub.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!