using game engine in designing a 3d-monitoring … in a container terminal is modeled. operation...

International Geoinformatics Research and Development Journal

Vol. 6, Issue 2, June 2015 44

Using Game Engine in Designing a 3d-Monitoring System For Container

Terminals

Shahvaroughi V.*, Momeni M., Jalali Farahani K.

Rahyab Rayaneh Gostar Co., Iran

*Email: [email protected]

Abstract

Operation registration in container terminal without planning and operating according to the plans, is either

impossible or wastes too much time and causes a vast range of costly problems, due to the speed and workload of

operations. In order to evaluate the level of matching between the operations and the plans, we need an efficient and

reliable monitoring system. The monitoring system must be in complete accordance with the reality and provide a

realistic insight to the planner and the system supervisor. Therefore it's one of their main requirements to prepare a

3D monitoring system for container terminal management. In this article we introduce a 3D monitoring system

made by Unity game engine. We have tried to design this system general enough to be usable with different systems

and for different purposes. Our main concern was how to create a general component which is easily adjustable for

different applications. Finally the system created, is capable of being used with different systems and applications

easily, efficiently, and only by changing a few settings.

Keywords: Container Terminal, Yard Monitoring, 3D Monitoring, Port Operator, Game Engine.

Introduction

In operation registration systems, there is a substantial need for monitoring the operation registration process and its

coordination with the plans. The reason is that in these systems any kind of inconsistency and lack of planning

imposes huge and irreversible costs. For instance if a container is put in the stowage by mistake, and after a vessel

stowage door is closed they discover this mistake, returning the container is so costly they prefer to pass it up even

though keeping the container in the vessel stowage is quite costly too. A monitoring system that shows coordination

of the operation with the plans can help prevent many errors and mistakes. In figure 1 the operation management

structure in a container terminal is modeled. Operation managers who execute the operation in the container

terminal, operation planners and high level managers who are responsible for answering the customers, consignees,

and authorities, strongly need a comprehensive and high-level view of the operations happening in the container

terminal and their status.

A container terminal monitoring system can spare its user (who is usually a manager, a planner or an operation

commander) the need for physical presence in the container terminal and direct supervision of the operation when it

is most compatible with the truth and induces physical presence in the terminal so that the user does not feel much

difference between sitting behind the monitoring system and being present at the terminal. The more realistic the

system shows events and incidents, the more comfortable and safer the user feels. The more similar the events are in

the monitoring system to the real events, the more attracted the user will be to the system.

Therefore to create an effective and efficient monitoring system, we have to focus our effort on how to implement

the system so that the user feels real in it. This phenomenon is called immersion. But why not use actual cameras

instead of creating a 3D monitoring system? The view actual cameras give to the users, is much more real than any

view we provide by animation. So why do we suggest to use 3D animation for our monitoring system instead of

actual cameras?

mailto:[email protected]



Although cameras give a more realistic image of what's going on in the operation yard, in practice they face serious

problems. First, for adjusting information to the picture we need a very strong OCR system. We also need numerous

cameras in order to have a thorough view of the yard. Sometimes natural barriers prevent cameras from seeing the

whole yard. Furthermore if the system has several users and we want the motion angle and camera rotation to be

adjustable by the users, we will need a camera for each user. Also adjusting the information of every operation that

is in progress and being registered in the information bank, turning the camera to the operation, filtering containers

according to their information and showing them and their status while they are surrounded by other containers are

quite difficult and sometimes impossible. And finally, the high cost of installing moving cameras and the space they

occupy in the yard are also obstacles that prevent every manager from using them.

Figure 1: The need for a comprehensive view of the container terminal in planning, management and operation

monitoring

Figure 2: 3D monitoring system in comparison with 2D monitoring or live monitoring by cameras.



Figure 2 shows 3D monitoring system in comparison with previous 2D monitoring or live monitoring by cameras.

As one can see, 3D monitoring system presents a very realistic view with possibility of access to a wide range of

information and yet it is much cheaper and more capable.

Background

Since the creation of computer graphic, hardware and software tools such as various languages and graphic APIs

like DirectX and OpenGL, very strong graphic accelerators and interactive tools like information gloves or 3D

glasses have been produced to bring the display closer and closer to the reality [2].

One of the tools that has improved fast and achieved a good position is game engine. A game engine presents a

collection of visual development tools and reusable software components. These tools are usually provided in an

integrated development environment in order to develop the games with a data-based approach faster and more

easily. Game engine is also called game middleware [3].

Video games and computer games are one of the subcategories of virtual reality. Based on the existing technology in

computer science and sciences related to it, virtual reality provides a digital environment for simulating the reality

where the user can interact with this digital environment through senses of sight, hearing, olfactory and touch in a

way that feels like the real world.

Research and practice in this scientific field started in the late second half of 20th

century but did not improve a lot.

But since 1989 and 1990, the concepts of virtual reality have adopted better and more acceptable shape and structure

and demands for using virtual reality technology in military, aerospace, complicated equipment, etc. have increased

considerably and this technology has started to grow quickly. Also the game industry has experienced considerable

changes and games with higher quality and better graphic have been created [1].

Virtual reality is functional in numerous and various zones but we can concisely refer to these as potential fields:

architecture, E-commerce, 3D shops, advertisement, 3D internet, teaching, simulating various equipment and also

dangerous operations for satellites, military operations, virtual cities like Second Life, information and monitoring

systems, tourism, sports simulation and online individual and group games [1], [4].

In most of these functions, the goal is for the user to experience a model similar to real life and walk in, control and

interact with a safe environment and even execute operations that are impossible in reality. Some of the best tools

that provide different facilities for creating virtual reality environments are game engines. The game engines created

so far, each have advantages and disadvantages of their own. But that which game engine is more suitable for our

field of work is quite dependent on our business needs. In general the main features of a game engine that place it in

a higher level are listed below:

1. Supporting more graphic interfaces. Like DirectX and OpenGL. The more graphic APIs a game engine

can support the more functions and capabilities it provides to create better and more complicated visual

effects. Also it facilitates outputting the simulated environment for more platforms.

2. Supporting programming languages such as C#, JAVA, etc. in working with game engines, the

developers are not very involved with basic functions in APIs and through existing high-level languages,

use methods and functions which contact the APIs from their inside and use their capabilities to implement

the environment and simulate.

3. Platforms. The more platforms (like Windows, Mac, Android, IOS, web, etc.) a game engine can output

for, the bigger market the creators have.

4. Meshes. There are different tools for creating 3 dimensional objects such as 3D MAX, MAYA, Blender,

AutoCAD, etc. each capable of producing files with special formats of their own which sometimes are

shared between them. One of the advantages of a good game engine is the ability to support meshes with

different formats of modeling programs and 3D making programs. This makes formation of development

teams easier and their implementation method more flexible.

5. Physics. It’s a general concept including elements, tools, functions and orders enforcing the laws of physics

in a simulated environment. Objects' collision to each other and not passing through each other, objects'

kinematics to each other, enforcing powers like wind, gravity, pressure, torque, etc. on objects, and many

other things are pillars of physics. Applying rules of physics makes movements and behaviors of the

objects much more natural and realistic and raises the level of immersion.



6. Shaders. Shaders are small programs that are executed on graphic cards and create special effects that

should be shown immediately. There are different shaders for effects of light, cameras (Shaders on camera

lenses), materials, shadows, etc. One of the advantages of a good game engine is supporting shaders in the

best possible way.

7. Terrain. Some game engines have another engine inside them though which they can create terrain

accidents such as ups and downs, dents, plant and trees. In designing these engines, some techniques are

used to implement the game field with high performance in the easiest possible way. These engines often

use billboard technique for creating plants and trees. This technique is a picture-based method and its

general essence is that instead of placing the 3D model of the trees and plants that have many details and

their render might be too heavy, a transparent picture of plants or tree leaves is placed on the plans and

these plans are constantly kept in an angle to the camera that they appear to the user to be 3D. They also

use a method called Level of Details (LoD) which has different levels of materials and 3D objects and

based on their distance from the user the appropriate level is loaded and shown to the user. For example

when the distance between the user and the object is long, there is no need to load a high and detailed level

of the object because the object and the material on it are not even completely visible. So in order to lighten

the processor's work load and lower the render operation, a lower level of objects and materials are shown.

8. Scene Management. One of the characteristics of a good game engine is a proper user interface that is easy

to use, so that they are highly functional, yet finding and managing the assets are easy in them and many

operations can be done by drag and dropping or connecting proper nodes.

Many famous game engines have been created and used so far. Some of them have been highly noted and found

great markets, while others have not been used that much. Among game engines, Unreal and Unity are used by

system developers the most. Unreal has more facilities and provides a more realistic game environment and Unity

makes it possible to program with C# scripts and output for different platforms and it is more compatible with .net

environment and.net programs [5]. Finally unity was chosen to be used as the game engine due to its compatibility

with what the development team expected of the game engine.

Developing 3D monitoring systems for container services using game engines

How the users move in 3D monitoring systems is very similar to FPS games. The difference is the guns and fighting

devices are eliminated and the user only moves around in the yard and interacts with the objects. After determining

the requirements of the system and the operation to be shown in the monitoring, the first phase is developing very

low polygon models of equipment and objects to be shown in the monitoring.

For instance, in a yard there may be more than 30000 containers and numerous transtainers, truck and other

container transportation equipment. In such cases even one extra vertex in each model may cause too much

overhead for the system when a large number of the model are made.

3D MAX was used for the implementations in making the models and Box Modeling technique in this tool was used

to make the models. The next phase is mapping the textures on the models. The best textures are made from the

pictures taken from the equipment in the yard. In fact, the models themselves are developed based on the pictures

taken of the equipment from different angles. This makes the textures completely compatible with the reality and

mapping the textures much simpler.

After the modeling and texture mapping process is done, it's time to make the animations required for showing the

operation of different transportation equipment. It's necessary that these animations have the least key frames so that

the output is not too heavy. Finally all the animations are output in standard formats like obj, 3ds, Fbx, etc. The

output format depends on what formats are supported by the game engine.

Other techniques that help improve the quality of the monitoring yard render and also decrease the load of render are

Texture Baking, Normal Bump and light Map (9). The models and the yard can be rendered in 3D MAX, MAYA,

etc. using advanced techniques like lighting with V ray, textures including lights, shadows and bumps are created

and instead of real time lights and shadows, textures made and rendered by advanced tools are used in the game

engine.



Figure 3: A general schema of the primary system developed and the real picture of the container terminal yard

Figure 4: Capabilities of the primary monitoring system in filtering, searching and making adjustments for surfing

the information of the container terminal

In other words using static lights and materials instead of their dynamic version is a technique which can be

substantially useful in lowering the process overhead because lights and shadows are only counted for moving

objects. Picture 3 shows a schema of the primary 3D monitoring system next to a real picture of a container

terminal. In this picture 30,000 containers are seen at once and only with the help of the mentioned techniques

loading all of them in a single picture has become possible.

Structural study of the simple primary system

In the primarily developed system whose general schema is shown in pictures 3 and 4, the system has a very simple

form. A DLL is made as a data access layer which extracts yard primary information from operation registration

charts and shows the containers in the yard based on it. Subsequently, by constantly controlling the database of the

container terminal operation registration system, each yard-related event in the system (including loading, unloading

or container displacement) is registered and the registered information is extracted from the system and sent to the

unity for display.

Facilities like filtering the containers based on a specific feature, loading, unloading and displacement operation

display, searching a specific container, showing a container's features by clicking on it and showing an operation's

features by clicking on its equipment are some of the factors provided in this system (however limitedly).



Figure 5: Software structure of the primary 3D monitoring system

In picture 5 the general structure of the primarily developed software for monitoring the container terminal is shown.

The application runs in the template of an application unity. Coding information in this picture implies factors like

terminal yard map, the containers' size, etc. which are adjusted in a separate part of the system. Data access layer

takes the information directly from container terminal operation registration system and applies it in the developed

application using the unity without any interface. The information registered in the container terminal is received

and shown in the unity display environment by the application under the game engine using this DLL.

Figure 6: Limited capabilities of the unity in building forms and showing the information

However there were some basic problems in developing this application. The first problem was limitations and low

speed of creating the forms and information display context. Picture 6 shows an example of the primarily developed

forms using the unity. For making the adjustments, viewing the reports, searching, etc. appropriate forms that are

able to cover each of these operations must be created by the limited facilities of the unity. All these were created

limitedly in the primary system but in the structure it was impossible to develop them quickly enough to be

compatible with the users' needs. In addition for showing another yard it was necessary to provide the coding part

for that terminal and develop the application for that yard again. Therefore to monitor each yard, the coding part of

that yard had to be made. Furthermore to work with different information registration systems, separate systems

needed to be made for each system and a single monitoring system could not simultaneously monitor several yards

whose information are being registered in different registration systems. And the last problem was that the

monitoring system with the current structure had a low reusability and to use it in various places and monitoring

various systems, different parts of the system had to be refactored.

3D-Monitoring Unity Application

Coding Data

Data

Access

3D-Monitoring Representation Component

Game Engine OpenGL API



Evolving the primary 3D monitoring system into a reusable component

It can be concluded from developing this system that if a system is supposed to be reusable, the unity part needs to

turn into an independent component so that it can apply to various applications. This way it can be delivered to any

programmer as a component and the programmers can adjust and use it however they want.

Thus, developing the system was divided to two basic phases. First, creating a 3D monitoring component

independent of any container terminal management system, and second, using this component to develop a

monitoring system and connecting it to the container terminal operation registration systems.

Figure 7: Evolving the primary monitoring system to a component

However there were substantial problems in the process of turning a unity application into a component. The unity

application, despite using C# codes, does not present an application executable by .net reflector and can't be used in

a .net component. Therefore we needed to apply Inter-Process Communication techniques to use the unity's output

program as a .net component. Among common Inter-Process Communication methods in .net, first WCF was

considered by the component developers but more researches showed that MONO (7, 8) (that compiles unity C#

codes and turns them into executive codes) does not completely and properly support WCF. Therefore in this part

communication was made by the old method of .net Remoting. Picture 7 shows a schema of the developed

component and its use in .net forms. Settings like coordinates, yard blocks, stable objects in the background, etc. are

adjustable in the component settings and the component can be easily used by adding the DLL to the program's

references.

In fact when the component is loading, the unity application is hosted in the component and the primary settings are

sent to it. For accomplishing the communication between the unity application and the component, which as

mentioned above is done using .net Remoting, we defined an interface that includes all possible communications

and is implemented in the unity and calls through the component. Picture 8 shows the communication structure

between the unity application and the component (referred to as SDK in the picture). As seen here, all the

communications between the unity application and the caller control are organized as an interface named interaction

manager.

Figure 8: Evolving the primary monitoring system into a component

Unity

IInteraction

Manager

SDKDLL

IDataProvider

Find Container | Device

Filters

TransparentLayer

, ...

Application



Restructuring into customer-service provider system

Several approaches were considered for developing the application using the created component. One of them was

developing an application without an information access layer and leaving this part to the operation registration

systems. Picture 9 shows a general structure of such systems.

Figure 9: Software structure of the monitoring system without a server

A standard template was defined for receiving data and every system that wanted to use monitoring, could develop a

DLL as an information access layer and present its data in a format displayable for the monitoring. The information

access layer presented by operation registration system must implement the interface shown in picture 10.

Figure 10: Interface of designing the information access layer

The “DoAfterSending” function is placed in the interface to enable the operation registration system to inform in its

own system after monitoring the operation sent. Operation registration system can implement this part in any way it

wants. For instance it can assign a separate server to manage sending the information to different applications. Or

this part can be programmed to receive the information directly from the information registration system of the

database.

interface IMonitoringDataProvider{

MonitorData GetMonitoringData();

void DoAfterSending(MonitorData objects);

}

class MonitorData{

List<Object> monitoringObjects;

object sourceData;

}

class Object{

Enum_Action Action

string ObjectName

string DestinationPosition

Enum_Device Device

string DeviceNumber

List<ExtraInfo> ObjectInfo

string Position

int SenderID

int Size

int TerminalID

string TypeCode

}

3D-Monitoring Application

Data

Access

3D-Monitoring Component



In order for the monitoring system to cover several operation registration systems, a monitoring server can be

dedicated to receive the DLL which implements access to the information of various operation registration systems

and manage the interaction between monitoring applications and operation registration servers. In picture 11 two

primary architectures suggested for this system are shown.

Figure 11: Two customer-service provider architectures suggested for the monitoring system

In the solution on the right, the operation registration systems, by calling the web service, register the operation

information in the database related to the monitoring and the monitoring applications show the new application by

checking the database related to the monitoring.

In the second solution the same method is used except here communication with the server in the data access layer is

accomplished through WCF technology. Also a monitoring feeder service is written for each operation registration

systems that implements the same presented interface and sends the information of all terminals whose operation

registrations are done through this system to the monitoring controller in the standard monitoring format.

Four-Piece architecture: Senders, Accumulators, Receivers, and Viewers

Finally we got to the four-piece architecture shown in picture 12. For operation registration systems, a component is

designed to send the information of the registered operation to the monitoring server while the operation is being

registered.

In this kind of architecture, the registered operation in every operation registration system is sent to the monitoring

applications in message templates from these systems. There is a monitoring server which we call an accumulator.

This server is responsible for delivering the messages. It receives messages from different operation registration

systems and sends them to monitoring applications (clients) that are monitoring the yard and their operations are

being registered by the operation registration system.

For each operation registration system there is one sender to send the information of every action in the yard

(including loading, unloading and displacement) to the accumulator. Of course before it sends the information to the

accumulator, it changes them to templates understandable to the accumulator. Therefore one of the basic pillars of

the system's correct application is that every operation in the storage is delivered to the monitoring server through

the sender component. The information conversion enables the system to easily adapt itself to different kinds of

operation registration systems. Because in using the monitoring information sender systems, the system has to

change its operation registration information to a standard form understandable to the monitoring system. For

sending the information to the monitoring system, there must be a service to undertake this task. We provided a

sample of this service which needs an information provider in order to work like what we mentioned in chapter 6.



Every few seconds this service receives the data which are changed into monitoring standard data, about the

operation in progress in the yard through “GetMonitoringData” and sends them to the monitoring accumulator and

then calls the DoAfterSending function related to the information provider.

Figure 12: Four-piece architecture for the monitoring system

Operation registration systems can use this service and stop at preparing an information provider or, based on their

own needs, program a service to send data to the accumulator. In order to inform the monitoring server about the

storage primary inventory, this same service can be used and for every primary inventory of the storage, a series of

unloading operation messages are sent to the monitoring server. For the accessible operation registration system,

whose data was used to test the application with, a small application was made to send the yard primary inventory as

a series of unloading operation to the service. Picture 13 shows a schema of the execution of these two applications

on a system, exchanging information.

Figure 13: A schema of two applications, the monitoring server and the message sender, running on a system,

exchanging information

An overall view on system workflow

In the monitoring server, all the transactions that happened in the terminal since the installation of the monitoring

system are saved. This helps us to have the storage inventory at any time in the past or present. It's also possible to

predict the storage status in the future by adding operations which are planned for the future.



For instance, if a user wants to see the whole storage inventory for two days ago (a user defined time), he/she sends

the request to the server via the monitoring application. The accumulator accounts the storage inventory by viewing

the loading, unloading and repositioning operations done till the defined time and ignores the transactions after that

point. Subsequently the user can request all the transactions since 2 days ago and the monitoring server sends them

one by one and the user can observe them in a short time with a high speed (all these settings are done according to

the user's will) and see how the previous storage inventory transformed to the current one.

This approach (All the transactions are saved in the server but only the current storage inventory is saved in the

application) solves many problems. For example you can send virtual transactions to the application from the server

for the storage's future application planning and measure your planning efficiency.

eq(1) shows how the inventory is accounted based on the container terminal transactions. In this formula nt is the

number of unloads from the beginning till the time t in the container terminal. mt is the number of loadings from the

beginning till the time t in the container terminal.

This formula can also be used in the cargo inventories; therefore it is extensible to every kind of storage. eq(2) and

eq(3) shows the way storage inventory is accounted based on the transactions of cargo storages. q in eq(3) shows the

number of the items that have entered the storage from the beginning till now. The first formula accounts the

inventory for one item while the second one accounts the inventory for the whole storage.

The thing to be considered here is the similarity of the units for loading and unloading. You can ignore packaging

and use weight as the only criterion; but if you want to take packaging into account and know how many packages

of each item there are in the storage, you must be careful for the loading and unloading transactions of the categories

to be the same.

Additionally this method makes it possible to show and register all the transactions in the container terminal. By "all

the transactions" we mean the transactions that take place in different parts of the container terminal. A container

terminal includes at least three parts. The operation yard between the sea wall and the yard (berth), the container

yard (the terminal storage- the stacking yard) and the terminal's land facing zone (including gate, etc.)[10].

The transactions in the berth including loading and unloading the vessel are often done by the cranes. These

transactions can be modeled just like the transactions in the yard. The only difference is that here we have a vessel

instead of a block. Also in the gate transaction, the job is still loading and unloading, but instead of loading to and

unloading from the vessel, loading and unloading takes place from the first yard to the second.

Basic features of the accumulator

The accumulator in the designed monitoring system works as a center for controlling, sending and receiving

message. Different operation registration systems can send the operation information from different yards to the

server through their senders. The server is responsible for managing to receive these transactions. Certain errors in

the sent messages might prevent the server from receiving and saving them in the saved transactions. The most

important problems are listed below:



Resending a message

A unique number is assigned to every message. This number must not repeat; otherwise the system recognizes it

and sends a message to the sender explaining that the message is repeated.

Message of reloading an object (a container) that already exists in the storage

This is determined by checking the last transaction of that object.

Message of loading or displacement of an object (container) that does not exist in the storage

This is also recognized by checking the last transaction of the object in the storage. One of the essentials of this

monitoring system is for the objects to have a unique ID; otherwise it's not recognizable by the monitoring system.

In addition to the senders, the receivers register their names in the accumulator server and the server, according to

their current choice, sends them the operation of the storage they are viewing. The communication to the

accumulator, from the sender or the receiver is done by WCF technology.

Receiver

The receiver and the monitoring viewer can both exist in an application or the receiver can exist as a service on the

system so that if the application is closed it is still able to receive information and adapt the storage inventory to the

storage inventory saved on the user's system.

The viewer

A viewer is an application responsible for 3D display of the yard's inventory and also supports the possibility of

searching a container in the yard, various kinds of filtering based on each feature of the containers, observation,

studying and surfing the operation information, etc.

Figure 14: A schema of the monitoring application while monitoring a container yard

Special features and results

The developed monitoring system has special facilities and capabilities which make it very convenient and easy to

use. The monitoring component can easily be used in any application by changing very simple settings. Only by

introducing a data source for it and applying an operation information injection function, a monitoring system can be



made for any kind of storage. Turning the 3D monitoring system developed using a unity which is very difficult to

use as an application and adjusting it for functioning in different situations and applications, to a component which

is easy to use in a .net application only by changing a few simple settings, is quite helpful for quick development of

different applications using this module and it makes it possible to work easily and quickly.

The monitoring application is developed independent of the server and possible to be used easily as a very simple

interface by providing required information. The application can be used alone only by development a data

convertor for the operation registration system and introducing it to the program as a DLL. The program can easily

answer to the monitoring needs of any storage operation registration system.

The developed server provides the monitoring with vast capabilities of management and monitoring information

arrangement and exploiting different possibilities of the monitoring application by the user and it can guarantee

periodic connection and disconnection of senders and receivers, consistency and integrity of monitoring data and

manage and control the connection between senders and receivers of monitoring information in different situations

with high error tolerance.

The developed sender limits working with the monitoring server to the data convertor unit and manages sending the

operation data to the monitoring server. Everywhere possible in these systems concurrent simulation techniques is

utilized to heighten the work speed as much as possible. In the unity part many techniques are used to, while being

fast, not to use microprocessors so much that results in system hang up. Some of these techniques were introduced in

chapter 3.

Converting the monitoring system architecture to four-piece architecture in which each piece is independent from

the other, provides significant power and freedom in developing the monitoring system and helps considerably in

decreasing faults, preventing useless vast data transfer, low speed and the monitoring system becoming unusable.

Conclusion

In this article we explained the architecture of a 3D monitoring system for container terminals when the 3D part is

developed by unity game engines. The four-piece architecture chosen for the monitoring system includes an

information sender, an accumulator, a receiver, and a viewer, all independent of each other which provides

significant power and freedom for developing the monitoring system. Decreasing the errors and avoiding a vast

range of information transfer are other advantages of this kind of architecture for the operation monitoring system.

But the most important advantage is the reusability of each piece and most of all the monitoring independent

components for developers of the applications.

As future system developing solutions, adding the facilities for different display equipment and creating the

possibility of designing and using the operation method for the equipment by the users are some of the factors that

must be developed. Other proposed factors so far for making the system as realistic as possible are: using this

system in monitoring different kinds of storage and creating a tool for visual designing of the storage floor shape and

map, facilitating user display and sounding for different operations.

References

[1] Ping Z. Q., A survey on virtual reality, Springer, Science of china, (2009).

[2] Sutherland I. E., The ultimate display, Proceedings of the International Federation of Information Processing

(IFIP) Congress, pp. 506–508 (1965).

[3] Lewis M. and Jacobson J., Game Engines in Scientific Research, Communications of the ACM, Vol. 45, No. 1,

pp. 27-31, (2002).

[4] Papastamatiou N., Alexandridis T., Tsergoulas K., Michopoulos A., Karadimas N. V., Virtual Reality

Applications with User Interface for Dynamic Content Development, Recent Advances in Computer Engineering

and Applications, pp. 201-206, (2011).

[5] Creighton R. H., Unity 3D Game Development by Example Beginner's Guide, Packt, (2010).

[6] Eberly D. H., 3D Game Engine Design: A Practical Approach to Real-Time Computer Graphics, Gulf

Professional Publishing, (2007).

http://dl.acm.org/author_page.cfm?id=81481651451&coll=DL&dl=ACM&trk=0&cfid=89415369&cftoken=22187923



[7] Costanich B., Developing C# Apps for IPhone and IPad Using MonoTouch: IOS Apps Development for .Net

Developers, Apress, (2011).

[8] Bluestein M., Learning MonoTouch: A Hands-On Guide to Building IOS Applications with C# and .NET, Addison-Wesley Professional, (2011).

[9] He Q. H., Zhai Y., Li X. W., Texture Baking Techniques on Construction of Virtual Reality Interactive Scenes,

Qi L. (ed.), Recent Trends In Materials And Mechanical Engineering Materials, Mechatronics And Automation, Van

Stockum, pp. 478-483, (2011).

[10] Brinkmann B., Operations Systems of Container Terminals: A Compendious Overview, Böse W. (ed.),

Handbook of Terminal Planning, Operations Research, Computer Science Interfaces Series 49, Chapter 2, Springer

Science+Business Media, pp. 25-39, (2011).

http://www.google.com/search?tbo=p&tbm=bks&q=inauthor:%22Michael+Bluestein%22

http://www.scientific.net/author/Qiu_Hai_He

http://www.scientific.net/author/Yan_Zhai

http://www.scientific.net/author/Xue_Wen_Li

http://www.vanstockum.nl/boeken/technische-wetenschappen-algemeen/gb/recent-trends-in-materials-and-mechanical-engineering-materials%2C-mechatronics-and-automation-luo-qi-edt-9783037850992/

using game engine in designing a 3d-monitoring … in a container terminal is modeled. operation...

Documents