 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Texturing Heightmaps |
|
 |
random_acts Member since: 2/3/2002 From: Chicago, IL, United States |
|||
 Posted - 5/13/2005 10:05:09 PM |
||||
| I enjoyed this article, but the author seems to suggest using a 4096 x 4096 image as one way to texture a heightmap. That comes out to a 16MB texture at 8bit and or a 32MB texture for 16bit. I have not done much 3d work (I'm still mastering 2D arcade types) but surely a 16MB texture is far too much. I was under the assumption that 1024x1024 was about as big as you want to get. I understand gfx cards are getting more powerful - 256MB cards are more and more common - and that memory is relatively cheap - we're starting to see 512MB as a standard for game systems, but one texture at 16MB? I also get that if you have little else by way of textures and poly's 1 huge texture is okay, but is this standard practice?? |
||||
|
||||
|
IronBat Member since: 2/18/2004 From: Peterborough, United Kingdom |
|||
|
Posted - 5/14/2005 10:41:41 AM |
||||
| No using a large pregenerated texture that is stretched over the terrain is not really a good idea. It’s more common to use texture splattering to blend the different tile textures together in realtime using a pixel shader. That way you dont need a massive base texture and you get more detail. But saying that a few months ago I created a game for college that uses a 64*64 tile hightmap with a pregenerated 1024*1024 texture map, but that was because the college computers didn’t support mulittextureing and I wanted to avoid expensive blending. I just made a simple hightmap editing application, which let me paint any texture I wanted to the map on a per vertex basis. For each tile I then calculated a 16*16 pixel alpha map for each ground type, using linear interpolation of each corner to smooth it out. The alpha maps are used to work out the final colour per pixel, this gives me a nice smooth transition. The following is a snippet from my code that works out the final blended colour for a pixel: // Get colours GetLayerColouri(corner1tex, cx, cy, r[0], g[0], b[0]); GetLayerColouri(corner2tex, cx, cy, r[1], g[1], b[1]); GetLayerColouri(corner3tex, cx, cy, r[2], g[2], b[2]); GetLayerColouri(corner4tex, cx, cy, r[3], g[3], b[3]); // Calculate final colours red = ClampColour(light * ((r[0]*alpha1[ai]) + (r[1]*alpha2[ai]) + (r[2]*alpha3[ai]) + (r[3]*alpha4[ai]))); green = ClampColour(light * ((g[0]*alpha1[ai]) + (g[1]*alpha2[ai]) + (g[2]*alpha3[ai]) + (g[3]*alpha4[ai]))); blue = ClampColour(light * ((b[0]*alpha1[ai]) + (b[1]*alpha2[ai]) + (b[2]*alpha3[ai]) + (b[3]*alpha4[ai]))); This worked well for me but as mentioned in the article it all depends upon what hardware you are restricted too. |
||||
|
||||
|
d000hg Member since: 1/21/2002 From: Durham, United Kingdom |
|||
|
Posted - 5/16/2005 8:10:26 AM |
||||
| Well hello, I was really suprised to see this article here since nobody told me it was being published! I am and am not advocating a large texture, in different ways... To get detail into the terrain I would use different small detail textures for each groundtype. However to get blending a little smoother and allow some extra variation in large scale colouring I use a large texture of about 1m resolution. This lets me precalculate lighting effects & terrain shadows too. I actually have my detail maps greyscale/desaturated so the colour comes from this large texture. I don't think a 4096x4096 texture is too bad since there is only one of them - I'm sure I remember reading that UT2003 and DOOM3 use such textures for each texturing a single model? Note that most/all cards support texture compression these days - certainly my Geforce2 does. One other advantage is that no vertex colouring is needed. This means a very low-poly version of the terrain still has a good colouring and is therefore still quite acceptable. |
||||
|
||||
|
OpenGL_Guru Member since: 1/12/2003 From: USA |
|||
|
Posted - 5/16/2005 9:42:23 AM |
||||
| hey you guys might find my work of texturing useful... someone on this site was nice enough to host my screenshots. basically its the whole world at 10-minute resolution(that is a point every 10 nautical miles of the earth, so pretty nice resolution). these are indeed accuarate heights even though i had to scale them up some on the z axis to get all the nice features to come out. the link to the screenies is here i use a 1-D texture(1024x1024 .bmp, created in photoshop)for the coloring of the heightmap. after i load in the data i find the min and max height and store those 2 values. as you can see from the legend(which is also colored through the same 1-D texture) i chose colors of the texture to be something that would make sense.. i.e. every height below 0 would be light blue -> dark blue/purple and at 0 would be a beachy color(beige i guess). everything above 0 would be light green->white, with white being the mountains. in my display lists where i draw the terrain and assign the texture colors i go through the loop and check to see if the height is above or below 0. if the height is < 0 then i do something like: glTexCoord1f((0.55 + height[i]) / min_height); else if the height is >= 0 then i would do something like: glTexCoord1f((0.45 - height[i]) / max_height); you notice that i dont add/subtract 0.5 for the middle of the texture, instead i go a little on each side .05. this ensures that you get the beach like color which is the center of the texture will be placed at all heights ~= 0. as you can see the coast isnt showing up right, but i did in fact get it working pretty nicely. you can see the colors i used for the texture by looking at the legend. anyway hope this helps out someone. if you have any questions i can answer. |
||||
|
||||
|
Will F Member since: 4/10/2005 From: Carmel valley, CA, United States |
|||
|
Posted - 6/1/2005 1:57:13 PM |
||||
| Nice article. One little thing - source code is always nice. I realize the article is more about the algorithms than implementation, but a SDL/OpenGl implementation would be nice (it'd run on just about anything). Then again, that's more work for the author. Otherwise, even just a demonstration binary would be nice (preferably a linux binary too). Regardless, keep up the good work. |
||||
|
||||
|
d000hg Member since: 1/21/2002 From: Durham, United Kingdom |
|||
|
Posted - 6/9/2005 3:15:54 AM |
||||
| Ah, the cross-platform advocate :) Since this is part of my game engine, putting some relevant code up that worked would be tricky to avoid putting up loads of other stuff too. It's also the first bit of my engine I wrote so not in a very readable form right now! As for a demo .exe, I did release a demo a while back here, but I don't think it's that great really! It shows some texture blending between groundtypes and uses some nice methods for very low memory use, but it's not optimised. I'm doing more work on the terrain again so hopefully can post a much improved version soon... |
||||
|
||||
|
onnel Member since: 3/11/2001 |
|||
|
Posted - 7/7/2005 6:10:21 AM |
||||
| How would this technique be used with a dynamic LOD mesh (like ROAM)? I am coordinating the textures for the dynamic faces via the vertices used to generate them, but this tends to lead to my textures "shifting" like blotches on the terrain as my LODs. Should I use some form of alpha blending based on distance from the vertex to make sure that the textures only stay near where they should be? Might this then cause a problem when at a very low LOD in the distance (so big triangles)? All thoughts are appreciated! Onnel |
||||
|
||||
|
cebugdev Member since: 1/12/2006 From: Cebu city, Philippines |
|||
|
Posted - 6/25/2006 12:51:07 AM |
||||
| source code? for the demo? |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
