Geoblender

Turn any real-world location into an editable Blender scene. GeoBlender autonomously builds, renders, evaluates, and refines 3D environments from map data.

Comment

Inspiration

A few days ago, I came across several experiments showing frontier AI models working inside Blender. I have always loved 3D, so I immediately wanted to test the idea on something real.

I started by asking an agent to model my own house.

The result was terrible: distorted proportions, gray materials, incorrect details, and the overall appearance of a plastic architectural model.

I could have stopped there. Instead, I became obsessed with understanding why it had failed.

The problem was not simply the prompt. The agent needed better geographic information, specialized Blender instructions, a way to inspect its own output, and a process for correcting mistakes.

That failed house became the starting point for GeoBlender.

What I built

GeoBlender is an agentic system that turns a place name, coordinates, or Google Maps link into an editable, block-based Blender scene.

Its agents and skills research real information about the requested location, including:

  • Building footprints and parts.
  • Heights and floor counts.
  • Geographic coordinates.
  • Roads, paths, water, and green areas.
  • Roof shapes and orientations.
  • Façade and roof colors.
  • Terrain elevation.
  • Landmarks and special infrastructure.

The system normalizes that information and uses Blender's native modeling tools to construct the scene.

It does not paste screenshots, satellite imagery, or Google Photorealistic 3D Tiles into Blender. Reference imagery can help evaluate the result, but the final deliverable is real, inspectable geometry.

One prompt: New York

Once the system was ready, I gave the agent a single prompt:

Build New York.

It returned an editable Manhattan scene without me moving a single vertex.

The city was not manually modeled between tool calls. The agent researched the location, retrieved the available geographic data, constructed the scene, created materials and lighting, positioned the cameras, rendered the result, and saved the final .blend.

That was the moment when GeoBlender stopped feeling like a Blender experiment and started feeling like a new way of interacting with physical space.

How it works

GeoBlender follows an explicit engineering loop:

place → research → normalized data → construction → render → evaluation → correction → repeat

The first scene is only a baseline.

The system renders the model from multiple camera positions and evaluates dimensions such as:

  • Geographic and semantic correctness.
  • Building geometry and scale.
  • Skyline and roof silhouettes.
  • Façade structure.
  • Colors and materials.
  • Camera framing.
  • Lighting and atmosphere.

Each iteration targets one category of problems. It records what changed, saves the corresponding render and .blend checkpoint, and measures whether the result improved.

A separate held-out camera prevents the agent from making one angle look impressive while leaving the rest of the scene structurally incorrect. If later iterations make the scene worse, GeoBlender restores the best checkpoint.

For the user, it still feels like one prompt. Internally, it is a controlled construction and evaluation process.

How I built it

GeoBlender uses Python, Blender, OpenStreetMap, Overpass, elevation data, procedural modeling, and specialized agent skills.

It runs on top of ahujasid/blender-mcp, created by Siddharth Ahuja. That open-source project provides the Blender addon, MCP server, connection, and native Blender tools.

GeoBlender adds the geographic data pipeline, construction system, agent instructions, safe Blender orchestration, checkpoints, evaluation policy, and correction loop.

After experimenting with different frontier models, GPT-5.6 Sol produced the strongest results for this kind of autonomous research, tool use, spatial reasoning, and Blender execution.

Challenges

Real-world geographic data is often incomplete. One building may have exact height, material, and roof information, while the building next to it may contain only a footprint.

GeoBlender tracks the source and confidence of its construction decisions. Explicit data takes priority, while missing values use bounded and deterministic fallbacks instead of arbitrary guesses.

Dense cities introduce another challenge: a single geographic request can become too large. The system caches responses and automatically divides overloaded areas into smaller queries.

Visual overfitting was equally important. Early versions could create a convincing hero render while hiding incorrect geometry. Held-out evaluation views, checkpoints, and rollback were introduced to make improvements more reliable.

Accomplishments

GeoBlender can now generate editable scenes for places such as Buenos Aires, Paris, and New York.

The current system supports:

  • Complex building parts and stepped massing.
  • Multiple procedural roof families.
  • Real terrain elevation.
  • Façade windows, entrances, cornices, and floor divisions.
  • Physical skies and atmospheric depth.
  • Deterministic rooftop equipment.
  • Source-aware colors and materials.
  • Stadium and grandstand interiors with stepped seating tiers.
  • Multi-view evaluation and automatic rollback.

The architectural detail still has a long way to go, but each iteration has produced a visible improvement over the previous one.

What surprised me

The most exciting part is not the final render. It is that the .blend remains alive.

Once a city exists as editable geometry, an agent can add a tower, move an avenue, replace a landmark, redesign a neighborhood, or combine elements from different cities through natural-language instructions.

Buenos Aires can exist on top of New York. The Obelisk can stand in Times Square.

I am not just modeling a city. I am turning reality into an editable draft.

What's next: football stadium ticketing

After I shared the project, someone I deeply admire in the community challenged me to explore football stadiums and ticketing.

That request is now shaping the next phase of GeoBlender.

The system already detects stadium and grandstand semantics and can construct concentric, stepped seating tiers. My next goal is to connect that geometry with ticketing information:

  • Sectors, bowls, rows, and seats.
  • Gates and circulation routes.
  • Accessibility information.
  • Capacities and pricing zones.
  • Approximate views of the pitch.
  • Restricted or partially obstructed views.

This could allow supporters to understand exactly what they are purchasing. Clubs and ticketing platforms could use the same spatial model for interactive seat previews, inventory validation, accessibility guidance, and venue operations.

The long-term vision is a living stadium model that connects the ticket shown on a screen with the real physical experience inside the venue.

Open-source goal

My goal is to continue developing GeoBlender in public so developers, Blender artists, geospatial researchers, football communities, clubs, and ticketing teams can inspect it, improve it, and build new applications on top of it.

GeoBlender is open source under the MIT License:

github.com/MartinPuli/geoblender

Built With

  • ai-agents
  • blender
  • blender-mcp
  • blender-python-api
  • digital-twins
  • eevee
  • geospatial-data
  • model-context-protocol
  • openai-codex
  • openstreetmap
  • opentopodata
  • overpass-api
  • procedural-modeling
  • python
  • srtm
Share this project:

Updates