Terrain too rough
Hmm, that could be I guess. But I still think the output seems about right. Could you maybe update the image to show a more zoomed out version?
It *really* looks like a quantization artifact, like hplus explained. If the piece of code you posted is correct, then it could be a problem with Ogre's plugin (maybe it converts doubles to 8-bits integers ?), or maybe you have yourself a cast to 8-bits int somewhere when submitting your data to the Ogre API ?
Y.
Y.
i don't have a solution to the problem but i wouldn't go as far as rick and say that it's alright. The terrain looks like a staircase. I also think that the problem is a result of inaccuracies of variables(like using ints) because every single vertex is lying on a 'step'.
regards,
m4gnus
regards,
m4gnus
Author
Well, Ogre is of course using 8-bit integers because I do not directly give the heightmap to Ogre - I save it as a 8-bit greyscale .png, first.
But heightmaps usually are 8-bit images, aren't they? So that should not be the problem...?
More zoomed-out version:
But heightmaps usually are 8-bit images, aren't they? So that should not be the problem...?
More zoomed-out version:
Quote:Original post by Hippokrates
I divide the value by 1000 because Pi is defined as 3141 (since you cannot use modulo on floating point numbers)
Just for the record, you can do that with the fmod function.
Quote:Original post by Hippokrates
Well, Ogre is of course using 8-bit integers because I do not directly give the heightmap to Ogre - I save it as a 8-bit greyscale .png, first.
But heightmaps usually are 8-bit images, aren't they? So that should not be the problem...?
It IS the problem. If you want to use a 8-bit heightfield you have to smooth it in your renderer.
Quote:Original post by Hippokrates
Well, Ogre is of course using 8-bit integers because I do not directly give the heightmap to Ogre - I save it as a 8-bit greyscale .png, first.
But heightmaps usually are 8-bit images, aren't they? So that should not be the problem...?
More zoomed-out version:
Given that image, the output still seems reasonable to me. If you're using a heightmap, there is only limited accuracy you can get (as already mentioned). This image seems to me to be using that accuracy quite well. I'm still interested in the difference in density though. If you look at the high hill on the left, you'll see that the density changes halfway the hill; the right part is twice as dense.
Hippokrates, I once had exactly the same problem as you. Stairs in all my hills. What did I do to get rid of them?
Just like some other people already suggested: use 16bit heightmaps!
I tried smoothing in the renderer first but this never worked good enough for me, the main problem being that you loose some detail and you can't really control the smoothness/roughness of the terrain anymore because everything gets smoothed out.
If ogre can't handle 16bit heighhtmaps you should really use something different for visualization.
Another tip: test first with a heightmap from a game, like Battlefield (they store their maps in rather small 16bit heightmaps).
Just like some other people already suggested: use 16bit heightmaps!
I tried smoothing in the renderer first but this never worked good enough for me, the main problem being that you loose some detail and you can't really control the smoothness/roughness of the terrain anymore because everything gets smoothed out.
If ogre can't handle 16bit heighhtmaps you should really use something different for visualization.
Another tip: test first with a heightmap from a game, like Battlefield (they store their maps in rather small 16bit heightmaps).
Author
Ok, so I should use 16-bit heightmaps then...
But since I have never dealt with those before: what kind of values do I store in 16-bit heightmaps?
Simply storing values between 0 and 255 in a 16-bit .png wouldn't solve the problem, right?
But since I have never dealt with those before: what kind of values do I store in 16-bit heightmaps?
Simply storing values between 0 and 255 in a 16-bit .png wouldn't solve the problem, right?
Quote:Original post by Hippokrates
But since I have never dealt with those before: what kind of values do I store in 16-bit heightmaps?
Simply storing values between 0 and 255 in a 16-bit .png wouldn't solve the problem, right?
Values between 0 and (2^16)-1 = 65535
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
