Features for next generation game engine.

In my mind, there are several unsatisfied demand for game engines. It is because most of game engines have been improved from long time ago. For example, game bryo, Unreal, Quake, and Half-Life. Those game engines did not have chance to adopt new concepts.

The features that I want to have are listed here:

1. Interface and contract driven design.
2. Support for Unit-Testing.
3. Pre-lighting as well as deferred shading and forward shading.

Additionally and personally I prefer these features as well:

1. Progressive rendering.
2. SPU support on PS3.
3. XNA support through C++ DLL.
4. No preprocessor codes such as #ifdef.

Other external tool supports such as Max/Maya plug-in, UI tool, and sound system are second level issue. Once we have the reliable corner stone, people will join the project.

Truck number or lucky number.

Truck number is the minimum number of people who can mess up a project. The higher, the better.

For example, the truck number is 1 for a project, meaning that when one person got hit by a truck then the project cannot go on anymore.

If the example is too cruel, then we can also call it lucky number. For example, a person get big money by a lottery, he quit the company and the project cannot go on anymore. It means the lucky number is one.Now our company has one HR person. He is out of country more than 30 days. I need to talk to him about my Visa but I cannot process it; I'm wondering he might actually get a lottery.

One may think higher lucky number means less efficient, because of too much redundancy. Well, it may be true. Insurance is for reducing risk not to increase efficiency. And the risk may mess up your company or your life.

My company is small as a matter of fact. But I do not think it is as small as it can afford only one HR person. I do believe it is rather a matter of experience. People who don't have various experiences tend not to prepare for other risky situations.

An idea to enhance SSAO.

AO here means Ambient Occlusion. As well known, AO increases realism in a scene. Some of concave shaped corner of objects are exposed to out side less then convex corners. The concave part will look darker than convex part. AO calculates how much a point is occluded by other geometries.
One problem of AO is that it is expansive to calculate. We cannot afford to calculate AO at run-time. So people pre-calculate AO values and they are used at run-time. In this way, AO values are valid only for static objects, because if objects move AO values must be re-calculated and we cannot afford it.

One novel approach was known as SSAO. AO calculation is done in screen-space with depth buffer; optionally with normal buffer.

SSAO does not give as good looking as pre-calculated AO values although it is still better than not using at all. In addition, one thing we need to notice is that SSAO is still not cheap at run-time.
For the screen-shot above, you can see a sofa on right side which has two cushions. And you can see a table. The screen-shot shows AO between the sofa and table which is represented by darker color. But actually the distance between table and sofa is relatively far, although it appears to be closer on the screen space. So the SSAO result is not quite correct. I feel it is more like dark glow effect from sofa or some kind of wrong shadow.

My idea is a kind of hybrid way between SSAO and pre-calculated AO. When a object is moving, we use SSAO, and when the object stop moving, we use a better AO value that is calculated at run-time. Although AO calculation is expensive then SSAO, once the AO values are calculated, it does not need to be recalculated until the object moves again.

First, we can detect whether or not a object is stabilized from physic engine API. Once stabilizing objects or sleeping objects were a big issue on physic implementations. People have improved it year by year. Since physic engines are handling this big issue, we can easily find which objects are about to be static.

Second, we can use SSAO until the better AO values are calculated. It is ok to spend more time than two or several frames as long as SSAO plays its role. Once the AO calculation is done, we replace SSAO with the better AO values. Then we will get a better look and don't need to do the expensive SSAO for the static objects.
This is just an idea. I haven't tested it yet.

One thing I'm afraid of is that when we replace SSAO with the better AO, player may notice the changes. It may give wrong information that something was moving there. So it should be gradually changing. Another thing is that I don't know how much expensive the better AO calculation will be. It may not feasible at run-time at all. Lastly, I am not quite sure how to differentiate SSAO rendering and AO rendering in a scene. Since SSAO will use just a big screen-quad, we may or may not be able to selectively calculate SSAO with a stencil buffer.

I wish I can have a chance to implement this idea sooner or later.

Sony leap year problem.

Today is March 1st, but PlayStation3 hardware recognized it as Feb 29th, because its internal clock had a problem.

Because of this reason, game players of play station 3 could not log-in the server; in fact, I'm not quite understanding why and how. In addition, I also could not work on PS3 this morning, because our game needed to log-in, due to Trophy system.
I was thinking that Microsoft people who developed X-Box must be laughing; indeed X-Box was fine today.

Game related programmers must learn how important Unit-Testing is...; I have never seen any game engine that support unit testing yet.

Uncharted2 after 1 chapter play

Today I have played uncharted 2 little bit. It has very beautiful graphics as people said. I like to share some of my findings.The game uses shadow map for each light, each flash light and sky light. I think the sky light shadow map moves according to the camera; I can notice the boundary some times.

Shadow doesn't appear when the characters are already inside of shadow. Instead SSAO is used under shadow. This is first time for me to see implemented SSAO. It was very nice but not as much as I expected. The ambient intensity changes by changing camera position. Especially grass had a bad look AO.

Although the playground is half-out-door, it is actually indoor rendering. I guess they used portal culling for each zone as usual for indoor engines.

Reflection on water surface was very very impressive. My best guess is that they redraw objects one more time with proper culling.

Most of walls or any surfaces were wrapped with high resolution textures and normal maps. This raises the quality of this game very high.

Some of specular with low EXP values gave very much realism. I have always thought specular must be shining, but I might be wrong. Especially one of white statues looks so nice.

Foot of the protagonist are implemented by Inverse-Kinematics, but sometimes it looks weird; it bends too much and too rounded.

I heard that Depth of field on Uncharted 2 is run by SPU. It was very natural and helped players to focus on the target. I think it might be better if DOF was used also for cut-scenes.

Eyes of characters get too much specular. It shines too much and got my attention unnecessarily.

I don't see motion-blur and I don't feel alias problems, so I guess it is using pre-lighting not deferred shading. I wonder whether lighting calculation is done by SPU or shaders.

Interestingly bullet decals are rendered by parallex mapping. Unlike unreal games, parallex mapping is not much used.

Generally the colors of buildings were well balanced from any point of view. I am guessing it is due to artists' effort or good supporting tools. If artists work on Max or Maya and have to pass through a long contents pipe line then they can hardly response to the final result.