-
Website Screenshot
-
Flowchart Diagram
Inspiration
After a disaster, a responder might have a drone pass, several phone photos, and an address, but no shared model of the building in front of them. The team coordinating from elsewhere has to reconstruct the scene from disconnected images, map pins, notes, and radio updates. That makes it harder to communicate where damage is, which entrance is blocked, what area is flooding, or what should be checked next.
GroundTruth turns that starting evidence into a quick, editable, map-linked 3D scene. A person can attach photos to a real location, ground the model in an available OpenStreetMap footprint, correct it when needed, and share the same scene across the map, evidence review, scenario view, and export. Instead of asking everyone to hold the photo context in their head, the team has a common spatial reference for planning and discussion.
For disaster response, that scene can become a lightweight operational component. Field personnel or a drone operator could capture a building, document visible conditions, and give planners a starting point for routing, hazard review, physics or flood simulation, damage analytics, or comparison against later observations. GroundTruth does not make those safety decisions itself, but it creates an editable spatial record that other systems and people can reason about.
The same problem appears in games, film, and visualization. Many virtual locations are based on real buildings, yet artists still spend time rebuilding a usable starting model from reference photos. A few images and a location can provide a faster path to a footprint-aligned asset, then artists can refine the parts that matter for the final shot or game level.
That is where Scorched Nebraska fits. It is a post-disaster game setting where a recognizable real-world building needs to become a playable, damaged landmark. GroundTruth keeps the clean, map-aligned building as the base record and applies a separate generated Scorched Nebraska treatment with burned surfaces, damaged openings, debris, and overgrowth. The goal is not to claim that the damage is real. It is to give creators a structured, editable starting asset that still knows where it belongs in the world
What it does
GroundTruth lets a person:
- Upload normal photos of a building.
- Search for an address or place and place the scene on a map.
- Use the OpenStreetMap footprint when one is available.
- Correct the footprint manually when the map geometry needs adjustment.
- Review or edit traits such as floors, height, material, roof type, window rhythm, and entrance direction.
- See the building as both a GIS footprint and an interactive 3D model.
- Switch between Base, Scorched Nebraska, and Disaster Response views.
- Download GeoJSON, metadata JSON, and a GLB 3D asset.
The result is not presented as a survey or an autonomous safety decision. GroundTruth keeps evidence, assumptions, confidence, and generated scenario treatments visible so a person can review the result before using it.
How I built it
The app uses one shared scene record for the map, the 3D view, the evidence panel, and the exports.
First, the workflow resolves the place. Curated examples make the demo reliable, while address lookup and OpenStreetMap geometry support new locations when available. If no building polygon can be found, the person can use an editable rectangle and correct its position, size, and orientation.
Next, GroundTruth creates a local meter-based scene plan from the authoritative footprint. That plan computes the building outline, facade directions, windows, entrance, roof, and other visible details. The same plan drives the interactive Three.js view and the exported GLB, so the model and export share the same geometry.
The Base scene is the clean building representation. Scorched Nebraska applies a deterministic generated treatment with darkened materials, boarded and broken windows, roof damage, debris, and overgrowth. Disaster Response uses separate simulated layers for fire, flood, wind, and structural conditions, along with access status, hazards, and responder notes.
An optional local vision adapter can suggest visible facade traits such as color, floors, roof type, and window columns. Suggestions are shown as a proposal and are never applied without review. The core workflow remains usable with conservative editable defaults when that adapter is unavailable.
Architecture in plain language
The flow is:
Photos and address -> evidence and map review -> shared building record -> procedural 3D scene -> scenario view -> GeoJSON, metadata, and GLB
The most important design decision was keeping the footprint and the scenario separate. The map footprint represents the building location and shape. Scorched and Disaster settings add generated or entered context without rewriting the underlying building facts.
Challenges I ran into
The hardest problem was keeping every representation aligned. The map uses latitude and longitude, while the 3D scene needs a local meter coordinate system. Windows, entrances, roofs, scenario details, and GLB exports all had to use the same footprint orientation.
I also had to be careful about the limits of a single front-facing photo. It can provide useful clues about color, materials, windows, and the visible facade, but it cannot prove the shape of the entire building. That is why OSM geometry, manual correction, evidence labels, and confidence information are first-class parts of the product.
Finally, I wanted the scenario modes to communicate different ideas. Scorched Nebraska needed to look like a generated game-world transformation. Disaster Response needed to show operational conditions without pretending that procedural damage was observed fact.
Accomplishments I am proud of
- Built a complete field-to-scene workflow instead of a disconnected demo screen.
- Kept a real building footprint connected to an interactive map and 3D model.
- Added manual footprint correction for cases where automated geometry is incomplete or needs review.
- Created three distinct scene modes from one shared building record.
- Added standards-based GeoJSON and metadata exports plus a self-contained GLB export.
- Preserved evidence sources, assumptions, confidence, and scenario claim types in the workflow.
- Built the app so curated demos remain usable even when external map, geocoding, or optional vision services are unavailable.
What I learned
I learned that geospatial 3D work depends on coordinate discipline. A model can look convincing in isolation and still be wrong if its footprint, facade direction, and map placement use different assumptions.
I also learned that uncertainty should be part of the interface, not a footnote. A useful tool can combine authoritative map geometry, photo-based clues, procedural generation, and human corrections as long as it makes those roles clear.
The biggest product lesson was that a narrow, reliable workflow is more valuable than an impressive but opaque reconstruction claim. The person using the tool needs to understand what can be trusted, what can be edited, and what was generated for a scenario.
What's next for GroundTruth
The next step is improving the quality of the assets and the way scenes are rendered. I would like GroundTruth to offer richer reusable building assets, better materials, more convincing lighting, and stronger representation of architectural details so the result feels less like a basic extrusion and more like the actual place.
The current system is strongest at the building footprint and broad visible traits. A much stronger vision model could identify smaller details such as pillars, columns, awnings, balconies, trim, doors, roof edges, repeating window patterns, and material changes. It could also help create textures and building features on the fly from the available photos, while still presenting them as reviewed suggestions rather than guaranteed facts.
Shapes and pillars are an important limitation I want to explore. Much of the current geometry comes from extruding the map footprint, which captures the ground shape but does not fully describe facade depth, columns, recessed entrances, roof structures, or other features that sit above the footprint. A future scene plan could combine the OSM ground geometry with photo-derived facade components and adjustable architectural assets.
I would also like to explore a hybrid pipeline that combines procedural geometry with Gaussian splatting or another image-based representation. Procedural geometry would remain useful for a clean, map-aligned, editable building, while a carefully sourced visual layer could add detail where photos support it. That approach would require more imagery, better capture guidance, efficient rendering, and careful attention to licensing and source boundaries.
For the game workflow, I would add richer reusable building modules and stronger Scorched Nebraska asset tagging. For disaster response, I would add field-team collaboration, timestamped observations, richer damage evidence, and integration with operational GIS systems.
Log in or sign up for Devpost to join the conversation.