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, :)
