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 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. 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 |