{"id":177,"date":"2006-02-17T18:22:40","date_gmt":"2006-02-17T23:22:40","guid":{"rendered":"http:\/\/www.shamusyoung.com\/twentysidedtale\/?p=177"},"modified":"2011-04-10T05:44:32","modified_gmt":"2011-04-10T10:44:32","slug":"terrain-part-9","status":"publish","type":"post","link":"https:\/\/www.shamusyoung.com\/twentysidedtale\/?p=177","title":{"rendered":"Terrain, Part 9"},"content":{"rendered":"
Diminishing texture sizes<\/div>\n

Right now my program makes 64 different textures for the terrain, each of which fits over a particular zone. Right now all the textures are the same size, which is 256×256. This takes about 16MB of video memory. Not bad, but certainly not ideal. This means every zone, no matter how close or how far, has the same sized texture. Check it out:<\/p>\n


In this set of textures, each one is 256×256 pixels. The entire set takes about 2 seconds to build and takes up 16MB of memory.<\/center><\/p>\n

If you remember from previous updates, I need to rebuild all of the textures if I move the sun. (If I don’t, the terrain would look exactly the same, which would defeat the purpose of moving the sun. It needs to re-make the textures with the new shading and shadowing.) But right now it takes 2 full seconds to rebuild the textures. I have to “steal” that two seconds a few milliseconds at a time, unless I want the user to endure a long pause every time the shadows need to move. <\/p>\n

But, we don’t need every dang texture to be 256×256. In fact, only the ones nearby do. Let’s make the texture size variable, so that the ones nearby have lots of detail and the ones far away have much less:<\/p>\n


In this set of textures, the closest ones are 256×256 pixels, and the ones in the distance are 8×8. The entire set takes about 0.7 seconds to build, and uses just over 2MB of video memory.<\/center><\/p>\n

I think I’m actually being too agressive here. The ones at the top that you can’t read are 16×16 and 8×8. They look pretty crappy, and I think 32×32 should be the minimum. Anyway, I need to calibrate this a bit, but it’s clear this is the way to go. I’m using a fraction of the memory I was before and the texture rebuild happens about three times faster. <\/p>\n

However, this introduces a new problem. (Doesn’t it always?) Let’s assume this engine is being used in some sort of Sim City or RTS setting. The user may want to zip from their current location over to the other side of the map. When they get there, the area right in front of them will look like this:<\/p>\n


Ugh. Not so nice.<\/center><\/p>\n

So, while before I was worried about keeping shadows moving smoothly, now I have to keep these texture updates coming so the above doesn’t happen. If the user hurries accross the terrain, I think it would be a good idea to dedicate more time to the texture rebuild, so that I can come up with a new set of textures with the detail in the right place. This would mean that moving very fast from one side of the terrain to the other would lead to the framerate dropping and things getting choppy for a second until the texture rebuild gets caught up. This is acceptable in my book, as long as the game doesn’t require lots of fast hops around the terrain. <\/p>\n

EDIT (July 6 2007): A much better idea, now that I’m thinking about this a year and a half later, for for each zone to hold onto several different resolutions. When I go to a new area of the map, it will build the higher res textures I need nearby, but it won’t throw away the high res ones I was looking at a second ago. It will just shuffle them out of use for a minute. If I come back, the textures go back into use. After a while, unused high-res textures are purged from memory. This means If I jump around between various “hotspots” the game won’t have to do a lot of texture rebuilding, and the game stays smooth.<\/p>\n","protected":false},"excerpt":{"rendered":"

Diminishing texture sizes Right now my program makes 64 different textures for the terrain, each of which fits over a particular zone. Right now all the textures are the same size, which is 256×256. This takes about 16MB of video memory. Not bad, but certainly not ideal. This means every zone, no matter how close […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[66],"tags":[],"class_list":["post-177","post","type-post","status-publish","format-standard","hentry","category-programming"],"_links":{"self":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/177","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=177"}],"version-history":[{"count":0,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=\/wp\/v2\/posts\/177\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=177"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=177"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.shamusyoung.com\/twentysidedtale\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=177"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}