slide 1 onesaf objective system (oos) overview marlo verdesca, eric root, jaeson munro...

OneSAF Objective System (OOS)Overview

Marlo Verdesca, Eric Root, Jaeson MunroMarlo Verdesca, Eric Root, Jaeson Munro

SAICSAIC

[email protected]@saic.com

11/28/200511/28/2005

Background

OneSAF consists of two separate program efforts:

OTB OneSAF Testbed Baseline (OTB) is • An interactive, high resolution, entity level simulation which represents combined arms tactical operations up to the battalion level• Currently supports over 200 user sites• Based on the ModSAF baseline• ModSAF officially retired as of April 2002

OneSAF Objective System (OOS) is• New development.• Composable, next generation CGF that can represent

from the entity to the brigade level.• New core architecture.• Need based on cost savings through replacement of

legacy simulations:– BBS - OTB - Janus - CCTT/AVCATT SAF

• Commonly referred to as “OneSAF”

What is One Semi-Automated Forces (OneSAF) Objective System (OOS)?

A composable, next generation CGF that can represent a full range of operations, systems, and control processes (TTP) from entity up to brigade level, with variable level of fidelity that supports multiple Army M&S domain (ACR, RDA, TEMO) applications.

Software only

Platform Independent

Field to:•RDECs / Battle Labs•National Guard Armories•Reserve Training Centers•All Active Duty Brigadesand Battalions

Constructive simulation capable of stimulating Virtual and Live simulations to complete the L-V-C triangle

AutomatedComposableExtensible

Interoperable

Target Hardware Platform

Target PC-based computing platform: The PC-based computing platform is envisioned as being one of the standard development and fielding platforms for the OneSAF Objective System. The hardware identified in this list is compatible with current OneSAF Testbed Baseline supported Linux PC based hardware, the WARSIM Windows workstation configuration, and the Army's Common Hardware Platform.

• CPU: 2.8 GHz Xeon / 533 Processor • Memory: 1 Gb DDR at 266MHz • Monitor: 21 inch (19.8 in Viewable Image Size) • Video Card: NVIDIA Quatro 4 700XGL / 64 Mb RAM • Hard Drives: Two, 80GB Ultra ATA 100 7200 RPM • Floppy Disk Drive: 3.5 inch floppy drive • NIC: 10/100/1000 Fast Ethernet PCI Card • Network connection: Minimum of 10BaseT Ethernet • CD-RW: 40x/10x/40x CD-RW

Target Hardware Platform

Target PC-based computing platform: The PC-based computing platform is envisioned as being one of the standard development and fielding platforms for the OneSAF Objective System. The hardware identified in this list is compatible with current OneSAF Testbed Baseline supported Linux PC based hardware, the WARSIM Windows workstation configuration, and the Army's Common Hardware Platform.

• CPU: 2.8 GHz Xeon / 533 Processor • Memory: 1 Gb DDR at 266MHz • Monitor: 21 inch (19.8 in Viewable Image Size) • Video Card: NVIDIA Quatro 4 700XGL / 64 Mb RAM (GPU)• Hard Drives: Two, 80GB Ultra ATA 100 7200 RPM • Floppy Disk Drive: 3.5 inch floppy drive • NIC: 10/100/1000 Fast Ethernet PCI Card • Network connection: Minimum of 10BaseT Ethernet • CD-RW: 40x/10x/40x CD-RW

FY98 FY99 FY00 FY01 FY02 FY03 FY04 FY05

OOS ProgramMilestones

FY06

OneSAFTest BedBaseline

(OTB)

OneSAFObjective

System (OOS)

Build A

Build B

MS A *

ORD V1.0 ORD V1.1

OTB V1.0

STOC Award

BLOCK C

BLOCK D

FOC

V2.0

BLOCK A

OOS V1.0

P3I

OTB V2.0

MS B/C

BLOCK B

OneSAF Program Schedule

Line of Sight (LOS) Service in OneSAF

LOS Variants

1. Low-Resolution Sampling (Geometric)

2. High-Resolution Ray-Trace (Geometric)

3. Attenuated LOS• Atmospheric • Foliage

4. Ultra-High Resolution Buildings

Low Resolution Sampling & High Resolution Ray-TraceLow Resolution Sampling & High Resolution Ray-Trace

Sampled LOS as used in WARSIM

Ray-Trace LOS includes strict segment-polygon intersection tests

(picture Courtesy of WARSIM)

WARSIM reuse legacy gives us

the sampled LOS model for

use by OOS

OneSAF enhancements include exact ray-trace LOS

model

LOS AttenuationLOS Attenuation

Compute path loss through canopy – individual trees or

forest area

35% LOS

Compute path loss through atmosphere

10% LOS

Sensor Model accounts for attenuation path loss. Usually by a thresholding combined with a random draw of LOS result

LOS inside Ultra High Resolution Buildings (UHRBs)LOS inside Ultra High Resolution Buildings (UHRBs)

The UNIVERSITY of NORTH CAROLINA at CHAPEL HILL

Hybrid GPU/CPU Approach

GPU used to conservatively cull LOS queries

Create depth map (4k x 4k) from above using orthographic projectionTest line segments against depth buffer with reversed depth testLine segments with no pixels passing depth test have LOS

CPUExact tests using raycasting for non-culled queries (using double precision arithmetic)Culling eliminates most of the worst-case (non-intersecting) queries


GPU Culling

CPU1

ExactTest

CPU2

ExactTest

LOS Queries

Results

Render Terrain (once)The terrain is rendered into the depth buffer


A set of LOS queries is received

GPU Culling

CPU1

ExactTest

CPU2

ExactTest

LOS Queries

Results

Render Terrain (once)


The first batch of queries is culled using the GPU

GPU Culling

CPU1

ExactTest

CPU2

ExactTest

LOS Queries

Results


Batch 1


GPU Culling

CPU1

ExactTest

CPU2

ExactTest

LOS Queries

Results


The non-culled queries are tested using the CPU while the GPU processes batch 2

Batch 1culled

Batch 2

Batch 1 non-culled


Conservative GPU Culling

Render terrain only once for static scenesUse GPU memory for fast rendering of dynamic scenesConservativeness leads to “false positives” requiring more CPU tests

Increased resolution decreases false positivesResolution limited to 4k x 4k on current GPUsWe use multiple buffers to increase the effective resolution


Exact Test Details

Based on ray-castingRay traverses the spatial grid

Test triangles in each grid cell

ParallelizableWe use one thread for each CPU

terrain with uniform grid

LOS Integration into OneSAF

LOSIntegration Process

OneSAF/GPU Requirements

(SAIC/UNC)OneSAF/GPU Requirements

(SAIC/UNC)

OneSAF Technical Report

(SAIC)OneSAF Technical Report

(SAIC)

GPU Algorithm Creation

(UNC)GPU Algorithm Creation

(UNC)

Execute Unit Test

(SAIC/UNC)Execute Unit Test

(SAIC/UNC)

OneSAF Scenario Creation

(SAIC)OneSAF Scenario Creation

(SAIC)

OneSAF Benchmark Results

(SAIC)OneSAF Benchmark Results

(SAIC)

Integration into OOS

(SAIC)

• Add several OpenGL dll’s to ERC libraries

• Place c++ header files for OpenGL among the ERC code

• Create a new directory among the ERC code

- Setup a new makefile/buildfile, to allow GPU to build as its own library

• Add calls to ERC Initialization to:

- Gather all the triangles in the entire database

- Gather all features in the database

- Pass all triangles and features into the initialization for the GPU

• Replace all original LOS calls with the GPU counterpart

Integration into OOS

(SAIC)






- Gather all the triangles in the entire database


- Pass all triangles and features into the initialization for the GPU

• Replace all original LOS calls with the GPU counterpart

LOSPast Performance

November 2004

• Baseline:– OOS Build 23 Block C

• Database:– Joint Readiness Training

Center (JRTC); Ft. Polk LA.• Scenario:

– 200 total entities– 100 blue tanks vs. 100

red tanks • Performing LOS while

traveling and shooting

• 100x speedup in LOS query

• 3x simulation speedup

November 2004

• Baseline:– OOS Build 23 Block C



– 200 total entities– 100 blue tanks vs. 100

red tanks • Performing LOS while

traveling and shooting

• 100x speedup in LOS query


May 2005

• Baseline:– OOS Build 24 of Block D



– 3,000 total entities– 1,500 blue tanks vs. 1,500

red tanks• Performing LOS,

stationary, not shooting– 33 blue RWAs vs. 33 red

RWAs• Performing LOS while

traveling

• 100-200x speedup in LOS query

• 10x simulation Speedup

May 2005




– 3,000 total entities– 1,500 blue tanks vs. 1,500

red tanks• Performing LOS,

stationary, not shooting– 33 blue RWAs vs. 33 red

RWAs• Performing LOS while

traveling


• 10x simulation Speedup

August 2005


• Database:– Ft. Hood, Texas

• Scenario:– 5,000 total entities– ~2,500 blue tanks vs. 2,500

red tanks• Performing LOS, stationary, not

shooting

– 2 blue RWAs vs. 2 red RWAs• Performing LOS while traveling

• 100-200x speedup in LOS query • 15-20x simulation speedup

August 2005


• Database:– Ft. Hood, Texas

• Scenario:– 5,000 total entities– ~2,500 blue tanks vs. 2,500

red tanks• Performing LOS, stationary, not

shooting

– 2 blue RWAs vs. 2 red RWAs• Performing LOS while traveling

• 100-200x speedup in LOS query • 15-20x simulation speedup

LOSCurrent Performance

LOS Demonstration

Results

• Average time for Standard LOS service call:

1 – 2 millisecond

• Average time for GPU LOS service call:

12 microseconds


• Overall speedup:

20x simulation improvement

Route Planning in OneSAF

Types of Routes in OneSAF

• Direct Routes

– Follow the route waypoints exactly as entered by the user

• Networked Routes

– Follow a linear feature, such as rivers or roads

• Cross Country Routes

– Utilize a grid of routing cells that form an implicit network for the A* algorithm to search

Route Planning Algorithms in OneSAF

• Apply the A* algorithm to routing networks

• The cost function assigns a weight (cost) for a route segment

– Segment data includes the segment’s coordinates, slope, terrain type, and an indication of features

• The routing algorithm evaluates possible route segments based on their cost; a lower cost indicates a more favorable route.

• While evaluating a route segment, the cost function may call other ERC services, such as line of sight.

Cross Country Routing

Routing Cell

Each page in the runtime database is decomposed into routing cells. These routing cells form an implicit graph that can be searched using A*. Only segments requested by A* are computed at runtime.

River

a’ Lake

Segment a’ has a river and lake associatedwith it.

Segment b’ hasno features associated with it.

b’

Cross Country Routing

End point

Start point

Generated Route

Lake

RiverFeatures: lakes, rivers, trees, buildings, etc.


Motivation

In OneSAF, the route-planning bottleneck is feature analysis (intersection tests)

Accounts for over 50% of computation time

Feature analysis is the best (obvious) candidate as the starting point for performance improvement

The route-planning algorithm in OneSAF can use parallel feature-analysis computations


GPU-based Route Planning

Terrain Features& Route Segments

Feature Buffer(static)

Cull Segment SetAgainst Feature Set

(GPU)

Cull Feature SetAgainst Segment Set

(GPU)

Cull Feature SetAgainst Single Segment

(GPU)

Exact Feature/SegmentTests (CPU)

Results

Render Features(Once)

All Segments

All Features

All Features

Feature/Segment Pairs

ReducedSegments

ReducedFeatures


3 phases of GPU-based culling

GPU-based culling proceeds in 3 phases:Cull segments against the full feature setCull features against the reduced set of segmentsCull reduced feature set against individual segments

Route Planning Integration into OneSAF

Route Planning Integration Process



(SAIC/UNC)



(SAIC)



(UNC)

Execute Unit Test


(SAIC/UNC)



(SAIC)



(SAIC)

Integration into OOS (SAIC)







- Convert our feature class into UNC feature class

• Modify our A* algorithm to cost multiple segments at once

(batching process)

• Replace all original route planning calls with the GPU counterpart









• Modify our A* algorithm to cost multiple segments at once

(batching process)

• Replace all original route planning calls with the GPU counterpart

Route PlanningPast Performance

May 2005

• Baseline: – OOS Build 24 Block D

• Database: – Joint Readiness Training Center (JRTC); Ft.

Polk LA.– ~15K Features

• Scenario:– Four tank platoons

• Cross Country traveling• Route 25km – 27km • 40 total segments / route • Full physical models, behavior models, and

sensing models

• 10x speedup in feature analysis computations• 2x simulation speedup

May 2005


• Database: – Joint Readiness Training Center (JRTC); Ft.

Polk LA.– ~15K Features

• Scenario:– Four tank platoons

• Cross Country traveling• Route 25km – 27km • 40 total segments / route • Full physical models, behavior models, and

sensing models

• 10x speedup in feature analysis computations• 2x simulation speedup

Route PlanningCurrent Performance

August 2005


• Database: – Ft. Hood, Texas– ~50K Features

• Scenario:– One tank platoon– ~50 Individual Combatants (IC)

• Tactically Traveling through dense urban environment

• Route 5km – 8km • 11 total segments / route • Full physical models, behavior models, and

sensing models

• 30-50x speedup in feature analysis computation


August 2005


• Database: – Ft. Hood, Texas– ~50K Features

• Scenario:– One tank platoon– ~50 Individual Combatants (IC)

• Tactically Traveling through dense urban environment

• Route 5km – 8km • 11 total segments / route • Full physical models, behavior models, and

sensing models

• 30-50x speedup in feature analysis computation


Route Planning Demonstration

Route Planning Results• Average time for Standard Feature Intersection checking:

68,000 milliseconds

• Average time for GPU Feature Intersection checking: 2,200 milliseconds

• Average overall time for Standard Route Planning service call: 45 seconds

• Average overall time for GPU Route Planning service call:4.5 seconds

• Improvements: 30-50x speedup in feature intersection checking 10x overall simulation speedup

• Greater improvement if ….– Use of a complex urban terrain database– Increase entity count

Collision Detection in OneSAF

Basic Architecture

• Basic Architecture of Collision in OneSAF– Two types of collision

• Entity collides with entity• Entity collides with environment feature

• Collision detection is performed for each entity

• Medium and High resolution entities perform collision detection once per tick (15 Hz)

• Requires that the footprint of the entity be checked for intersections against features with linear, circular, and polygonal geometry.

• OneSAF Environment provides a service (get_features_in_area) to assist in detection of collisions with environmental objects

Current Status of Collision Detection

• OneSAF continues to finalize collision detection capabilities for version 1.0– OneSAF Build 24, Block D baseline contained minimal collision

detection capabilities

• SAIC/GPU team incorporate a basic collision detection algorithm into our GPU Build 24, Block D baseline:– Algorithm incorporated performs only the exact entity/feature tests

(similar to UNC) – Timing results that are collected are estimates to the true functionality

• Once collision detection is finalized and integrated into OneSAF:– Collision detection algorithm will be better defined– Provides more accurate timing results while comparing GPU-based

algorithms to non-GPU-based algorithms

47

Proximity & Collision Queries

Geometric reasoning of spatial relationships among objects (in a dynamic environment)

d

Closest Points & Separation Distance

d

Penetration Depth

Collision Detection Contact Points & Normals

48

Applications

Rapid Prototyping – tolerance verification

Dynamic Simulation – contact force calculation

Computer Animation – motion control

Motion Planning – distance computation

Virtual Environments -- interactive manipulation

Haptic Rendering -- restoring force computation

Simulation-Based Design – interference detection

Engineering Analysis – testing & validation

Medical Training – contact analysis and handling

Education – simulating physics & mechanics

49

Motivation

Collision and proximity queries can take a significant amount of time (up to 90%) in many applications:

dynamic simulation – automobile safety testing, cloth folding, engineering using prototyping, avatar interaction, etc.

path planning – routing, navigation in VE, strategic planning, etc.

51

Algorithm

Object-LevelPruning

Subobject-LevelPruning

Exact Tests

GPU-based PCS computation Using CPU

52

Real-Time Collision Detection for

Avatar Motion

53

Self-Collision Detection:

First interactive self-collision detection algorithm

1.5 orders of magnitude improvement in state of the art

Deformable Models

54

Real-time Surgical Simulation

Path planning for a deformable catheter

1 order of magnitude performance improvement

55

3 Stage Algorithm

Stage 1: Entities are removed that can be culled conservatively on the GPU Input 1

Entity 1

Entity 2Entity 3

Entity 4

Entity 5

Entity 4

Entity 5

56

3 Stage Algorithm

Stage 1: Entities are removed that can be culled conservatively on the GPU

Stage 2: Features are checked against entities and conservatively culled on the GPU

2

Entity 4

Entity 5

Input 1

Entity 1

Entity 2Entity 3

Entity 4

Entity 5

Entity 4

Entity 5

57

3

Entity 5

3 Stage Algorithm

Stage 1: Entities are removed that can be culled conservatively on the GPU

Stage 2: Features are checked against entities and conservatively culled on the GPU

Stage 3: Remaining features are checked per entity on the CPU

2

Entity 4

Entity 5

Input 1

Entity 1

Entity 2Entity 3

Entity 4

Entity 5

Entity 4

Entity 5

Entity 5 is the only colliding entity

58

3 Stages of Collision Detection

Each stage reduces the complexity of the next phase

If features are static, they are rasterized only once for all entity-based occlusion queries

Dynamic terrains can be easily supportedDynamic features are easily supported by the

algorithmRequires one extra rasterization of the feature

set

59

3 Stages of Collision Detection

Terrain Features are first rendered into a depth buffer at startup

At runtime Entities are checked

against feature depth buffer

Features are checked against entities

CPU performs final exact test

Feature Buffer(static)

Terrain Features& Entities

Render Features(Once)

Cull Entity Set Against

Feature Set(GPU)

Cull Feature Set Against

Single Entity(GPU)

Exact Entity/FeatureTests (CPU)

Results

Feature/Entity Pairs

Reduce Entities

Reduce Features per Entity

60

Occlusion Queries for Overlap Tests

Standard feature of current GPUs

When two objects are rendered/drawn, the queries check for overlap

We draw features and entities with occlusion queriesFind features and entities that overlapDrawing a feature or an entity takes only a few

microseconds

Collision Detection Integration into OneSAF

Collision DetectionIntegration Process



(SAIC/UNC)



(SAIC)



(UNC)

Execute Unit Test


(SAIC/UNC)



(SAIC)



(SAIC)







- Gather all features in a given area


• Replace all original collision detection calls with the GPU counterpart







- Gather all features in a given area


• Replace all original collision detection calls with the GPU counterpart

Setting the Stage

• OneSAF Configuration– OneSAF Plan View Display (PVD)

• GPU toggle switch (route calculation time)

– OneSAF SimCore

• OneSAF Terrain Database:– Ft. Hood, Texas– Future database – South West Asia (SWA)

• Scenario Overview:– Multiple tank platoons and IC’s performing LOS, route

planning and collision detection through a complex urban environment

– Full physical models, behavior models, and sensing models

Collision Detection Demonstration

Collision Detection Results

• Average time for Standard Collision Detection query: 20 milliseconds

• Average time for GPU Collision Detection query:2.1 milliseconds

• Improvements: 10x speedup in collision detection query5x simulation speedup

• Greater improvement if ….– Use of a complex urban terrain database– Increase entity count

2004

Collision Detection

Line of Sight(LOS)

Route Planning

BLOCK D

GPU Performance Improvement Schedule

2005

BLOCK D

BLOCK C BLOCK D

Nov.

DARPA Review

May

DARPA Review

Aug.

DARPA Tech TODAY

100x LOS query3x sim. speedup

100-200x LOS query10x sim. speedup

10x feature int.2x sim. speedup

30-50x feature int.10x sim. speedup

10x collision query5x sim. speedup

100-200x LOS query20x sim. speedup

slide 1 onesaf objective system (oos) overview marlo verdesca, eric root, jaeson munro...

Documents