Frictional Games Forum (read-only)
Blog: "Tech feature: Terrain geometry" - Printable Version

+- Frictional Games Forum (read-only) (https://www.frictionalgames.com/forum)
+-- Forum: Frictional Games (https://www.frictionalgames.com/forum/forum-3.html)
+--- Forum: Blog (https://www.frictionalgames.com/forum/forum-23.html)
+--- Thread: Blog: "Tech feature: Terrain geometry" (/thread-5315.html)



Blog: "Tech feature: Terrain geometry" - Thomas - 11-04-2010

Starting on terrain!

http://frictionalgames.blogspot.com/2010/11/tech-feature-terrain-geometry.html


RE: Blog: "Tech feature: Terrain geometry" - TheLittleGarfield - 11-04-2010

Hmmm... Deserts, cool.


RE: Blog: "Tech feature: Terrain geometry" - nofsky - 11-05-2010

Although most of the technical bits of that articles goes over my head, it's very interesting to read anyway. Please keep us updated with more articles like this!


RE: Blog: "Tech feature: Terrain geometry" - WindexGlow - 11-06-2010

The jpeg conversion didn't seem fair - looks like you added a ton of noise to it. In the slightest the lack of accuracy would have caused blocky formations, not total erratic values.


RE: Blog: "Tech featuTerrain geometry" - Thomas - 11-06-2010

(11-06-2010, 12:02 AM)WindexGlow Wrote: The jpeg conversion didn't seem fair - looks like you added a ton of noise to it. In the slightest the lack of accuracy would have caused blocky formations, not total erratic values.

well it was fair Smile the way it is saved jpeg just does not work. I am not sure any lossy image format would.


RE: Blog: "Tech featuTerrain geometry" - WindexGlow - 11-06-2010

(11-06-2010, 01:03 AM)Thomas Wrote:
(11-06-2010, 12:02 AM)WindexGlow Wrote: The jpeg conversion didn't seem fair - looks like you added a ton of noise to it. In the slightest the lack of accuracy would have caused blocky formations, not total erratic values.

well it was fair Smile the way it is saved jpeg just does not work. I am not sure any lossy image format would.

Yes, but how do you go from
http://1.bp.blogspot.com/_QfesHslH-uc/TNL3_aAjW8I/AAAAAAAAARc/HEgFuZlmyaI/s1600/10_png_compressed_rgb_packed_24bit.jpg

to
http://1.bp.blogspot.com/_QfesHslH-uc/TNL4Wr7quuI/AAAAAAAAARk/fVRl8y-86AU/s1600/12_jpeg_lossy_rgb_packed_24bit.jpg

I understand (been making procedural terrain my self, 32bit RGBA. 8bit caused odd steps on my terrain, too few bits) that jpeg will lose data over time with saves & messes color up, but all that will do is make it blocker looking - not completely invert colors.

I'm not denying the fact that jpeg is a poor choice for heightmaps. I'm just curious as to *how* you could make a jpeg like that without putting noise in.


RE: Blog: "Tech feature: Terrain geometry" - nofsky - 11-06-2010

That's because it's RGB packed.


RE: Blog: "Tech feature: Terrain geometry" - WindexGlow - 11-06-2010

Here is a 1024x1024 perlin I generated. In photoshop I resized it (billinear) to 64x64.
I than resized it (billinaer) to 1024x1024
I than saved it as jpeg at 20% (Very shitty quality, very small filesize)

It didn't create drastic changes. It looks blocky. But it doesn't have noise to it.
http://img526.imageshack.us/img526/6449/24725462.jpg


RE: Blog: "Tech feature: Terrain geometry" - nofsky - 11-06-2010

Again, it's because the RGB packed image was encoded to JPEG. What is shown in the corner of this screenshot is the unpacked image.

If you opened the JPG image in a normal image editor it would show up as noise of various colors because it was RGB packed.


RE: Blog: "Tech feature: Terrain geometry" - Thomas - 11-06-2010

Yeah, the reason for noise is the the packing.

R contains the 8 highest most influential bits in a 24 bit decimal number, G the 8 next and so on.

So when R is not the same as the orginal (as happens in jpeg compression) there are vast changes in the final value, leading to the noise.

I expected this, but was not 100% sure, so figured might as well test Smile