US Patent 6,085,192 System and Method for Securely ...



University of Arkansas – CSCE Department

CSCE 4013 Virtual Worlds – Final Report – Fall 2010

Towards a Virtual ‘University of Arkansas’ Campus: Automating Terrain Import

Jon Holt, Tim Sexton, Edmond Snell, Seth Williams

Abstract

The aim of the Virtual Campus project is to develop a way to automate building 3D virtual worlds using GIS map data and other data from the real world. The demonstration will be to use automated tools to build University of Arkansas campus from data supplied by the UA Center for Advanced Spatial Technology (CAST). At present, in virtual worlds like Second Life, terraforming of terrain is a manual process, and it can take days to weeks to build a landscape. But with existing map data, we should be able to automate that process. We aim to create a script that plug-in to the Unity Game Engine and another for the Open Sim virtual world. These script will import map data in DEM format (available from CAST), convert this map into game representations to terraform a virtual terrain (prototype procedure completed).

A second step (not implemented yet) would be to use map data to autogenerate land use cover for forests, fields, lakes, and urban areas. The end result will (eventually) be a 3D landscape that avatars can visit and further populate with buildings. Using such an environment, in a third step, students could go to a virtual class or meet together at a virtual union. Their cell phones in the real world could inform the movement of their avatars in the virtual mirror campus. At present, many virtual campuses exist in Second Life but none that we know of accurately reflect the geography of their campus or location of their students.

1. Problem

3D virtual worlds like Second Life are multi-player social worlds where humans in the form of “avatars” meet with one another, use voice or chat to communicate, and can own virtual land, build virtual buildings and script (program) objects. Millions of people have downloaded the free Second Life client (like a browser). Currently, the only way to create a 3D virtual model of a real-world region is to do so manually. This involves hours to weeks of elevating terrain “by hand,” sculpting and placing roads and buildings, and filling terrain locations with vegetation. The result is often so inaccurate that we are unaware of anyone succeeding in developing an accurate 3D map of their surroundings (exception: accurate military 3D simulations do exist). Real world 3D elevation and land use maps exist but at present, there is no established way to import such map data into a game engine or a virtual world to create an accurately terraformed terrain. In addition, there is no current method to take use a script and parametrically populate an urban region with vegetation, roads, and buildings. If an automated means of building 3D worlds from map and land use data could be developed, it would expedite the process of building 3D games - but more than that, it would find application in so-called “serious games” in architecture, archaeology, military strategy, geology, and many other fields.

2. Objective

The objective of this research project is to create a script that will enable a user to import existing real world map and land use data to populate a 3D representation of that map in the 3D virtual worlds Unity3d and OpenSimulator.

3. Related Work

3.1 Context

The Everything is Alive project provides the backdrop for our project. The goal of this project is to create an “Internet of things,” wherein sets of computer applications can provide information about objects in the physical world by accessing virtual data [1]. This could even extend into functionalities that would allow objects to “communicate” with each other or humans. This is the idea of “pervasive computing,” and it would be useful in a variety of applications. Such applications would include biometric security systems, residential lighting/heating/air conditioning, or keeping inventory of assets in a building or company.

Our project provides an opportunity for users to keep track of objects in a certain space by generating a virtual space based on true-to-life map data. This virtual space could then be accessed by a personal computer or, potentially, even a smart phone. By accessing the virtual space, users could then remotely control their possessions with the assurance that what they are attempting to contact is precisely where they left it, in the same condition they left it in.

3.2 Key Technologies

Unity 3d Game Engine: One of the main goals of our project is to create a plug-in for the Unity Game Engine. This plug-in deals with one of the major limitations of this 3d platform. Namely, it is painstaking and tedious work to create a terrain that is in one-to-one correspondence with the real world location. Our plug-in takes in map data, provided by a user, and generates the terrain of the region given.

OpenSimulator: Along with trying to provide a plug-in for Unity, there was also a focused approach to create a similar application for the OpenSim virtual world. This application would also create the 3d terrain of a region based on the map data given. We knew it was possible to do this because of the work of the Intel Labs team that created a Virtual Yellowstone. Our aim, however, was to take their work one step further. They were only able to create a terrain that was only the land, not any of the vegetation.

3.3 Related Work

There has not been much work done on this particular subject. However, we did a significant amount of research into the methods used by the Intel Labs team in an effort to see how they implemented their Virtual Yellowstone in ScienceSim.

3.4 Related EiA Projects

Our Virtual Campus relates (or could relate) to these other EiA projects:

• Mirror World application: This is a fairly obvious correspondence. Our project creates the mirror world itself. The user can then populate with what they wish.

• Augmented Reality: This is also a fairly obvious correspondence. The difficulty with connecting these two projects is in caching information from other regions that the user is not directly accessing.

• Smart Phones: The integration of smart phone technology could make our project much more accessible to the general public. Perhaps we could create several virtual regions that would cover a large physical area. Then, any time the user was physically within our regions, they could explore, virtually, the area around them.

4. Architecture

4.1 Use Cases or Requirements

Depending on which medium you wish to work in, running our scripts will require that you are running either Unity or OpenSim. This creates the requirement that you have at least one of these programs installed on your computer. Additionally, to create the terrains themselves, then you must download Terragen or L3DT. Luckily, these programs are all free-to-use, or have free-to-use versions available online.

4.2 Tasks

Briefly outline-like list of the main tasks on your (team) project (indicate who did what).

1. Understand …

It was Seth’s job to do a lot of the initial research regarding Unity and terrain creation. He created my own terrain from scratch in Unity, which was a terribly tedious procedure. Through this process, He learned the steps that would need to be taken in order to create a proper script to generate terrain. To begin, it is necessary to create a terrain that is a manageable size for the general processor. This knowledge led me to the realization that to create a true virtual campus, it would be necessary to split the campus up into as many as 8 regions that were interconnected. After creating the base terrain, the proper elevations can be added by using a grayscale map. Then, the proper textures must be added to the terrain, which will be incredibly difficult to script. After that, assets can be added to the map, such as trees and grass or buildings and monuments. These must be created outside of Unity, and then imported in.

Jon’s goal in this project was to research methods and programs that could be used to create terrain both from scratch and based on map data within OpenSim: Researching information regarding terrain generation in OpenSim returned rather stagnant information. Much of what he was able to find was from many years ago and, as subsequent versions of Opensim were released, much of the information from these tutorials became useless. For the purposes of the project he was able to find that 2 programs (terragen and L3DT) were the most commonly used utilities in generating terrains for openSim. He decided to use L3DT to both create maps in .r32 format that could be imported into OpenSim as well as convert height field data from several file types into said .r32 format that could then be imported. Unfortunately all tutorials ealing with L3DT and Opensim terrain generation were so dated that they were of little help in figuring out how to create data using L3DT in a way that would properly load and display.

During the research phase of the project, Edmond found a plethora of information online where others had done similar work. The main task was then combining what worked the best out of these various techniques and combining them into a more manageable and straightforward process.

2. Design …

Unity Scripting - One of the first tasks that we decided to try was making a plug-in script for Unity. Tim was the lead coder on this portion of the project. This task was more difficult than we first realized because of the inability of JavaScript (the language used by Unity) to do some of the more difficult math effectively.

OpenSim Scripting - Edmond and Jon began working on the OpenSim plug-in, but never were able to get it off of the ground because of the steep learning curve associated with OpenSim. Also, because of OpenSim’s data type restrictions, the two had to rely on outside programs to bring in map data.

OpenSim and Unity Terrain Creation Using L3DT and Terragen - After being unable to design pieces of code that could automate terrain generation, Tim and Jon began working on a method to use outside applications (in their case, L3DT) to create terrains in OpenSim. Edmond, likewise, used Terragen to do the same for Unity.

3. Implement …

Figuring out exactly how to handle terrain creation in an effective and cost-efficient manner became the main priority after everyone’s focus shifted away from coding plug-ins. Steps were taken to document all of the methods used and all of the successful ways that each individual found to generate terrain in whichever medium they were working in. For Tim and Jon, this meant taking in map data, processing it with L3DT, VTbuilder and other utilities and creating a heightmap stored as a .png or .r32, then exporting this heightmap into OpenSim, then elevating the map’s height in OpenSim (thereby allowing depths below sea level, to a reasonable degree). Edmond used a similar approach with Unity, creating a heightmap with a file type acceptable to Unity, exporting it to Unity, then adding lighting and a first person viewer to allow the user to explore the terrain.

4. Test …

All groups came to the same conclusion: creating a tutorial that would be useful for creating terrains in whichever is the preferred medium. The work has a long way to go before it reaches the point where terrain generation can be dealt with automatically. The hope, however, is that through the use of these tutorials, future work can be done that will allow more researchers like myself (Seth) to find ways to script plug-ins using the same methods outlined above for terrain creation.

5. Report …

Seth was responsible for this report about the progress made by our group. Each group member shared their contributions, and they have also shared their tutorials, which document the most successful ways they found to generate terrains based on real map data.

4.2 Architecture/Design

For this project, we needed a source of real world maps. We used Geostore, which is located at . Here is a great tutorial for using geostor: 

A lot of knowledge was required to complete this project. So we began by researching (or, in my case, actually trying) terrain creation in Unity and OpenSim to provide a backdrop of the necessary pieces of a terrain. This research gave us the steps required for a piece of code to be made that could generate terrain for us. We also needed the knowledge of what image types could be used by Unity and OpenSim. Seth was the primary information gatherer, looking up whatever data was necessary while also informing the group of what direction the code needed to move in.

Tim primarily focused on scripting in Unity, in the hopes that he might make a piece of code that could auto-generate terrain. However, after running into some issues with single pixels either elevating to an incredulously high level or sinking to an infinitely low level, he abandoned that project and joined up with Jon to create terrains in OpenSim.

Jon and Edmond originally focused on scripting in OpenSim, but found out many more ways that they could potentially crash their systems instead of moving ahead in the terrain creation process.

So, Jon, as mentioned earlier, began working with Tim on just getting a terrain made in OpenSim.

Edmond broke off and found a way to create terrains in Unity by using the Terragen software.

Tim, Jon, and Edmond then designed tutorials which outline step-by-step processes to creating terrains in either Unity or OpenSim that are based on real map data being imported by the user. The hope is that a future researcher will be able to use these tutorials to discover a way to script a plug-in for one or both of these applications that will auto-generate the terrain.

4.4 Testing

Testing was done mainly in a trial-and-error fashion. There was not much data about creating terrains based on real map data, so it was difficult to get off of the ground and get working terrains built. The code that was originally written for Unity did a good job of getting most of the elevations for each pixel in a region correct, based on the terrain map given. Every once in a while, however, it would create one pixel wide peaks or sinkholes that skewed the final results of these terrains. After experimenting with potential fixes to these bugs, it was ultimately decided that it would be in the best interest of the group to scrap that project for the time being and come up with a way to effectively create terrains in a way that was not as tedious as making the terrain from scratch, but was not automated.

5. Results and Analysis

[pic]

This is what a newly formed terrain in OpenSim looks like. Through the use of Tim and Jon’s tutorial, you can take this terrain, and this heightmap:

[pic]

And create this terrain:

[pic]

Similarly, by using Edmond’s tutorial, a user will learn how to import a heightmap into Unity in order to create a blank terrain like this one:

[pic]

6. Conclusions

6.1 Summary

Although we were not able to create a working piece of code that generated the terrain automatically, we were able to create tutorials that will be helpful for future researchers in this area to look at. Even the failed code could be a significant piece of information that could be tweaked slightly to work.

We discovered that, to a large degree, we are branching into new territory that has yet to be researched by very many. The group at the Intel Labs has done a bit of work on auto-terrain generation, but they, too, have only gotten the ground level of work completed. There is still much to be better stood and automated in this area.

6.2 Potential Impact

This work is significant because of the sheer number of professions that would find it potentially useful to be able to load map data of a region and have a virtual, 3-dimensional space that they could explore. The impact reaches into architecture, engineering, asset management, geology, gaming, and even military application. In each of these areas, having a virtual space to explore would lend itself to new innovations and discoveries in how we interact with our world recreationally and professionally.

6.3 Future Work

Future researchers will be able to begin their quest for a piece of code which eluded us, one that will be able to create terrains based on heightmaps. They will be able to start where we left off, working primarily towards terrain creation by multiple sources. The challenge for them will be creating one plug-in or script that can call on many different applications and piece together the terrain from parts of each system.

Another interesting area, one Seth briefly touched on in his work with another 3D studio, Cinema 4D, would be creating the interiors of buildings based on floor plan data. Once a script was up and running for the outdoors, it would be a simple task to create a script that could potentially create buildings from the inside out that could be dropped into terrains built by the first script. This would make for a true one-to-one correspondence with the real world that would lend itself to further application in other professions, like building maintenance, city planning, etc.

7. Biography

Seth Williams: Williams is a junior in the Computer Science and Computer Engineering Department at the University of Arkansas. He has completed Programming Foundations I/II and Programming Paradigms and is currently enrolled in a Virtual Worlds course and a Game Design course. The Game Design course is focused on developing levels in the Unity Game Engine. Through these courses, he has demonstrated a capacity to complete small research projects. He was responsible for gathering information about Unity in the early stages of development, as well as researching the data types that were allowed by Unity and OpenSim. He provided knowledge of the Unity Engine to his colleagues when they required any additional help. He was also responsible for this documentation of the project.

Edmond Spike Snell: is a senior at the University of Arkansas majoring in Computer Engineering. He has completed many software and hardware courses and continues to demonstrate a great deal of interest in the field of computer science and technology. He is currently employed part-time by both the electromagnetic imaging and biology department at the UA working as a web designer and website manager. He was responsible for some of the early OpenSim work, as well as the creation of the Terragen/Unity tutorial and a small landscape demo.

Jonathon James Holt: is a junior at the University of Arkansas majoring in Computer Engineering. He has completed numerous programming and hardware courses at the university and is currently enrolled in Virtual Worlds. He is currently working with the University of Arkansas Sociology department on developing a website based video driven teaching platform and is employed at CAST. His role in the project was to first research OpenSim and ways of creating terrain within this virtual world. He investigated multiple utilities for custom creating of terrain as well as methods for converting real world data into formats capable of being displayed within OpenSim. He focused on the programs VTBuilder and L3DT in order to perform these operations. L3DT was used to create custom maps in both .png heightmap format as well as .r32 a 3D file format type. VT builder was used independently along with L3DT to create .png files from existing map data that could be converted and displayed within OpenSim.

Timothy Leon Sexton: is a research assistant for the Center for Advanced Spatial Technologies and a junior at the University of Arkansas majoring in Computer Science. As a research assistant, he has designed and implemented several mapping interfaces to real world data for a multitude of projects. Currently he is working on a virtual reenactment of the Prairie Grove battle during the Civil War, an NSF project to architect a 3D visualization lab for display of large datasets, a project for the University of Arkansas to track room use and provide analytical data to enhance decision making for future building remodeling and use, and is enrolled in the Virtual Worlds course. Tim’s role in the course was to assess the feasibility of dynamically creating and loading real world data for terrain objects. Initially he investigated writing a custom script within Unity to dynamically terra-form the terrain, however, this ended up not being feasible using the initial methods since the Unity scripting languages were not able to perform the mathematics needed. During the investigation he discovered a very handy program called Fractscape which allows a user to open height map data and modify it on-the-fly to generate a terrain for Unity. He then shifted his focus to OpenSim and working with Jon Holt to see if dynamic terrain loading could occur in that platform. While unable to find a method of scripting the loading of terrain dynamically, he found a method of loading a terrain to a virtual world when OpenSim was initiated. Using a simple script, he was able to get any elevation png file to terra-form the terrain in OpenSim on load.

Dr. Craig Thompson, Mentor – Thompson is a professor in the Computer Science and Computer Engineering Department. He leads the Everything is Alive research project that is currently focusing on how to simulate pervasive computing using 3D virtual worlds. See .

8. References

[1] Craig Thompson, “Everything is Alive,” website:

[2] Fashion Research Institute. (2010, January 24). A Glimpse of the Future of OpenSim: Virtual Yellowstone National Park in ScienceSim [Online]. Available:

Appendix A – Deliverables Manifest

• Final Report

• Tutorial pdfs

• Tutorial videos

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download