Canvas, scene and camera: what you actually plug in

It starts with a canvas

The engine takes a canvas element in its configuration and draws into it. That is the whole surface contract.

Nothing in the rendering package imports a UI framework. No Vue, no React, no Svelte, anywhere in the engine source. A Vue 3 binding ships because that is what we build with; wiring the same configuration object up from React, Svelte or plain JavaScript is ordinary work, not a compatibility problem.

The camera is yours to replace

The default controller lets a user pan, rotate, tilt and zoom from street level out to orbit, and it is a class you subclass. Swap it for a first-person walk, a drone overflight, a driving rig: same scene, different navigation paradigm.

The camera pose also lives in the URL, so a viewpoint is a link. Give it a place and a zoom and the map opens there.

Your objects render inside the world

Drop your own 3D objects into the scene and they are drawn alongside the world's geometry, lit by the same sun, occluded by the same buildings, shadowed by the same cascades. They are not an overlay floating above a map image.

Your palette, in one configuration step

The whole output can be re-toned to your brand through the grading stage, from a single configuration object.

Nothing is baked into a texture, so the palette holds at every distance rather than drifting back to a default when the camera pulls out. Further down, individual shader chunks are replaceable; the post-effect chain is composable and nothing in it is private.

Anchoring your own data to the world

The engine owns the camera and the projection, so it is the only thing that knows where a coordinate lands on screen this frame.

That mapping is handed back to you, frame-synced with the render loop. You supply points from your own database, a geocoder, an agent, anything that returns coordinates, and you get the screen positions where your tooltips, badges and dashboards belong. They follow the camera as the user moves.

What leaves the browser

Your data does not. What travels is the tile request: the camera needs a region of the world, and that region is fetched.

That is the boundary, and it is set out request by request in what CityMap3D sends, and what it does not. What a tile is made of, and why it is geometry rather than a picture, is covered in from an OpenStreetMap row to a shaded pixel.

The fastest way to judge it

The demo runs this exact engine, on the real planet, with no account to create. Open it, set a city you know, move the sun across it, and decide from what you see.