Haxpor

Welcome back my friends.

Lots of improvement in term of airplane asset and its related functionality inside the engine have been done. They are now quite close to stable.

For what I have planned before dumpping myself into the code is this.
For the airplane asset configuration, there are many type of airplane such as “Boeing 747 - 100 class”, or “Boeing 747 - 400 lcass”, thus I plan to let the user who implements upon my engine to edit the config file. By inserting the information about all type of airplanes that will be used in the simulation, in this way the engine will know how to treat each type (but not too flexible, due to the limitation on particular artist-method => there are many ways to do things, so the limitation on this will surely comes to play.) and hold all of the information.

Anytime user wants to create new airplane entity and put it to fly over the airport. He/She just grabs the desire type of airplane information (which now already loaded prior to the content-load period)  from the engine, and create one.
As you may see the flexibility for creating process,  content-loading process, and clean code can be achieved. Thus user can be more focus on the core part of the simulation itself, not wasting time too much on misc steps to create just one another airplane entity.

In fact RealKo Engine relies heavily on the config files. All of the model which are airport, airplane, skydome/clouddome, and others to come will use the config files. You may ask it’s a bit of cumbersome to edit the config file and thus giving the slow on setting up the scene. But it takes time at first but then after user specifies all the assets’ information, user can now be freely from that part and move into the actual core of the simulation. The final result is better and better. Anyway not all the engine uses config files, it’s up to the situation and case. For RealKo Engine, I must le t the user freely specifies new type of asset, enable them to modify the resource (not worry about file name, name of file can be changed, but just reenter that name in config file.), and it some assets are modified by user, they can reedit the config file and keep going. So at this point I think you have got what I mean. ;)

Okay, let’s talk about airplane. Airplane has lights, right? That’s true. But my clients said that Suvarnabhumi Airport can hold about 400 airplanes at once! If you think along with me, one airplane can have at least about 5-6 lights attached to itself. RealKo Engine powered by the Deferred Shading Rendering System, thus it can support more light (specially for many small point lights, as they’re cheap.). But not for this, if we use real lights attached to each airplane.
If we do so, 400 x 5 = 2000 lights will be on the scene at once, hauhhhhh!!!!! At first glance this is not possible at all.
Nevertheless that I already know it’s not the solution I will take and go on with it, but I will test it anyway.
By inserting the lights into the scene for 2000 lights, my GTX 275 is pulled down to earth at the rate of 2 fps. Immediately I switch back to another solution ….

Another solution suggested by my artist leader (P.Yod), he said that we will use the textures instead of lights. I agree and it’s the similar thought as mine as well. One drawback if we use the textured light is that “far far away, we may not be able to see the light, and some visualization will be gone”. If the textured light is lit by light sources in the scene, absolutely we will not be able to see the light of airplane in the night (in which we must have light shows well and clearly in that time!!).

After P.Yod sent me the airplane resource, and I saw the textured light is alpha texture. The solution just come out directly from my head. We will draw it externally after deferred shading process is finished thus this will give the best result as the particle system that I have faced it before and solved it. By drawing the alpha textured light on top of deferred shading result, the light-calculation will not be taken into effect, and we see it clearly in the night, for the day time, the alpha textured light will be blended nicely with the pixel already resided in the color buffer and thus it will automatically reduce the strengh of textured light attached to airplane. WOW!!!! (In the night of course, mostly the color in the color buffer is quite close or in the theme of black color, thus it will step up the strength of texture lights attached to airplane.)

There are 4 types of light for airplane.
1. Window light, light coming from the inside airplane through the window. Thus simulating the night time.
2. Head light, turn on before landing process begins.
3. Signal light, always blinking at night
4. Ground light, will be turn on when airplane landed or touch the runway (thus simulate the realistic light, but infact it’s just the textured light.)

To draw those lights stuff correctly, I decide to create just another effect file for those light-type.
I categorize the light into 2 types.
1. Non-blinking light
2. Blinkging light

Both of them is similar in code, but just when doing this stuff for blinking light, I use the current time from engine, and put it into sin() function to calculate the intensity to be applied to texture light. Thus it will be like blinking!! That’s all, simple enough.

See that section of code from my effect file to draw the blinking light below.

float4 PixelShader(BasicPSInput input): COLOR0
{
	float4 color = tex2D(diffuseSampler, input.TexCoords);
 
	//calculate the light intensity used specially for the signal light (blinking effect)
	float intensity = sin(time);
 
	if(intensity < 0)
		intensity = 0;
 
	color *= intensity;
 
	return color;
}

I think you already get the idea from seeing the code above.
If the intensity is below 0, then I will not take any risk to multiply the color with negative number, I just want it to be dissappered. So let it be zero, 0 will be better.

When combining the particle scene with the airplane, in the time of collision or just normal weather effect.
The visual effect is more enhanced in the way we can feel it, and appreciate the result it can give us.
(Remember that deferred shading is backed the engine up, so the lighting calculation is more neatly and at least cost as it can be, thus giving another advantage.)

Enough for chitchat now, let’s see the real stuff below.
Please enjoy!!!