Search This Blog

Problems with map display...

I spent a total of about 4 hours trying to find out why my map wasn't displaying properly.
Turns out there was nothing wrong with my code, or my shader, the problem was in the imprecision of the floating point numbers used to scale the UVs and the default use of sRGB color space by blender.

(top left) This is similar to what I was getting, obviously not right, but I couldn't figure out why.
(top right) Using data from the map each square is given a red color from 0-255.
(bottom left) There are 16 possible arrangements of tile and the red color offsets the UVs of that tile by a set amount.
(bottom right) The rather unimpressive final base result.

When scaling UVs Blender avoids imprecision in floating point number by just rounding up to a more suitable number, so 0.0625 becomes 0.063. This is fine usually, as you don't really care about pixel perfect placement in most applications. But when your total image is only 32 pixels across it can cause issues as 1 divided by 16 is NOT 0.063! Easy to solve, I had to add a second modifier after the offset to correct the rounding. But I didn't even know about this problem until I had solved the second one...

Blender uses sRGB color space by default. This is fine as nearly every application does these days. But the above method relies on linear color distribution, each color must map exactly to its true value or the offset will be wrong. This was solved by switching color management for the offending texture to simple RGB color space. Sadly the setting for this is hidden away in a collapsed tab in the texture settings, so I only thought about it after a lot of time wasted modifying code and testing other solutions.

So finally, the map display works. However... I'm not sure I like the result. :(
It's great that I solved the problem though as I can use this method in Vinland 1936 for texturing the terrain.

Comments

Post a Comment

Popular posts from this blog

I'm going back to my real time tactics project, Vinland 1936.
While working on the other project I overcame the problems which were stopping me from saving/loading the game and also cleaned up the base code a lot.

After a few weeks I'm getting near the the state I was in before.

Infantry are back to their previous state, and vehicles are running OK.
This time I'm going to push ahead with mocking up the combat system though before I work any more on the vehicle builder or graphical aspects of the game.

I finished working on the code for adding foliage and having some extra time I decided to experiment with the code for rockets.

The original idea I had was that rockets would be large vehicle components that can be fired very quickly, regardless of how much manpower is used for reloading.

They would use up a lot of ammo, so they would run dry after a short but devastating barrage.
The problem here is that it's easy to take advantage of this by adding a lot of ammo, which is much smaller than in bulk than the rockets.

There's also the problem of firing large caliber rockets. In real life rockets of up to 30cm were used, but I think that will be too powerful for the scale of combat in this game.

lol. Somehow that one trooper survived the mother of all explosions...

A 30cm rocket could contain nearly 30KG of explosive. That would be a very large explosion.

I've tried to balance the game by using a simple equation to make bigger guns more powerful, but hopefully not too powerf…

I've been working a lot on the game recently and I've nearly rebuilt it to the level it was before. Past that maybe, since now I have the beginning of a working combat system and the ability to save and load the game.

Infantry can now occupy a building. It's quite an abstract representation, since they stay at the door and turn invisible. But they can then fire from one of the windows and take damage from shots at the windows too. I think I've set it up well so that when building damage and destruction is working then the system should continue to work.

For combat I tried some new ideas, but they didn't work out that well. It seems that it's important that viewing range should be further than shooting range. Now shooting range is pegged at 18 units of distance, while viewing range can extend out past that.

In the above image one unit has an officer, so has further viewing range. The other can only see as far as they can shoot, a dangerous situation since the en…

Pickledtezcat

I'm an English teacher living in South Korea, I'm married and have two young sons, which makes it rather difficult to devote much time to my projects, but whenever I can I try to sit down and write some code or make some content and keep on building my dream.