Yesterday, I skipped Making Of JF because I was so lazy that I forgot. I watched Traffic on DVD and I searched the web for anime until 2 AM and Making Of JF totally slipped my mind. Accept my apologies as well as Scene 5 Page 3. Page 4 is finished, laid out, and compressed. I just don't want to let people who read JF daily to miss Page 3 if I post Page 3 and 4 at the same time. We all know that's a big no-no. I'll post it tomorrow at 6 PM. I'll also tell the people to look at this page, so that hopefully they don't skip this wonderful scene. JF came together a bit tonight. I sat down and did some work after watching Muppets from Space on DVD. Yes, I own it. It is one of my favorites. Duh, JF is 3d puppeteering, The Muppets are a huge inspiration for me. The audio commentary on the DVD is not any good. If the director would have given his secrets, I'd be very happy. Not that lack of good commentary detracts from the high value of the movie. But back to JF, I decided to really put in effort. It's mainly because I feel so bad about not giving Making Of JF last night and not doing Page 3 as soon as I could. Page 3 has been possible for a week at least. All I did tonight was: add death animations for DA 3 and DA 6, do the directing in AS3D Manga Director, and do the page layout in AS3D Manga Producer. It took a good three hours, but it was not too hard. It was extremely rewarding seeing all of it come together. I often am afraid of trying to get someting fleshed out too soon and getting it all wrong. Work in AS3DMD does no good unless all the models are really well done and ready for action. Same with AS3D MP. Making a page layout is hardly useful if the pictures look terrible. The lesson for today is get those silly animations done quickly, get into AS3DMD and make it happen. One of my main problems was overexposure and underexposure. That's a huge problem in 3d. You can see how some images are all one color, very overexposed. Some images, though are very dark, very underexposed. The problem is that the light model is very unrealistic. Believe it or not, the physics is too "real". When I say real, I mean true to simple equations. The reality is that very few real light sources act like point sources. That's all I use. So imagine a scene with a 100 Watt light bulb in your room and look at pictures of people taken in that room. There's very little room between underexposed and overexposed. That's what I'm having trouble with. So what I try to do is make it a pair of 20 Watt bulbs across from each other. That way, it actly more realistic with dull lighting all around instead of a bright light in the center of the room. It also gives a decent shading system in my opinion. It's not Jet Set Radio, but maybe one day.
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.
