Portfolio and Technology Blog: 20 Years of Tinkering

In my last post on exporting Google Earth models into UDK, I linked to a video that covers the basic steps to export models from Google Earth into 3DSMax, using 3D Ripper DX.  Once you have the GE models in 3DS Max, complete with textures, its simple enough to export the scene as a .fbx file into UDK.  After you've worked through the process a few times, its pretty straight forward and easy to execute.  However, there are still some limitations.

1. While the textures render okay in 3DS Max, their .dds format is not acceptable for UDK.  So, these textures have to be batch converted to an acceptable format (i.e. tga) if you wish to include them in UDK with your .fbx model.  This can be done using IrFanView Batch converter, additionally utilizing the "All Plugins" plugin to recognize .dds filetype. After IrFanView and the plugin have been installed, proceed to this video (starting around 1:15) to setup and use IrFanView to bach convert your files properly for usage in UDK.  The only exception here is that in the video he is convering .jpg textures exported from Google Sketchup.  Simply swap this workflow out for .dds textures exported from Google Earth.  The rest of the steps will be the same for our uses.  After the batch conversion is complete, you should now have 1 .tga texture for every .dds texture.  In some cases this could easily be thousands of files.  Here is where manual work comes into play.  Every tga texture needs to be imported into UDK, with a material created, and manually assigned to your model, in place of the current .dds texture assignment.  And while this is possible, it is extremely tedious if your scene has anything more than a dozen buildings, which could easily be hundreds or thousands of textures…  I went through this, and it is painful.

Luckily, a reader of this site has been working on simplfying the entire workflow, and has thus far come up with the following:

1. Capture with 3D Ripper DX
2. Using IrfanView’s batch conversion, convert all the .dds files in the Textures folder to .png (or .tga, or any other texture file type UDK will accept)
3. Using a text editor, open the .mtl file in the Frames folder. Use find and replace to replace all “.dds” with “.png” or whatever file type you converted the dds files to
4. Using a text editor, open the .obj file in the Frames folder. At the very top, type "mtllib (*FILENAME*).MTL", where *FILENAME* is whatever the filename of your .mtl file is
5. Move all .obj, .mtl, and all the .png files into the same folder
6. In 3DS Max, import the OBJ file.
7. One, possibly two, .png files will be missing. Hit skip both times.
8. Run the MaxScriptForMakingMaterialsShowInViewport.ms script (included in this zip).
9. Run the MaxScriptForAdjustingSpecularHighlights.ms script (included in this zip).
10. Run the MaxScriptForCloningAndAddingUCX.ms script (included in this zip).
11. Export the scene as a .fbx file. Make sure the the Embed Media checkbox in the fbx export options is checked.
12. In UDK, import the .fbx file. Make sure that Import Materials in the import dialogue options is checked.

This simple workflow saves so much time, its not even funny!  And as a bonus, the models will now even have rough collisions in UDK.

There is one other final thing to consider, Scale.

Setting the correct scale in 3DS Max for use in UDK

Assuming we want our Google earth models in UDK to be as close to reality as possible (in scale), we need to adjust the Unit settings in 3DS Max to match the Unit settings in UDK.  That way if we know a building is 12' tall in Maxm it will also be 12' tall in UDK.

Create dummy box in Create Pane to represent a 6’ tall person

 
Select Modify pane, and set the following:

• Length: 32
• Width: 32
• Height: 96

Update Max Unit system settings to map to UDK scale

• Customize > Units Setup > US Standard > Feet w/Decimal Inches > Inches 
• In same dialog, System Unit Setup > in the “1Unit =” field press CTRL+N to open calculator.
• Input 12/16 (12” divided by 16 Max units).  This equals 0.75.
• Paste value into the 1 Unit = field.

Note: 3DS Max will not save these settings by default, and they will have to be re-applied everytime you open a new scene file.  Unless: 

• Create a new scene, apply the units setup above, save the scene as "maxstart.max" to "MyDocuments>3dswMax>Scenes"
• This will start max every time with this same scene. 
• You can use this for units setup or anything esle like lights, geometry, etc.

This will translate 96 Units into 6’0.0”

Now that you have a proper reference, and a matching unit scale from 3DS Max to UDK, scale your captured model to match the scale of the 6' block.  In general, I found that scaling the captured model up 3 separate times (by 100000, by 100000, and by 62000) worked for me as a close enough approximation.

In a previous post, I provided an outline for exporting models from Google Earth into 3DSMax.  The next step is to export the models from 3DSMax into UDK.

After a few weeks of extremely manual work, mostly revolving around textures, here is my neighborhood in UDK.

Notes:

1. Models exported from 3DS into UDK (originating from Google Earth) will not have collision data out of the box.  However, there is a simple work around:  In 3DS max, create a copy of every model, and rename all the copies with "UCX_" in front of the original name. Export the whole scene from 3ds max as an FBX.  When importing into UDK, in the Import Options menu, under Static Mesh -> Advanced, check "One Convex Hull Per UCX."  The collision with that isn't the greatest, but it's good enough to be able to walk around in the city for the most part and it's certainly a lot faster than doing all the collision by hand in 3ds Max. If you don't check the One Convex Hull Per UCX box (normally you wouldn't if you'd built the model and collision mesh yourself), the collision goes completely bonkers in UDK because of all the planes and concave meshes.
2. The textures associated to the models captured from 3D Ripper DX and imported into 3DS Max will be in the .dds format.  That's fine if you stay in 3DS Max.  However, if you wish to export the models with textures into UDK, the .dds extension is not recognized (thankfully, the texture coordinate data will still be there, just not the textures themselves).  To get around this, you need to batch convert the .dds files into .tga.  I used the IrFanView batch convert to accomplish this task.  However, you will also need to extend the extension capability of IrFanView by installing "All PlugIns."  This will allow the program to recognize the .dds extension, from there you can proceed with the batch conversions.  If you need assistance on the settings you should be using in IrFanView to create the tga files ready for UDK, reference this video (about 1:30min in).  Finally, with all of your tga textures ready to go, import them all into UDK.  Next, double click your static mesh in UDK to launch the Static Mesh Editor.  Under LODInfo > [0] > Elements is a listing of all the textures mapped to the model.  Simply expand out each element to reveal the texture mappings.  For each Material, locate and select the equivelant Material in the Content Browser, and click the green arrow next to the Material to "Use selected object in Content Browser."  This will overwrite the missing texture mapping with your imported tga texture.  Rinse and repeat until all Materials for the model have a tga association.

That was about as far as I decided to take this project in UDK.  Ultimately, the texture/mesh quality is just too low to be useful for anything other than extremely rough blocking out of a city.  To that end, it was a fun project.  🙂

Update: See my last post on this subject here to simplify a majority of the steps above.

In a recent post, I touched on a workflow to export models from Google Earth into UDK.  However, what if you wanted to repeat this process for an entire city?  Manually exporting every building one at a time would be extremely tedious and a complete waste of time since the models in Google Earth are low-res and would have to be re-created (again) at some point anyways, one at a time, for the final UDK product.  No thank you.  In such a scenario what we really need is an entire 3D city exported from Google Earth to serve as a TEMPLATE.  And then later we can then replace each and every building with a high-res model for our final UDK product.  Sound good?  Then let's get started.

For starters, I came across an article that details this exact scenario.  However, being nearly 4 years old (as of 2013) the article is quite dated, has dead links, and is otherwise missing some very critical pointers.  What follows is an updated overview of the same process from that article, with additional notes and steps to follow.

Prerequisites:

I wrote the following some time ago, and no longer can assist with troubleshooting.  The fact is, this technique/software was already 5+ years old when I came across it, and as time goes by, it only becomes older and more unsupported.  I will not be answering any further comments on this thread, as I cannot help and have myself moved on to 3D Ripper DX.  That being said, if you still wish to proceed, take it slow, read everything, and good luck!!!

Prerequisites:

• GoogleEarth: v5.0 [download] [mirror].
• GLIntercept: v0.5 [download] [vendor].
• OGLE: v0.3 beta [download] [ mirror] [vendor offline].
• 3D modeling software to import OBJ files, such as: Maya, 3DStudioMax, Rhino, Blender, etc.

Setup Instructions:

1. Install Google Earth.  The installer will install GE into Program Files (x86) by default (on modern Windows 7/8 systems).  To mitigate known issues running programs from the x86 directory, after the install I then copied the Google Earth folder to the root of my C drive.  Henceforth, I ran Google Earth from the C:\ root folder only.

    

   Copy Folder: C:\Program Files (x86)\Google\Google Earth
   To: C:\Google Earth
2. Install GLIntercept.  Likewise, the installer will install this into Program Files (x86) by default (on modern Windows 7/8 systems). Again, to mitigate known issues running programs from the x86 directory, after the install I then copied the GLIntercept folder to my Program Files folder.

    

   Copy Folder: C:\Program Files (x86)\GLIntercept0_5
   To: C:\Program Files\GLIntercept0_5
3. Extract OGLE plugin into the GLIntercept0_5\Plugins folder and rename the OGLE folder from "ogle-0.3b" to "OGLE".  Your OGLE plugin files should reside in the following folder:

    

   C:\Program Files\GLIntercept0_5\Plugins\OGLE
4. Copy "OpenGL32.dll" from "C:\Program Files\GLIntercept0_5" into "C:\Google Earth".
5. Make a copy of the "opengl32.dll" located in your "C:\Windows\SysWOW64" folder and rename it to "opengl32.orig.dll".
6. Cut "opengl32.orig.dll" from your "C:\Windows\SysWOW64" folder and Paste it into "C:\Google Earth".  You should now have both "OpenGL32.dll" and "opengl32.orig.dll" in your "C:\Google Earth" folder.
7. Download this zip and extract the "gliConfig.ini" file into "C:\Google Earth".
8. Open Google Earth (from "C:\Google Earth") and go to Tools > Options and set the Graphics Mode to OpenGL.  All other settings are up to you.  I left mine at default.  Apply changes and close Google Earth.
9. If you haven't done so already, install your 3D modeling software now.  Most all 3D applications come with a trial that you can utilize for testing purposes.

Capture GoogleEarth Geometry:

1. Open Google Earth (from "C:\Google Earth"), and navigate to whatever zip code/city you wish to capture.  Keep that folder open so you can see any new files created in it from the following steps.
2. Setup your camera angle/view so all the buildings you want are in view.  However, before it finishes rendering all the buildings, start your capture.
3. Press CTRL+SHIFT+F at the same time to capture.  GoogleEarth may freeze up for a few seconds, depending on how many buildings are being rendered, so be patient as it extracts the geometry.

    

   Note: you may need to Middle Mouse Button click inside Google Earth to ensure it is the active window.  Most important though is to ensure Google Earth is still rendering buildings before you start the capture, otherwise GLntercept may not work and you will have to close Google Earth and start over, or try changing your Camera Angle to for Google Earth to render more geometry.

4. After the capture has started and Google Earth unfreezes, you will now see an "ogle.obj" file in your Google Earth folder, "C:\Google Earth".  Some additonal log files and folders will be created as well, but they are not needed at this point.  Depending on how many buildings you captured, you should expect the "ogle.obj" file to be 10-100MB or more.

Import OBJ Into 3D Application

I will be using Maya to explain the remaining steps, as it is my preferred 3D modeling application.  The steps will be similar for other applications however.

• Open Maya and go to File > Import.  Navigate to "C:\Google Earth" and select your ogle.obj file and press OK to import.
• After navigating your camera around a bit, you may be dismayed to only see what looks like the border/menus of Google Earth, and no buildings!

• Rest assured your building models are there.  They are just EXTREMELY tiny!
• Zoom into the Origin of your scene and drag select around until you select what appears to be nothing.  You will know you have your buildings selected when your Heads Up Display jumps from 0 to several hundred thousand Verts.  To enable the Heads Up display, go to: Display > Heads Up Display > Poly Count.  You will also see a tiny white blip indicating your selection.
• Select your Scale Tool, and drag the center yellow box (origin) to the right.  You will see your buildings pop into existence!

• From here on out, its a simple matter of scaling, rotating, and modifying your model to your specifications, like so:

That should be it.  You now have a workflow to export entire cities from Google Earth into your Modeling application of choice.

I neither support nor condone the use of copyrighted models/assets from Google Earth in personal projects without the the express written consent from the original model authors.  My own goal is to utilize an exported Google Earth model purely as reference, to be replaced by my own work.

Final Notes

With regards to mapping Google Earth textures to the buildings in our obj file: You should notice the "CaptureTextureCoords " option in the OGLE settings in the gliConfig.ini file – that should get you the texture coordinates – but linking with the textures I believe has to be done manually. (I did not write OGLE so I don't know for sure – there is nothing in theory preventing it for working, I just thought it was un-implemented). 

The OGLE Plugin for GLIntercept will work on any 32bit application that uses OpenGL.  And while OpenGL is becoming less and less common these days, if you do a bit of digging around, you can still find games and applications that still do.  For instance, anything written using the idTech3 engine uses OpenGL.  By simply copying the gliConfig.ini, OpenGL32.dll, and opengl32.orig.dll files into my Return to Castle Wolfenstein folder, I was able to capture character models with ease.  Pretty cool, right?

WARNING: You will only want to test this on a local game server.  If you join a public game server with these files in your game directory, you may be kicked/banned/etc for trying to run a game exploit of some kind.  This happened to me in RTCW. You have been warned!

Credits

The following resources will guide the UDK/Maya novice in creating a simple model in Maya (with textures) and successfully importing it into a simple UDK map.

UDK/Maya: How to Set Up Your Grid in Maya to Match UDK

UDK: How to Add Player Starts, PathNodes, Weapons, Items, Vehicles and JumpPads

Maya Beginner Basics: Snap Tool and Pivots

Applying Custom Textures to a model in Maya

Maya 2012: Create static meshes for UDK