1
\$\begingroup\$

I am building my world-editor for my game. I've noticed, that, no matter how i implement the heightmap, i'll end up with dumb odd numbers in calculations.

For example, lets take a HeightMap of 4x4 which covers a area of 2x2 OpenGL-Units. Thats a small image which shows the problem. The black lines and numbers represent units in OpenGL, the red lines and numbers repesent pixel/values on my heightmap.

enter image description here

You can easily see, that in the top image, every number is really odd and i actually need a lot of additional code to calculate everything correctly (OpenGL-position -> heightmap-pixel and heightmap-pixel -> OpenGL-position).

In the bottom image however, i am missing height-values for the right and the bottom row of vertices.

I thought i could just use +1 pixel for every heightmap, this would solve this problem but i am sure it will introduce problems at other ends.

How would you guys handle this?


As stated in the comments, the real problem here is, that i need to calculate OpenGL-position -> heightmap-position and OpenGL-range -> heightmap-range fairly often to draw on the heightmap and the math gets really hard to handle with the mapping as seen in the top-image.

\$\endgroup\$
  • \$\begingroup\$ Use a 5x5 heightmap? \$\endgroup\$ – user253751 Aug 2 '15 at 23:10
  • \$\begingroup\$ Yes, but as i said in my second last sentence: this would solve this problem but i am sure it will introduce problems at other ends. \$\endgroup\$ – tkausl Aug 2 '15 at 23:25
  • \$\begingroup\$ Which problems are you sure it will introduce? \$\endgroup\$ – user253751 Aug 2 '15 at 23:31
  • \$\begingroup\$ Why doesn't the size of the height-map correspond to the number of vertices in your terrain mesh? \$\endgroup\$ – Fuzzy Logic Aug 2 '15 at 23:45
  • 1
    \$\begingroup\$ Something about what you are doing outside of anything you are showing us is where your problem is. You aren't really making a lot of sense so its hard to help you out. Could you try explaining a little better? \$\endgroup\$ – Alan Wolfe Aug 3 '15 at 0:57
1
\$\begingroup\$

Don't think in World Units -> Heightmap. Think in World Units -> Model Units -> Heightmap. This is called normalization.

You will need to normalize from world units back to your model units before you try to map to the heightmap and vice versa. You can do this with some simple scale-factor, assuming that the vertices in your terrain mesh are uniform distance of 1 unit apart from each other.

Lets say you have a terrain mesh that is 100x100 vertices and a height-map that is 100x100 pixels, but you want the terrain to be 257x257 units.

Now, when you are painting with the terrain brush, you will find the world coords from your mouse position, then scale that position back down to your model units, so you get a 1:1 mapping with your height-map.

In this example, the model scale is 100units but the world scale is 257units, so that is a scale factor of 2.57

Let's say that you click on the position at {183,183,z} in world units. So divide by 2.57 and you get 71.206226... rounded, that would be vertex[71][71] (but don't round yet).

You will need to do this for the brush size as well, if the brush size is 3 world units in diameter, then divide by 2.57 and you get a model unit size of 1.167315... for your brush diameter. Knowing this, you can work on the vertices and pixels within a radius of (1.167315/2.0) from {71.206226, 71.206226}. If your brush were square, that would be {70.622568, 70.622568} to {71.789884, 71.789884}

Once you determine the bounds of your brush in model units, then you round to integer so you can index the vertices or heightmap.

Hope that helps.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.