Greetings, as promised, here is Scene 5, Page 4. If you missed it, yesterday was the magnificent Scene 5, Page 3. Page 4 will be easier to understand with Page 3, 2, and 1. And if you have not read Scenes 1-4, I emplore you to. Javantea's Fate may seem disjointed except for the common theme of violence, but I tell you that all of it is more than necessary. In fact, it deserves far more than what is there. I'm planning on redoing the entire comic next year or so. But if you read Making Of JF everyday, you'd know that. Of course, I've skipped three or so, so it's not exactly daily, but 121 vs 3 is a statistically probable event. In fact, I'm so sorry about missing the other day, I'm doing one today even though I shouldn't (since I don't do Making Of Pages on days that I post actual comic material). It's not up now, but it'll be up around midnight or so. By the time you read this, it'll be up here.
Greetings and welcome to a continuation of AltSci3D Terrain Works 2. At the end of last episode, we saw a bunch of problems cropping up. Today, we solve those problems and begin new problems. The problem was mainly messy code and DirectX's insistance that an 8-bit greyscale bitmap is in fact a 32-bit image. We can survive this. Multiply by four and we have terrain. A bit of code later and I have a skybox. The same code that gives a skybox also gives a wonderful set of buildings. There are a few problems, though. The first one is not very obvious. Using vertex buffers that are of static size means that we must have a constant number of buildings. This is fine for the end user (since it'll be loaded from an .X file anyway), but the developer has some serious problems with that. Why don't I just set a large number of buildings to be the cap? Well, that's because I'm creating a buffer. Each building has thirty 16-bit indicies and ten thirty-two byte vertexes. Each building takes up 380 bytes of RAM. That's not much, right? But a 3d city has approximately 1000 buildings. That's how much a GeForce can render at 30 fps using culling. So do the calculations and we have 371 kB. That's about one third of the size of the skybox texture. Really, it's not that bad. But it's the principle that counts! What if you're modelling a very large city with very complex buildings, with normals for each. Each building might be 300 kB alone. Multiply that by ten thousand buildings and you get 3 gigabytes. That's more RAM than I have in my computer, more than the virtual RAM even! But now you say, you could never render so many buildings, it's a moot point. But then I say: oh yeah? What about a model of the entire west coast? Top to bottom, Washington, Oregon, California. Maybe even Mexico and British Columbia. Using LOD and zones, it could be managed. But then what about the developer? Who cares about the end user rendering it, that's some heavy shiznits for the developer. I have a couple possible solutions. The first is to have two vertex buffers. The first is empty, the second has the date. When we want to add one, we fill the first with the second plus the new one. Then the second one becomes the first and the first becomes the second. Repeat as many buildings as you want. Simple enough? I guess so. But it should be Microsoft's job to make reallocatable vertex buffers without having to copy the data.
12 faces/building * 20 buildings/row * 20 row/neighborhood = 4800 faces/neighborhood. 2 * (32-1)^2 = 1922 faces/terrain. Why 32-1? That's because of the whole world of bitmaps. If I made 32 rows of faces, there'd be an odd number of verticies per row and column. That is where the bitmap comes into place. The vertex get it's height from the bitmap which is a power of 2 (512x512 in this case). If I had an even number of faces, I'd have an odd number of verticies which would mess up the mesh. It's so crazy that it took me hours last year to figure that out. Finally, 4800 + 961 = 6722 faces. That's how many faces are in the scene. However, not all of them are being drawn. Half of the buildings' faces are being "culled", which in computer terms is to hide things unseen. We don't have to render them if they aren't going to be seen. A further improvement would be to hide things behind me (unseen, of course) and hide or simplify things far away (continuous level of detail). Of course, this takes a lot of work and is only worth it for projects that require certain types of scenes. For JF, no problem. Even if the scene is 5 frames per second, I still just take a picture. It might as well be 500 fps, because the user never sees the fps. Also, I have a Asus GeForce2 GTS 64 DDR 7700 Deluxe as you can see in the upper right hand corner. That means that my fps stays high up until the faces goes up to 20,000. The Jav model is 456 faces. Add in ten DA models at 534 each and the terrain and you get around 12,000 faces. My fps stays at 30 even then at 800x600x32. But then you add lighting and it goes down to 15 fps. Static lighting of the buildings and terrain would help. A simple solution would be to cull whole characters. Doing a dot product between the view vector and the displacement vector of the character from the camera would give a definitive answer to whether it is visible and would save a bunch of fps. How many characters will be in the viewfield at a time? Only four or five max. But the thing is that if you ever want to have more viewable, it'll lose fps fast. Another possible solution would be vertex shaders. Even though I'm fairly well versed in assembly as well as the mechanics of vertex shaders, there's no way that I'm going to use a vertex shader within a year. I may eat my words soon, but not without a huge step towards ease of use. The lesson? Well, I guess given all this information, we see how pessimistic a person can get. A bunch of ugly buildings costs a GeForce 2 at 800x600x32 at 45 fps. Well, don't dispair too much. I was reading a review for a video game the other day and they said how the buildings were terrible, ugly as arse, really. I looked at the screenshot and the buildings looked beautiful. I wondered if the reviewer was blind. But he explained how the buildings were so monotonous that it drove him mad. The engine allowed for a very non-linear gameplot with a city ten kilometers across, beautiful with amazing sights to see and wonderful scenery. The level designer forgot it completely. Driving around the huge town where every building was exactly the same height, same texture, same color, and same spacing was impossible. A person could get lost so easily because there was only a radar that told you where your destination is. Your enemies' AI acted monotonously, the adventure was bland, and the story was a solid line from start to finish. You can see that the problem is that monotony does not quite save performance. In fact, take a thousand faces and make a bunch of squares out of them. Not very inspiring, huh? What if you make no two buildings look alike? Then you'll have yourself a beautiful scene. I didn't do that in this image. You can see that this is extremely monotonous. When I put in the lined-up streets like in JF, you will probably say the same thing as the reviewer did. But I'm going to make sure that JF and UAV:RR will not be monotonous. I'm going to stretch the UV map in LithUnwrap to make boulevards, I'm going to make rotated neighborhoods such as in real life Seattle, different colors and textures for almost every building, street lights, a static lightmap for the city, and parks.
Today's lesson is to stand your ground. Why? First off, you know that you're right. If you're right, your enemies will fall, run, or attack. Thus you will know that they are wrong. If your enemies attack, you have the defensive posture. Of course, if you're shot to death while standing still or lying on the ground twenty feet from twelve attackers, then you're fucked. Even then, I say that justice will see you through to heaven and your attackers to a terrible demise. I'll give you a few good examples. Today I was at the bus stop, running very late. I looked at the next stopping time: 7:02 and then at my watch: 7:04. Should I head three blocks east to another bus stop or should I wait? I'd say that I had equal chance of either good or bad outcome. I wait and in sixty seconds a bus drives up and picks me up. Standing my ground saved me from being very late. Another beneficial outcome today, citizens of the U District wanted to protest the murder of Shawn Maxwell. When they got to 50th and University Way, a police officer told them that they would have to walk on the sidewalk since they didn't have a permit. Instead of shouting obscenities at him and blocking the street (to be unjustly arrested and abused), a friend from Socialist Alternative told the police officer: The First Amendment is the only permit we need. By disallowing unplanned protests, the city is breaking the First Amendment. We will march in the streets no matter what you say or do. So the police officer talks to his colleagues and decides that they don't have the time, patience, or legal expertise to argue the intent of the founding father's in writing the First Amendment. He told them that a safer route guided by a police escort would be possible, taking only one lane of two lanes and blocking the Ave and Brooklyn instead of the Ave and Roosevelt. Roosevelt would have been more populated, but would be very unsafe since it's one way with few lights (and thus more evil traffic). The thirty protestors democratically agreed and we peacefully did our thing. We shouted the good old chants: "What do we want?! Justice! When do we want it?! Now! Why did cops have to kill?! An innocent black man, Shawn Maxwell?!" Many people were supportive. I'm sure that cars trapped in the protest weren't entirely happy, but they didn't make too much of a scene. One problem I had was a couple people scowling at us. One said, "Obviously, we need more police." Of course, I'll forgive them because they have no idea that an innocent man was murdered before my very eyes by people whose salaries I pay.
