final sprint for the semester

So this is the final sprint before alpha. The first thing I did this week I worked with Ron to finalize our information layer conventions. Basically, we have no editor for our game. At all. So we're using Maya, instead. What we're doing is we're splitting a level into 3 separate .fbx's: display.fbx, which gets drawn, collision.fbx, which goes to the physics engine, and an information.fbx. Information.fbx contains placeholders for all the other entities. Lights, routes, ability pickups, objectives, etc. We're embedding a little bit of data in the mesh names themselves, then Ron's loader can iterate through all the meshes in a model, look at their names and transforms and act accordingly.

The other thing I worked on is a multiplayer level. Last sprint, Blake had mentioned in our stand up that he was working on multiplayer, and had met some milestones there. I decided that it was kind of important to have a level to go with it. So I did that. for a couple days fairly solid. I missed the art lock by about a day but not for lack of effort.

Since then I've just been working with Ron to fix any random little things I missed, like incorrect texture references, a couple missing colliders, and a random bug where all the faces on a few objects were reversed. It didn't display them as reversed in Maya, but they were, oddly enough.

This sprint

This sprint, I've made a samurai hat to give to the enemies to distinguish them as such, some scrolls for powerups, or whatever, a shrine, to put in the grave yard. That turned out nicely. Side - note, I was originally planning on using text from actual authentic scrolls, upon further reflection, I decided that probably wouldn't be the best idea given that I wouldn't actually have any idea what they would say, and that just seemed like a bad idea all around For all I know, it could have been an old list of the various Japanese synonyms for 'dong.' Therefore, I found some translations of 'common signs' and used those instead. One of the scrolls says 'parking', while another says 'remove your shoes'.
I've also been working on tombstones as well, particularly the weird altar type tombstones you see scattered across a graveyard, only Japanese styled, or at least what the internet alleges is Japanese. The tombstones, the shrine, and the graveyard walls from last sprint should complete the graveyard area, sans other details like foliage.
I may perhaps get to that this sprint, however, I think it's a little more important presently to pump out some architectural elements so we can prefab us some random buildings.

Last sprint

Last sprint I worked on building some tile-able modules so we could make things like walls and such by way of just copy-pasting. I really like the way the roof edges turned out. 'Happy accidents', eh?
 I also did some more testing stuffs. For some reason, the method that we've been using to differentiate object types in the fbx stopped working. Something to do with the physics engine and sending it 'meshes' as opposed to 'models'. Therefore, we elected to come up with a new structure, wherein the different object types are to be separated into their own fbx files.

Natural textures

This week, my primary assignment was to work on textures, most of which were natural materials, i.e. dirt, grass, rock, sand, etc. These proved a bit of a challenge on account of the fact that I just couldn't figure out how to paint those materials. So I came up with a method to turn a photograph into something that matches our style more closely. I feel satisfied with the result, although it does feel a bit like cheating. Additionally, I discussed AI algorithms with one of the programmers, and how it interacts with level design.

A non-halloween themed halloween post

    So this week's assignment, for me, has been to make some objects. Well I did that. I made 5 lamps, a barrel, and a crate, and I decided to do a quick lighting test, because I was worried that the models and textures alone didn't create enough definition. That worked out great.

    Afterwards, I decided to do a mid-scale test of the light-mapping workflow. That didn't work so great. at all. I had 2 problems: time and quality. As it turns out, baking light maps in Maya takes considerably longer than the equivalent render, for some reason. I don't know why. Well, I can see it taking a bit longer, but not as much as it does. Secondly, it took a 4k light map texture just to look acceptable. Mind you, that was only for those 7 objects, not including the floor. The problem was really just texture bleeding. Both from the space in between UV shells, and internal, hard edges. The result was that edges that were cut were outlined with black, which is fixable in Photoshop, and edges that weren't cut looked soft. If the light across an edge gets blurred, it looks... blobby. Not cool.
  
    So that pretty much murders the whole light mapping idea entirely, unless someone else has a better idea of how to go about it, which is sad, because that means we can't do nearly as much cool stuff with lighting. It wasn't a total loss, though. I still figured out how to do make the lamps work in XNA. In Maya, I used incandescence maps to fake back-lighting on the paper, there. Essentially, incandescence just adds directly to the result color. That is, if lambertian shading is light * diffuse color (where light is sum( light vector . surface normal) across all lights), then lambertian shading with incandescence is light * diffuse color + incandescence. Using what I learned from writing the light map shader, I could pretty easily modify a lambert shader to include incandescence.

I think I skipped a week...

Well, moving on then. So I've been working on textures, lately, gearing up to do some actual level design, once we have a better idea of what we're doing. I also made a light map shader that we can use for our levels. Instead of lighting the level in game, we can use that shader - come to think of it, we might need a specular version as well - to substitute for lighting. That way, we can bake all of our lighting in maya, using as many inefficient lights as we could possibly want, and whatever effects we want, and it won't effect performance at all. Part of the hurdle there was getting multiple UV sets to work. This allows us to have the advantages of both tiled textures, and unique UV coordinates. Tiling textures by extending uvs outside the 0 to 1 UV range works great for applying textures because you get way more bang for your buck, so to speak. Each pixel on a texture map can show up on as many faces as you need it to, as many times as you need it to, i.e. the size of your texture doesn't necessarily correspond to its quality. On the other hand, having a separate UV map where everything is in the 0,1 range, and nothing is stacked, means that each pixel on a UV map corresponds to at most 1 point on geometry, which is absolutely necessary for light mapping. You get less density that way, but you don't need as much texture space with light maps as you do with textures. By way of example, I made this object to test with:

The model is comprised of 9 cubes. The diffuse texture is applied 4 times per face, and there's 6 faces per cube. 9*4*6 = 216. So from an efficiency stand point, 21600% of that texture is being used, compared to the lightmap, which, as you might be able to tell, is using maybe 85% of the texture space, but at the same time, that light map would not be possible with the 'more efficient' repeating UVs.

 So for the rest of the weekend, I'll be making textures, and maybe some small objects like lamps, or maybe some architectural elements.