Data-Driven Wildfire Spread Modeling Using Earth Observation Data
with Interactive 3D Visualization in Unity

Phase 1 — Data Acquisition

All fire detection data originates from the NASA Fire Information for Resource Management System (FIRMS), a publicly accessible service that distributes near-real-time and archived fire detections produced by the VIIRS (Visible Infrared Imaging Radiometer Suite) and MODIS (Moderate Resolution Imaging Spectroradiometer) sensors aboard multiple satellites. Each detection record includes geographic coordinates (WGS84 latitude/longitude), acquisition date and time, brightness temperature, Fire Radiative Power (FRP), and a confidence classification.

FIRMS Area API Integration

The platform queries the FIRMS Area endpoint directly from within the Unity Editor. Because the API restricts each request to a maximum of 5 days, large date ranges are automatically chunked into sequential 5-day windows; results are merged and deduplicated by geographic coordinate and acquisition date before export. This prevents undercounting from single-window queries on long study periods.

Supported Fire Collections

• VIIRS SNPP NRT — 375 m resolution, near-real-time; primary collection used in all study areas.
• VIIRS NOAA-20 NRT — Complementary VIIRS sensor providing additional overpasses.
• MODIS NRT — 1 km resolution; used for cross-validation on older archived events.
• VIIRS SNPP SP — Standard product (non-NRT) for historical analysis.

Confidence Filtering

VIIRS encodes confidence as categorical classes (low, nominal, high). The pipeline normalises these to numeric scores (low = 30, nominal = 70, high = 95) and applies a configurable minimum threshold (default 80) during scene load. If filtering would produce an empty dataset for a given load, the system automatically falls back to the full unfiltered set and logs a warning, preventing broken visualisations from over-strict thresholds.

Boundary Definition Modes

• Preset regions — Paraguay (Gran Chaco), Portugal, Eastern Australia, and Hawaii are registered as named bounding boxes selectable from the Editor pipeline tool.
• Custom bounding box — User enters west/south/east/north decimal degree values manually. The manager normalises coordinate ordering and validates the API constraints.
• Shapefile boundary — An arbitrary polygon shapefile is accepted as the study boundary; the pipeline computes the bounding box of the shapefile geometry to query FIRMS.

Phase 2 — Data Processing and Unity Integration

After acquisition, fire detection records are processed through several stages before being visualised in the 3D scene. All processing runs in managed C# code within the Unity runtime, using only the Unity scripting API and the Cesium for Unity package.

Shapefile Export

Each pipeline run exports three geospatial files: a fire points shapefile (.shp/.dbf/.shx), a boundary polygon shapefile, and a WGS84 projection file (.prj). A timestamped CSV report is also written. The export base name follows the convention wildfire_<startdate>_<enddate>. These files are compatible with standard GIS desktop software (QGIS, ArcGIS) for independent post-processing.

Coordinate Transformation (WGS84 to Unity World Space)

The central technical challenge of this thesis is converting WGS84 geographic coordinates into Unity Cartesian world positions without introducing floating-point precision errors at global scale. This is resolved using Cesium for Unity’s Earth-Centred Earth-Fixed (ECEF) pipeline:

1. Each fire’s latitude and longitude are converted to ECEF coordinates using the WGS84 ellipsoid.
2. CesiumGeoreference.TransformEarthCenteredEarthFixedPositionToUnity() maps the ECEF position into the current Unity local coordinate space.
3. The CesiumOriginShift component moves the coordinate origin to track the camera, preventing precision degradation when viewing areas far from the scene origin. Fire anchors store ECEF coordinates and recompute their Unity positions whenever the origin shifts.
4. A terrain-readiness gate waits for Cesium mesh tiles to stream before spawning fire objects, using an exponential back-off retry (up to 15 attempts, 0.5–2 s apart) to verify that terrain raycasts at fire locations return valid hits.

Fire Clustering and LOD

Large datasets (tens of thousands of detections) are clustered in two stages before visualisation. First, fires within a configurable radius are merged into a single scaled marker; the marker scale is proportional to the square root of the cluster member count. Second, a tiny-fire merge stage aggregates low-intensity fires below an FRP threshold into a larger representative marker, reducing particle instance count without losing overall fire extent information. Distance-based LOD disables particle effects and smoke for fires beyond a configurable camera distance.

Burn Scar Projection

Accumulated burn areas are computed from fire detection clusters. Each scar is projected onto the Cesium terrain surface using downward terrain raycasts, with full vertex-level conformance for steep slopes. Nearby same-day scars are merged using geographic distance in metres to avoid overlapping objects. The default terrain attachment offset is 0.2 m to prevent z-fighting.

Phase 3 — Interactive Visualisation

The runtime environment provides a full interactive application built on Unity’s scene graph, with a main menu, in-game settings panel, and multiple real-time data overlays.

Timeline Animation

Fire detections are grouped by acquisition date and stored as an ordered list of timeline entries. Autoplay advances through dates at a configurable rate (seconds per day, adjustable from the in-game settings). Each day’s fires are spawned incrementally using a coroutine to avoid single-frame hitching on large datasets. Timeline startup uses an incremental build pass (BuildAndStoreDayEntriesIncremental) to further reduce first-frame latency after scene resets.

Weather Data Layers

Three weather overlay layers are registered on the orthographic minimap view and can be toggled independently at runtime:

• Temperature layer — Loads daily mean/max/min temperature records from Open-Meteo JSON. Markers are coloured on a blue-to-red gradient and scaled by temperature value. Optional location merging averages multiple records at the same coordinates to reduce visual clutter.
• Wind layer — Displays directional wind arrows on a spatial grid. Arrow orientation and length represent direction and speed respectively. Grid animation can run every N frames (configurable stride) to reduce CPU overhead.
• Cloud cover layer — Reads cloud cover mean and maximum values from Open-Meteo JSON. Flat disc markers are coloured on a clear-sky to overcast ramp using a transparent material.

Fly-Through Camera and Annotation System

The fly-through system supports scripted camera paths defined by waypoints stored as ECEF coordinates. Each path segment plays back at a configurable travel speed (default 3,000 m/s for continental distances). During playback all active CesiumOriginShift components are suspended to prevent coordinate drift. Annotations (text and optional image overlays) are attached to waypoint ranges; they appear as draggable cards during recording and replay at the same screen position during export. Paths and annotations are serialised to JSON for persistence between Unity sessions. Export quality controls include resolution presets, export FPS, GIF FPS, and GIF width.

Performance Architecture

A camera-look gate advances the fire simulation and timeline only when the viewport is aimed at active fire bounds, reducing unnecessary computation when the camera is facing away. Runtime performance presets (Quality / Performance) apply consistently across particle budgets, smoke LOD, wind grid stride, and render scale, and are persisted via Unity’s PlayerPrefs system so settings survive application restarts.

Tools and Technologies