Wednesday LOD and LIGHT

Plenty Code Crunched

A full day of coding, both last evening and this evening sees the low and high LOD system implemented. I also added in some test artwork from Mark for the segment visuals to see how the popping would look.

I have run into some logistical issues however as performance is very much tied to the size of a single segment, how many of those segments are in close proximity and the cumulative processing required to fill the buffers as you traverse through the space.  If I spread out the segments, all is smooth. When I bunch them up, I get stutter as I move through the level. Not ideal by any means, and something will have to give. Currently my high LOD test segment uses over 3000 polygons so one thing that might give is to set an upper limit for segment art.

Thursday will see these logistics put under scrutiny and some rules established so I can have 120fps smooth scrolling through the level with the LOD system in play.  I can report the 'LOD popping' is minimal with my test segment which is good, and I have also increased the size of the overall level from 200x20x200 to 500x20x500 as when I walked from one end to the other I felt I needed more distance, and it's only an extra 50MB (with further optimization in memory use possible).

The Lighting Issue

A new situation has emerged that might affect deadlines, and just like the memory resource bar and massive levels was discussed in the blog, I felt it was a good idea to broke the new subject here as well.

I was about to add the real-time light mapping system to the instance stamp code I have been working one when I got an email from Mark suggesting that adding directional light to the level would not work in cases where a soldier or object was placed alongside a wall that would cast a shadow over the subject based on the angle of light.

For an outdoor scene, it is common in some FPS games that a single directional light representative of the sun would allow all objects in the scene to cast a shadow. This shadow would render on the floor, walls, characters and objects of the scene. The common technique used is a variation of shadow mapping and uses a second render from the light position and clever shaders to achieve.  It was suggested that before I embark on adding my real time light mapper to the new static scene system, we look at the possibility of adding dynamic directional lighting into the scene, and perhaps even deferred rendering.

It must be stresses that starting a series of prototypes to experiment with deferred rendering techniques, and implementing those to replace reliance on baked light mapping would add considerable time to the project deadline. Although I am familiar with the technique, I have not created one personally and there are bound to be a hundred small details that relate to creating a deferred rendering system for an entire game engine. It would also mean we basically throw away the real-time light mapping system developed so far as a dynamic lighting system would not need secondary shadow baking and surface lighting.

Rick suggests we implement both, baked lights for interiors and dynamics for exteriors, but this of course means all the work of a deferred renderer, plus implementing, perfecting and then combining these two techniques into the final engine, producing the most amount of work.

One advantage of dropping baked light-maps is that no memory would be required to store the UV data sets and of course the light map textures, which when considering a 500x20x500 level, would amount to quite a sea of lightmap textures and most certainly some form of streaming system to ensure the texture and UV data was streamed in as the level scene required the data.

Decisions Decisions

I am loathe to drop code that I spent weeks theorizing, coding and perfecting, but at the end of the day it is about creating the best product and if that means smashing the sculpture to pieces and starting again, then these are the hard knocks of game development.

I have decided to crack on with things that need coding and not debating such as getting the static LOD system smooth and predictable, adding it to the main map editor so I can edit with the new instance stamps, and then seeing what I can do about physics and player controls.

Physics and Player Controls

Just to highlight that game engine development is not all peaches and cream, another issue to tackle in my immediate future is the fact that as the geometry is being constructed on the fly as you get near to it, so to does the physics geometry. 

In the current FPSC all physics level geometry is loaded in at the start and stays solid until you go to the next level. Apart from placing pseudo static boxes, I have never tried generating polygon data and adding it to a physics scene on the fly. My mind tells me such a thing would introduce instability and cause distant objects to start flying out of the scene, and at the very least add more processing overhead as you advance to new parts of the level.

A prototype will need to be created to answer these questions before I can introduce physics to the map editor and allow the user to drop down and run around the instance stamp based level.

All these things can be worked on without answering the lighting question, so we have some time to debate the pros and cons of creating a whole new shader based lighting system over the traditional baked lighting system we have right now.  Its worth noting both COD MW2 and Black Ops are forward rendered using some baked light-maps, and they look just fine.  Deferred rendering you would see in games such as the latest Far Cry. I am not pinning my 'alternative flag' to deferred, simply opening up the possibility for developing a new lighting system that does not use baked lights and instead produces all it's lighting from clever shaders and even cleverer techniques.

Signing Off

I am quite pleased with how the LOD work went, and with some tweaking of buffer sizes, asset sizes and load balancing so not too much happens in the background, I should be onto the next thing soon. If anyone looks at these daily antics from outside the cult of coding, you should begin to realize just how fluid development can be. Where I to stick with a deadline and meet it, I would not be implementing instance stamps, I would probably already be working on physics and player control systems, running around a light-mapped level created under the umbrella and protection of a resource meter. The big question is whether the lighting question is one of those deal breakers, or whether we can stick with baked lighting and return to outdoor directional dynamic shadows and lighting during an update after Christmas.  Feel free to post some comments on this!