solution « Haxpor

Posts Tagged ‘solution’

RealKo Engine updated

Wednesday, November 11th, 2009

Hello you guys.

I have updated RealKo Engine to fix the issues proposed by users at

Aeronautical Radio of Thailand LTD.
There are major 4 issues as follow.
1. Lots of resource being loaded is too large, slow loading process should be avoid
2. Changing the new offset of airport should affect others transportation object (airplane, cars, etc)
3. Be able to flexibly add new type of airplanes.
4. Option to enter the test scene, for fast debugging and testing simulation

I have written the possible solutions into text files which you can download it from the link below.
Issue 2, 3, and 4 are already fixed but left 1 as the long process to tackle down.

If you want to see more detail about how I tackle those issues, please those downloadable file below.

[Brief]: For what I can say to you now is that, RealKo Engine can now flexibly add new type of airplane. In fact, I have changed the name, and internal format of airplane to transportation object to let it be more generic and support wide range of objects in the simulation. So they can be airplanes, cars, helicopter. Ha ha, thus now very flexible to use.

For a little more detail, the transportation object now consists of 3 rotateable meshes, users don’t need to specify them all in the config file, but they are all optional. This way, by becoming more and more generic in the format, the good is given to users. You can see the detail of format of transportation of config file from the same solution file below.

The main problem is the resource management and loading. I have tested it, and it requires at least 2GB to handle those models, airplanes, and etc. Note that those model of airport and airplane is the most complex one that will be really use in the simulation, it’s Suvarnabhumi Aiport. So if I can tackle and find the way of rewriting the content management to be more efficient then it will cover all others airport. :)

And I want to say that from now on, a changelog will be available so you can see what’s updated.

See you next time.

[Download: Solution File, ChangeLog]

Tags: fixed, fixing, realko engine, solution, updated
Posted in 3D Grahphics, Journal | 2 Comments »

RealKo Engine: Map 07 updated

Friday, July 17th, 2009

After a prolong working time of RealKo Engine.
Now it’s in the final state to release it to my client, Aeronautical Radio of Thailand.

Below is the very mess talk of mine for today closes to morning (not even check the grammar). Many things will be exposed in talkative way in some forms. You may enjoy those topics and get some idea from my working experience with RealKo Engine.

At first, the Suvarnabhumi Airport model is now updated to version 7. Slightly improvements of model-optimization and little-by-little adding the mesh-by-mesh into the big model come in each version. I mention my great artist of all time again, P.Yod (as you may be familiar by now. :).

Lots of the detail can be packed into one big airport model whose the size is accumulated up into about 41 MB for now.

Airport Model
It’s easier to create the airport model which includes everything important with it into one model file. Its children can be ranged from trees, runways, taxi way, buildings, towers, skydome/clouddome, and others. As they are all initially set as static mesh, they should be packed together for convenient use, and also with the specification for the usage of engine that must be able to support all other airport model as well. Consequence of these will give you pile of papers designing about the system to handle its meshes and other supporting component too.

Some of the meshes inside the model can be treated differently such as tree, light on the runways, and fog mesh must be drawed with alpha-enabled. Thus the mesh management comes to play with the important role. Note that I used deferred shading for my rendering pipeline.

Now with 2 big categories to be handled, opaque mesh and alpha mesh.
This links into another aspect of something called “Entity and Type ID”, in which each mesh of the airport model must have its own ID and TypeID to identify each mesh from another and to tell the engine to handle it properly.

In fact as I have choosed “Deferred Shading” as the main driving force for my engine, many other supporting components will come into consideration without any invitation. We have to manage the mesh type, update them, draw them properly, and handle light calculation correctly as well.

If I talk too much, the subsection of Airport model will go too far, so I will limit myself to only I intend to talk here.

Actually as the generic engine that support all other airport model purposed in the specification, it gives much the flexibility for modifying each mesh, separating content from logic code, add/remove each mesh with different type easily without modifying any line of code, the config-file system comes in handy and very flexible.

Shadowing System

At the current state, it need to be fixed in the future. Due to the shadow algorithm that can support the large area is called “Cascaded shadow maps” need some time to implement. I cannot accomplish adding this feature into the engine due to lack of time to implement as it closes to the final release time. Can you guest, how do I solve this problem anyway? I solve it by using only the small to medium area of shadow. Only partially part of the area on the airport’s ground can be shadowed, not all. This limits to some kind of light source that can cast shadow which are spot light and directional light. It gives the acceptable and mid-quality of shadow, realistic at enough range but if too close it can pose some jaggy pixel. The situation to use my solution shadowing system is to find some objects that can cast shadow and adding the spot light into it, then place them around the tower or airport map. This can give out the feeling at some point but not that realistic.

I can say something here that the engine itself need to render huge amount of number of airplanes at one frame.
The maximum that I have heard from some guys in the Aeronautical Radio of Thailand is 400 at once!
Imagine that one airplane’s triangles are counted as about 2700 tris. Then for 400, its’ 400 * 2700 = 1080000 tris.
So it makes sense right that the shadowing system need not to be that complex, hmm, may be I am a little bit of myself now! (Sorry for that, :)

Anyway it’s too huge to be processed, in fact the realistic number of airplanes that will be in the simulation at once is 125. Thus 125 * 2700 = 33.7k tris. It’s more reasonable to handle those data along with some simple culling from view frustum.

But nontheless, the shadow the need to be coverred all the area of airport will be implemented and integrated into the engine in some days in the near future, but not that close for now as I am very busy for taking the mid-term exam here, quite a shame again.

As I plan for future, I will implement “Cascaded shadow maps” with about 1-2 pieces of shadow map each with 1024 * 768 to cover all of my airport’s area. May be I need more that 1-2 pieces, it can be 3-4 pieces.

Rainy day

Some sort of the special effect that I have found the funniest time to work with is “rainy day”.
To create the rainy atmosphere, you need many small subsystem of many small special effect added together and give the final look and feel result.
They are

- rain drop
- rain splash
- rainy textureset (diffuse, normal, and specular)
- rainy and realistic sky/cloud
- lightning
- lighting flashes

By integrated all of above into the rainy scene, the small flaw of each one will never come out to the eye of viewer (or at least say little chance.) as the overall result will take the focus and blend them well altogether.

For my scene (as I will show you some of the rainy screenshots later on), I use 8000 raindrops falling at the negative y direction falling down to earth, 10000 rain splashes to simulate the feeling of rain drops hit the ground, rainy textureset for all the airport’s meshes that expose the feeling to the viewer, sky’s color is set to black as to suit for the other rainy scen algorithm such as lightning, lighting flashes, cloud’s movement and its looking much be some kind of shurbbly and less organized, ligntning is calculated in realtime and use the benefit from the mathematics to simulate the natural of brachning along the way of point, lighting flahses should be in natural and only some areas are affected by the lighting flashes, not the whole sky.

From my test bed, the cpu peaks when the lightning need to be drawed next frame. Also when the rainy scene starts the cpu peaks again as it need to initialize all of the particles of each particle system of rain drop, and rain splash. The lighting flashes run properly without any immediately flicker at the framerate.

The overall look and feel of the rainy scene can be achieved in this way. I personally believe that the rainy scene can be created from many small systems added together and produce the state-of-art visual graphics with less flaw noticed by any viewers.

I would like to talk about my idea on implementing the lightning and lighting flashes natural algorithm which will show less and less pattern to the viewers.
But it’s time for now, I should go back to sleep and read some books preparing for the mid-term exams as it only 1 weeks left.
Before we part, let’s see some of the screenshot from my map 07 below.

Thanks for your time reading the messy article above, :)

Tags: algorithm, cascaded shadow maps, cloud, component, directional light, Journal, lighting flashes, lightning, map 07, mesh, mess, procedural terrain generating, rain, rain drop, rainy, rainy textureset, realko, realko engine, shadow, sky, solution, spotlight, subcomponent, subsystem, suvarnabhumi airport, system, updated
Posted in 3D Grahphics, Journal | 3 Comments »

RealKo Engine: Airplane asset and their functionality

Sunday, June 14th, 2009

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 &lt; 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!!!