Alphaville City Simulator & Griffinville

Griffinville Development: Roadblocks and Solutions in a Timeline

All of this work was done concurrently as I developed Alphaville.

• August 2016) The initial meshes used for the buildings were from a CAD file (3D blueprints) made for the facility's physical construction.
  • This data was provided by the Michigan National Guard.
  • Problem 1: Unfortunately the CAD's file type was a read-only format.
  • Solution 1: I converted the mesh data into an editable FBX file format, and exported the data building-by-building.
  
  
  • Problem 2: Unfortunately the exporting process removed any type of linking of data between any of the 5000 meshes!
  • This created months of extra work ahead of me, as every single one of the meshes now had unique shaders, no UV-maps, no shared mesh (geometry) data.
  • Only the mesh data, object hierarchy, and naming data still existed, but even these were cluttered with tens of thousands of empty, or blank, parenting objects that cluttered the scene and had no function!
  
  
  • Solution 2A: I imported the FBX files into Blender, where I salvaged most of the useful data that I could (the meshes (all correctly sized because they were the blueprints!), object names and their hierarchy). This was done by creating a Python script to automatically clean up the imported FBX data. This largely involved identifying and removing tens of thousands of unneeded objects from the scenes which contained no useful data and clogged up Blender's interface.
  
  
  • Solution 2B: Also, as each of the mesh's shaders only differed in the diffuse (solid primary color) used, I made the script to group all of the shaders by those colors and then set them to share single instances of those shared shaders. This eliminated the number of shaders in the collective scene from about 5000 to around 20.


• September 2016) I took a two-day trip to Fort Grayling to tour the facility.
  • While there I ended up crawling through the 1m tall underground tunnel network connecting some of the buildings with a laser tape measure.
    • Later I modeled these tunnels, as their geometry wasn't included in the CAD data.
    
    
  • Also I took around 1,000 reference photos.
    • The photos were used to ensure accurately scaled textures for all of the objects within the scene.
    • Some of these reference photos were turned into textures for the buildings. Afterwards I then spend about a week making an initial set of textures, many of which would be tweaked and polished in the next step.


• February through September 2017) Within Blender massive amounts of texturing/duplicate meshes detection/realignment work needed to be done.
  • To speed up this workflow I continued making a tool-set/plugin with Python in Blender to speed up or eliminate many of the choke points which were holding me back.
  
  
  • There were over 5000+ individual source meshes which made up the combined scene, split between 26 buildings and the outside environment.
    • Problem: To eliminate massive amounts of repeated work, each mesh needed to be compared to the other 4999 meshes to find repeats. Then all of those repeated meshes needed to be rotated and linked to their duplicates so that work done on one mesh would affect the others.
    • This was no small task, as there were over 4000 duplicate meshes, with random rotations being applied to most of them. Additionally none of the meshes shared mesh data. Just matching rotations could take a couple minutes per mesh.
    
    
    • Solution: I made my add-on for Blender that handled the sorting and categorizing of all these meshes.
    • It could categorized meshes by their physical size, vertex count, or surface area (plus a few other attributes of the meshes).
    
    
    • Using these matched sets, it could automatically match the roatations all of the duplicate meshes in a set to use just a single instance of that mesh (eliminating much of the duplicate mesh data problem).
      • This worked perfectly for true duplicates of the meshes (when all of their mesh data was truly identical).
      • Unfortunately in my case this step ended up being temperamental because all of the input geometry had been triangulated when imported from the FBX file. The triangulation method used often caused the duplicate meshes to be triangulated differently depending on their initial orientation within the scene.
      
      
    • This plug-in also kept track of which matched mesh sets were done.
    • Additionally it put all of the matched mesh sets into a single list. This allowed me to instantly navigate between the matched mesh sets without having to identify hundreds of repeated meshes, or deal with manually checking/selecting which meshes were done in the scene hierarchy.
    • I could also set the plug-in to navigate to only matched mesh sets which weren't marked done.
    • This additionally saved months of scene-management work, and reinforced quality by not allowing any meshes to be accidentally missed.
    
    
    • Although this took me a couple months I hadn't planned for, ultimately the script saving me probably seven months of tediously repetitive work that I felt like I would burn out doing.
    
    
  • At the start of this project I was planning on perform these steps for each of the above 5000 meshes (all manually and one-at-a-time). After I developed my solution to the problem above, that count was down to 1000 matched mesh sets.
  1. For each mesh set I had to select (as well as creating or sourcing) one of 60 PBR textures made for this project.
  • This required remaking, tweaking, or finding replacements for many of the initial textures made the previous year.
  
  
  2. Each mesh set had to be U-V unwrapped.
  • This is the process of cutting seams on the meshes: such that all of the geometry is laid flat (and non-overlapping). It's similar to what clothes look like when cut and laid out, but before they're sewed.
  
  
  • Problem: Although performing an automatic U-V unwrapping within Blender worked for 95% of the meshes with minimal manual decision making, each mesh still needed to be manually checked for quality control, and usually required small amounts of input. Even for these quick meshes it was still taking a couple minutes of performing the same clicks to get each one done.
  • Solution: I carefully wrote down the 20 or so repeated steps which I was performing before I had to put in any mental input. I combined those steps into a single operation which was performed by clicking a single button. This alone saved me about a week of clicking the same 20 steps in a row, making 95% of the meshes take less than 15-20 seconds to process.
  
  
  • Also the UV maps of the mesh's 3D geomentry had to be scaled to accurately reflect its real-world size on a given texture.
  • Problem: Manually scaling the UV maps was a very slow process, prone to much guessing and checking, and could easily take 2-4 minutes per mesh to get an approximate fit. This was a problem because the fit of the texture had to be exact and consistent between all meshs which shared a texture.
  • Luckily because all of my input meshes had their correct real-world scale, I could leverage that fact to save me a lot of time.
  • Solution: I made a tool which allowed me to select a single UV edge and added a field to the UI where I could enter a scale for how large the texture should be. By clicking one button it would automatically center the texture to have its side aligned on that edge, place the UV map correctly, and then scale the UV map to be the exact size it needed to be. This eliminated all of the guesswork, while only taking a couple seconds per mesh, and it removed at least several weeks of work.
  
  
  3. Even with all of these efficiency improvements, it still took about 3 months of work to process the remaining 1000 matched mesh sets.
  
  
• October 2017 through May 2018) I finally moved the project to Unity Game Engine.
  • I coded and developed the multiplayer VR/FPS interfaces used for navigating the level from several preexisting packages for VR interactions, and a traditional FPS multiplayer interface, along with the Game's GUI.
  • In Unity I developed the game world's networked:
    • intractable physics,
    • weather,
    • full virtual reality body immersion for Oculus and FPS interfaces,
    • and external hackable targets.
  • I additionally developed several editor tools to speed up this process within Unity, which I won't describe here.
  • My work on Griffinville was finished May 2018.

Development Experience With Unity Packages

I used these Unity packages extensively through 27 months of professional game development making Alphaville and Griffinville. I've used and tried out many others as well.

• Cinemachine - Unity's best camera control system.
• Photon Network - For multiplayer gameplay.
• Game Interface Development in FPS (First Person Shooter) and VR (Oculus)
  • I combined with the following assets with Photon to add on multiplayer virtual reality support.
  • UFPS - Standard First Person Shooter Interface
  • NewtonVR - Basic interaction system with interactable objects with Oculus
  • Final IK - For adding player's bodies within VR and animating them
  • Morph3D -- Character Skin and Morphing System with Clothing

  Players move with head-tracking or gamepad.

• Unity Terrain Generation / Map Management
  • Gaia - For terrain generation and foliage placing
  • World Creator - For stylized terrain generation
  • EasyRoads3D Pro - For creating road networks and leveling terrain to match road's surface
  • Enviro - For weather within Unity