<\/td><\/tr><\/table><\/p>\nThe big problem is that it is taking crazy, super, insano, bonkers long to generate terrain. It’s about a second per node. Several people, including fellow code-hobbyist Michael Goodfellow<\/a> – suggested that the octree is really expensive to use. So let’s disable that and see if we get any speed gains.<\/p>\n And by “disable” I mean, “write an entirely different, simpler storage system for my data”. No trees. No dynamic allocation. Just one huge, honkin’ block of memory where you can get anywhere in a single lookup. And let’s see how the new system performs…<\/p>\n
 <\/td><\/tr><\/table><\/p>\nWow. Just over a tenth of a second. Almost ten times faster. <\/p>\n Click on octree.cpp. Hit delete. <\/p>\n Now my project is probably a thousand lines smaller and runs ten times faster. And of course now I have a project called “octant” that is no longer related to octrees. So that’s hilarious. I think I should make this into a game called “Shoot Guy Online”, which is a single-player game about a woman who fights with a sword. <\/p>\n I’m not really that sad to see the octree go. The octree made it super-fast to do things that were rare, and super-slow to do things that were common. This is like a sprinter buying shoes that make her walk three times as fast and run ten times slower. <\/p>\n I’d wanted to use it so that I could fit a really huge data set into memory, and see how far out I could get my draw distance. It became clear a few days ago that memory wasn’t going to be my chief hurdle. I was going to run into throughput problems long<\/strong> before I ran into memory problems, even though every doubling of distance results in eight times as much memory usage. A kilometer view distance is just not<\/em> going to happen within the context of this project. (Oh, it’s possible<\/em>, but it would require super-long loading times, or multi-pass block generation where the map would fill with increasing levels of detail, or some other trick to manage the sheer volume of stuff I have to process. That could take days to investigate and it might not pan out.)<\/p>\n Moving on…<\/p>\n People have been asking about the surface normals. If you remember, those are vectors (think of them like arrows) that say which way a vertex is pointed.<\/p>\n Now that normals are working again, I can use lighting. <\/p>\n I’ve also got a super-cheap shadowing system that will darken a block if there is another block anywhere above it. It’s strictly pass\/fail – the “sunlight” doesn’t spread. I’m not sure I want to change it. This looks pretty good as-is.<\/p>\n Now that we have some free CPU cycles, let’s see if we can’t make more interesting terrain. Right now I’m just making rolling hills with a maze of random tunnels underneath. The above screenshot is from a rare location where the terrain dips below the tunnels and exposes them. I’m not even using the noise system very much yet. No overhangs, no mountains. Cliffs are massive boring walls of smeared pixels. Yawn.<\/p>\n So let’s just generate some random pockets of noise and use it to remove volumes of terrain. How does that look?<\/p>\n That’s a lot more interesting. This more complex topography is really exposing the shortcomings of my texture mapping system. We’ll deal with that in a bit.<\/p>\n Let’s add some different types of terrain. Maybe some dirt would look good. <\/p>\n I like that. And the tunnels look good too. They looked very mechanical in the cube world, but here in blob world they look like natural caves. It’s fun to run through them to go from one open area to the next. <\/p>\n You know we need next? Let me grab the grass-scattering code I used in Part 3 of Project Frontier<\/a>.<\/p>\n Yeah. Okay, enough fun. Now that we have a shader, let’s fix this texture mapping problem.<\/p>\n The problem: I don’t just want to smear texture around randomly. If I put a brick texture down, I want to be able to map it all over these lumpy hills and still have the bricks align properly. But how can we do this? We’ve got a 2D square that we’re trying to project onto complex 3D shapes. <\/p>\n Well, there are three ways to apply patterned textures to a scene so that you can be sure they’ll line up. First, I could project the texture along the x-axis, so that walls facing east \/ west look good: <\/p>\n You can see this makes the x-facing walls look great, at the expense of making everything else look like a big smear.<\/p>\n Also: I should note that these square trenches are part of my testing grounds, not my terrain system. I created these for exactly this sort of situation.<\/p>\n Another way to map things is to project the texture along the y-axis.<\/p>\n I don’t think you’d call this an improvement, unless you happened to be looking at a north-facing wall and you didn’t have any plans to turn your head.<\/p>\n Finally, I could project from above:<\/p>\n But again, this just changes who gets screwed. What we need is to switch between these systems. If only there was some way to know which one we needed…<\/p>\n Oh right! Those surface normals we just got done fixing. To make the above image, I just had it color the walls according to which way the normals were pointing. (Programmer talk: Actually, I’m using the absolute values of the normals and not The more something points along the x axis, the more red it has. The more along y, the more green. The more up or down, the more blue. Because our normals are normalized (remember from above when we resized them?) we know that if you add up red, green, and blue the sum of the values will always be 1. So, red=1, green=1 is impossible. This means we have a nice, clear indication of which way a particular bit of wall is pointing.<\/p>\n So all I need to do is pick my projection method based on which axis is the predominant one. (Which color has the highest value.) <\/p>\n Perhaps you’re wondering why we needed shaders for this. Consider:<\/p>\n |
<\/td><\/tr><\/table><\/p>\n
<\/td><\/tr><\/table><\/p>\n
<\/td><\/tr><\/table><\/p>\n
<\/td><\/tr><\/table><\/p>\n
<\/a><\/td><\/tr><\/table><\/p>\n
<\/td><\/tr><\/table><\/p>\n
<\/td><\/tr><\/table><\/p>\n
<\/td><\/tr><\/table><\/p>\n
<\/td><\/tr><\/table><\/p>\n
<\/td><\/tr><\/table><\/p>\n
<\/td><\/tr><\/table><\/p>\n
<\/a><\/td><\/tr><\/table><\/p>\n