Complex Terrain Databases for Urban Operations

1
Complex Terrain Databases for Urban Operations

• Dr. Stephen J. Adelson
• Leo Salemann
• Steve Farsai
• Dr. Dale D. Miller
• Timothy Miller
• Melissa E. Nakanishi
• Lockheed Martin Simulation, Training Support
• Advanced Simulation Center (ASC)
• Julio de la Cruz
• Army RDECOM/STTC
• 04S-SIW-007
  
  April 21, 2004

2
Urban Operations (UO)

• Urban Operations require
• Dense, realistic cityscapes
• Thousands, if not MILLIONS of buildings
• Reasonable database generation times

3
LM STS Jakarta
1.8 million buildings
4
Database Generation Time

• 1.8 million buildings (Jakarta)
• typical system can generate one building per
  minute
• _____
• 42 machine months generation time
• Excluding human-in-the-loop processing.
• NOT ACCEPTABLE

5
ABGS / UHRBSim Alternative

• Automated Building Generation System (ABGS)
• Attributed, textured simple building in under a
  second
• Automated process
• Implies 1.8 million buildings in 21 processing
  days
• Ultra-High Resolution Building Simulator
  (UHRBSim)
• Simulates damage to complex buildings in
  real-time operations
• Similar to DTSim for terrain

6
ABGS Process Overview
7
ABGS Step 1 Data Preparation (1)

• Building Footprints
• Two dimensional building outlines (shapefile)
• Urban Terrain Zones (UTZ)
• Large 2D polygons of similar building clustering,
  from source or automatic/manual derivation from
  imagery.
• Terrain Imagery (If UTZs are incomplete)
• Correlated 1-5m pixel images
• Road Networks
• Linear features correlated with building
  footprints, used to determine the front of
  buildings.

8
ABGS Step 1 Data Preparation (2)

• Footprint, UTZ, and Road attribution based on the
  Environmental Data Model (EDM) for Ultra-High
  Resolution Buildings (UHRB)
• UHRB-EDM is a simplification of the OneSAF
  Objective System (OOS) EDM
• Dropped Abstract and Generalized features in
  favor of a more explicit hierarchy.
• Reduced feature set to the core features
  necessary for a building with a basic interior.
• Attribution reduced to just those which support a
  visual representation.

9
ABGS Step 2 Attribution Generation (1)
10
ABGS Step 2 Attribution Generation (2)

• Root Segment Generation
• Use the building footprints and correlated roads
  to calculate front door

11
ABGS Step 2 Attribution Generation (3)

• Attribution Rules Configuration
• Driven by a database of allowable values and
  probabilistic value distribution
• Utilize UTZs to determine building type
• Analyze footprint for most likely building match
• Derive building function, building floor count,
  building heights, and number of floors

12
ABGS Step 2 Attribution Generation (4)

• Attribute Generation
• Assign attributes to buildings based on the
  attribution rules
• Largely automatic, manual intervention possible

13
ABGS Step 2 Attribution Generation (5)

• Verification Phase (optional)
• Edit buildings using common GIS tools
• Check for aesthetic distribution of building
  heights
• Check building type distribution
• Manually address special cases, e.g. landmarks

14
ABGS Step 2 Attribution Generation (6)

• InteriorGen
• Generates basic format of building interiors,
  with attribution
• Automated process, using ARC GIS tools / ESRI
  GeoDatabases

15
ABGS Step 2 Attribution Generation (7) Typical
InteriorGen Output
16
ABGS Step 2 Attribution Generation (8)

• InteriorGen Operational Steps
• Hallway line generation
• Shaft creation
• Hallway areas
• Room areas
• Door points and lines
• Shapefile export

17
ABGS Step 3 Floorplan Generation

• Generates abstract 3D building
• Includes walls, but no clipping or triangulation
• Attributes come from several sources
• Directly from the InteriorGen exported shapefile
• Default values from UHRB EDM
• Derived (e.g., number of rooms, window width)
• Fully automated process
• Output (xml files) used to build MESs in CTDB

18
ABGS Step 4 Polygon Generation (1)

• Takes a Floorplan (xml) and creates explicit
  polygons (x3d)
• Performs all clipping and texturing

19
ABGS Step 4 Polygon Generation (2)

• Fully automated process
• Output used for visual database, and real-time
  damage algorithms

20
ABGS Step 4 Polygon Generation (3)
21
UHRBSim Real-Time Modifications (1)
22
UHRBSim Real-Time Modifications (2)

• Similar to DTSim, reuses existing technology
• DTScribe for reliability
• Coverages / specific HLA interactions for
  readability
• Uses ABGS .xml and .x3d files as DTDB

23
UHRBSim Operation (1)

• UHRBSim Operations
• Listen for detonations
• Determine Affected Buildings
• Damage .xml files
• Use xml damage to cull x3d polygons for clipping
• Transmit damage information

24
UHRBSim Operation (2)

• Listen for Detonations
• Currently listens for c4 (UO focus)
• Could listen for any potentially damaging
  munition
• Determine Affected Buildings
• Gather buildings within the blast radius
• MSO database (derived from ABGS output) contains
  the location of .xml and .x3d file for each
  building

25
UHRBSim Operation (3)

• Damage .xml file (1)
• Damaging the more abstract .xml file allows
  better culling of real polygons.
• E.g., a single wall polygon corresponds to many
  .x3d polygons
• Only .xml action is to add apertures to existing
  structures

26
UHRBSim Operation (4)

• Damage .xml file (2)
• Generate blast outline
• Project to surfaces
• Creates ice cream scoop effect
• Effective for small munitions (c4)
• Gather damaged surfaces

27
UHRBSim Operation (5)

• Damage .x3d file
• Naming convention allows association between .xml
  surface and .x3d polygons, for efficient culling

• Clipping may not actually occur

28
Future Directions

• More complex buildings
• Level of Detail
• Non-building structures
• Incremental database generation
• More robust damage assessment, including rubble
• More variable attribution
• Optimized Storage