Using Codex to Build a Smart Highway 3D Visualization Dashboard: From 18 Industry Design Drafts to an Interactive Operations Monitoring Center

Because Codex has been resetting so frequently recently, we took the opportunity to generate a large batch of visualization dashboard design drafts for the smart transportation domain in one go. The result was predictable: quite a few of the 18 generated drafts were repetitive.

Problems encountered

The cost of rapid batch generation is homogenization. The UI frameworks are similar, the layout logic is similar, and the way information is arranged keeps falling into the same few patterns. That clearly won't work.

So we started reflecting on how to genuinely consolidate a useful design system. Several directions are being pursued:

• Asset library and componentization: Accumulate icons, header containers, and various frame lines into a reusable component library. Fonts need to be chosen well, and visual hierarchy must be distinct.
• Chart library creation and polishing: Bar charts, donut charts, timelines... these basic chart templates need repeated proofreading to ensure consistent data display logic.
• Data asset accumulation: Each generation leaves behind some realistic data examples, and later drafts can reference these value ranges and distribution patterns.

Fortunately, Codex resets frequently enough that the cost of this rapid iteration is low. We can safely try different design directions, and through continuous correction and accumulation, gradually build a design system for this domain.

Back to the main topic

We first present 18 industry design drafts, three for each transportation domain, to show the design approaches. Then we select the smart highway solution with the most potential and actually develop it into an interactive frontend project.

Next, we break down the technical details one by one: how to construct 3D roads, how Shader draws flowing light, how vehicles move along curves, how points link the camera, and how day/night switching is implemented. Each part gives key code and implementation ideas, while marking which are design choices, which are technical implementations, and which need to be changed when connecting real data later.

This practice started with a round of design generation before a Codex reset. First, create dashboard design drafts for the transportation industry, then select one to continue with web development, 3D scene, and interaction. This article shows 18 design drafts for six industry types, and uses the final "Smart Highway Operations Monitoring Center" to explain the process from image to code.

The project uses React, TypeScript, and Three.js. The completed page supports vehicle flow, single-vehicle information viewing, node perspective switching, vehicle following, and day/night switching; the business panels use demo snapshots, and vehicles move along programmatically generated trajectories.

01 | Industry design drafts: six traffic scenarios, 18 solutions

The following 18 are design exploration images, three per category; the chart values are for layout illustration only, not industry statistics. Each group unfolds by operation overview, special coordination, or facility management. This round of designs covers highway, rail, road, water transport, civil aviation, and postal transport. Then from the highway direction we selected one design draft to develop an interactive frontend project.

01 / Smart Highway

Highway designs cover interchange operation, service areas, and bridge-tunnel support. Multi-layer road relationships suit 3D expression; traffic volume, speed, and event handling status still need tables or charts to give clear definitions.

Design exploration | Smart Highway Operations Center | with mountainous multi-layer interchange as visual center, paired with node flow and operation indicators, emphasizing road network spatial relationships.

Design exploration | Smart Highway Service Area Coordination | focusing on parking, charging, and service facilities, showing internal resource distribution within the service area, suitable for discussing peak support and service scheduling.

Design exploration | Smart Highway Bridge-tunnel Support | arranged along the corridor formed by bridges, tunnels, and slopes, centralizing support information for different facilities.

02 / Smart Railway

Railway designs target transport organization, station-city integration, and line maintenance. A 3D station yard can help understand spatial relationships, but running graphs, interlocking, and formal dispatch commands still belong to their respective business systems.

Design exploration | Smart Railway Transport Command | with high-speed rail hub as the core, showing transport relationships in different directions, exploring the overall composition of transport command scenes.


Design exploration | Smart Railway Station-City Coordination | using a station section to connect waiting, platform, arrival, and connection areas, highlighting passenger flow between spaces.

Design exploration | Smart Railway Line Maintenance | linking track, turnouts, power supply, and inspection objects, serving the design expression of line inspection and facility maintenance.

03 / Smart Road

Ordinary road designs separate mountainous trunk lines, urban-rural connections, and bridge maintenance. The first two focus on network and nodes; the latter focuses on structure and defect location, avoiding mixing network statistics with component indicators in the same view.

Design exploration | Smart Road Operation Overview | with mountainous national and provincial trunk lines as the main body, organizing traffic information by section, making network conditions easier to locate.

Design exploration | Smart Road Urban-Rural Coordination | connecting town main streets, county roads, and township roads, exploring display approaches for urban-rural road coordination and node passage.

Design exploration | Smart Road Maintenance Management | presenting maintenance objects through bridge sections and inspection information, giving facility status and maintenance tasks a clear spatial correspondence.

04 / Smart Water Transport

Water transport designs split by channel, port area, and ship lock. Channel conditions change with water level, ship locks need queue and lockage planning; 3D spatial display needs to combine with these time-series and scheduling data.

Design exploration | Smart Waterway Channel Operation | organizing channel and ship information in upper, middle, and lower reaches, highlighting the continuous relationship of waterway passage.

Design exploration | Smart Waterway Port-Navigation Coordination | placing berths, cargo ships, storage yards, and collection/distribution roads into one scene, exploring coordination between port operations and external transport.

Design exploration | Smart Waterway Ship Lock Scheduling | with a double-line lock at the core, presenting water level, lock chamber, and upstream/downstream waiting areas, suitable for discussing ship lockage scheduling.

05 / Smart Civil Aviation

Civil aviation designs organize airport operations, passenger flow, and cargo support separately. Airfield space, passenger nodes, and cargo operations are different objects; you cannot just swap models and reuse the same set of indicators.

Design exploration | Smart Aviation Operations Center | building an airport panorama with runways, taxiways, and aprons, arranging information around flights and ground operations.

Design exploration | Smart Aviation Passenger Service | organizing the frame along passenger processes such as check-in, security, and waiting, focusing on passenger flow and service pressure at each stage.

Design exploration | Smart Aviation Cargo Support | arranged around cargo aircraft loading/unloading, import/export, and transit operations, showing the spatial and process relationships of air cargo support.

06 / Smart Postal Transport

Postal transport designs cover delivery networks, sorting sites, and last-mile delivery. The network layer focuses on flow direction and backlog, the site layer focuses on equipment and movement lines, and the last-mile layer focuses on service coverage and fulfillment anomalies.

Design exploration | Smart Postal Dispatch | connecting regional transport networks through sorting hubs, presenting the overall relationship of delivery chains and vehicle dispatch.

Design exploration | Smart Postal Intelligent Sorting | showing sorting lines, conveying equipment, and chutes, focusing on processing status, anomaly locations, and equipment maintenance.

Design exploration | Smart Postal Last-Mile Delivery | connecting outlets, stations, smart lockers, and communities, exploring the organization of last-mile delivery coverage and service resources.

Checking the business model against design themes: where the six industries differ

A Ministry of Transport interpretation of digital transformation for road and waterway infrastructure lists digital maintenance, operation monitoring and early warning, emergency command and dispatch, and cross-department coordination as construction content. This lets us split dashboard design into three layers: where objects are, whether status is abnormal, and who handles the abnormality. Visualization covering only the first two layers does not mean business handling is complete.

Ministry of Transport, Comprehensive Planning Department | Interpretation of the Notice on Supporting and Guiding Digital Transformation and Upgrading of Road and Waterway Transport Infrastructure (2024-05-01) (https://www.mot.gov.cn/gongkai/zcjd/202512/t20251226_4191354.html)

The table below summarizes management tasks based on public material; data items and 2D/3D trade-offs are engineering analysis for this case, not a unified interface mandated by the authority. Railway running graphs, water transport lockage queues, civil aviation support timelines, and postal flow networks each have their own data structures and ways of being read.

Domain	Management objects and core questions	Data that needs organizing	Division of 3D and 2D
Highway	Main line, ramps, interchanges, service areas; judge impact direction and handling resources	Section flow, speed, events, weather, equipment, rescue resources	3D explains interchange levels and local scenes; 2D compares network-wide congestion, trends, and to-dos
Railway	Sections, stations, bridges/tunnels, track, power supply; risk correlation	Equipment alarms, inspection, maintenance, environmental risk, authorized operation information	3D locates facilities and scenes; 2D keeps line topology, running graphs, and risk ledgers
Ordinary road	National/provincial trunk lines, pavement, bridges, slopes; asset evaluation and maintenance scheduling	Defects, patrols, inspections, work orders, construction occupation, pass status	3D verifies components and terrain; 2D manages line distribution, work orders, and annual plans
Water transport	Channels, locks, bridge areas, port areas, ships; navigability and scheduling coordination	Water level, clearance, channel dimensions, ship dynamics, lockage times, waiting queues	3D expresses lock and port relationships; 2D shows electronic channel charts, queues, and water level curves
Civil aviation	Flights, gates, airfield, vehicles, support tasks; air-ground coordination	Flight status, resource occupancy, support milestones, overruns, weather	3D for airfield space understanding and replay; 2D for flight timelines, milestones, and anomaly lists
Postal transport	Sorting sites, trunk transport, outlets and last mile; backlog spread and site safety	Processing nodes, arrivals/departures, backlog, equipment status, safety hazards	3D locates in-site equipment and movement lines; 2D analyzes network flow direction, timeliness, and node backlog

Road materials clearly define management objects such as facility inspection, maintenance, and testing; railway materials emphasize risk grading and hazard management; waterway materials list channel monitoring objects and joint dispatch directions; civil aviation pilots involve air-ground joint situation and support coordination; postal cases cover sorting site patrol and hazard closure. These materials support business scope; they cannot directly prove that a particular dashboard already has the corresponding capability.

State Council (published by Ministry of Transport) | Road Safety Protection Regulations (2011-03-07) (https://xxgk.mot.gov.cn/jigou/fgs/202006/t20200623_3307992.html)

National Railway Administration | Notice on Printing and Distributing the Management Measures for Railway Safety Risk Grading Control and Hidden Danger Investigation and Management (2023-03-10) (https://www.nra.gov.cn/xxgk/gkml/ztjg/gfzd/gfxw/zuti/jgzf/202303/t20230320_340029.shtml)

Ministry of Transport, Waterway Bureau | Opinions on Accelerating the Construction of Smart Ports and Smart Waterways (2023-12-04) (https://xxgk.mot.gov.cn/jigou/syj/202312/t20231204_3961959.html)

Civil Aviation Administration of China | Notice on Piloting Full-Process Operation Scenarios for Smart Civil Aviation Construction at Chengdu Shuangliu Airport (2024-03-04) (https://www.caac.gov.cn/XXGK/XXGK/TZTG/202403/t20240308_223162.html)

Hebei Provincial Postal Administration, Xiong'an New Area Postal Administration | Xiong'an Bureau Strengthens Remote Monitoring and Inspection (2026-08-14) (https://he.spb.gov.cn/hbsyzglj/c20241030/202608/fe4e009c5b434bb5ba01de8c67f7d37b.shtml)

02 | Choosing Smart Highway: from one design draft to the development target

The development baseline chosen this time is the "Smart Highway Operations Monitoring Center." The view centers on a multi-layer interchange, surrounded by node flow, event handling, vehicle type composition, equipment online rate, and trend comparison. This solution includes spatial relationships, statistical information, and object operations, splitting the design-to-code process into clear implementation tasks.

Selected development design draft | Smart Highway Operations Monitoring Center. The central interchange, five points, and surrounding business panels form the baseline for layout and interaction.

Preview video:

The central multi-layer road needs reconstructed curves, bridge deck heights, and lane boundaries; moving vehicles need model assets, continuous pose, and queryable object identifiers; the five points need to link camera targets and screen labels; surrounding charts need unified statistical definitions. This forms a development thread: how roads are built, how vehicles move, and how clicking relates information and viewpoint.

Implementation scope: the current project is an interactive frontend demo. Business panels use fixed snapshots, vehicles use programmatically generated trajectories; roads are reconstructed from the selected design draft, without connecting surveying road network, real-time traffic data, or actual dispatch command systems. IDs like V0869, P001 in the text are demo objects.

Development result | Smart Highway Operations Monitoring Center day overview. The center is a programmatically generated 3D road network and vehicles; surrounding panels are snapshot-driven traffic, events, vehicle types, and equipment.

Mapping the selected view to highway operation management tasks

The Ministry of Transport's published Jiangsu "AI + Smart Road Network" case brings operators, traffic enforcement, and highway police into coordinated command, and aggregates weather, infrastructure, and emergency resource data. Corresponding to system design, detecting events, assessing impact, issuing commands, executing on site, and confirming recovery each require different states and permissions. An alarm point on a map does not mean the dispatch process is complete.

Ministry of Transport (case provided by Jiangsu Provincial Department of Transport) | Ministry of Transport releases 12 typical cases of pilot transport power construction | Case 2 "AI + Smart Road Network" protects highway safety and smooth operation (2026-08-26) (https://www.mot.gov.cn/xinwen/jiaotongyaowen/202608/t20260826_4223249.html)

Indicator	Definition that must be clear	Implementation in this project
Todays traffic	Vehicle trips or unique vehicles; statistical scope, section, dedup method	Node flow summed to 48,000 in snapshot; independent of scene vehicle count
Average speed	Road scope, time window, source, aggregation method	Reads fixed snapshot 88 km/h; not inferred from on-screen vehicles
Equipment online rate	Equipment list, heartbeat validity, maintenance downtime, no-data states	Fixed data total 990/1,000, giving 99.0%
Events in progress	Event dedup and state machine; start, end, recovery conditions	Filters 3 events by snapshot state; no real dispatch flow

The four indicators also have different time scales. Vehicle position is trajectory observation, section flow is window statistics, equipment online depends on heartbeats, and maintenance status may come from work orders. Production interfaces need to carry observation time, receive time, source, and quality flags simultaneously. Smooth browser animation only means rendering is continuous; it does not prove data is real-time.

03 | Using Codex to drive development: from design image to engineering boundary

Engineering splitting follows the path "business requirements, design baseline, asset split, scene implementation, interaction verification." Codex handles execution work like design generation, code writing, and checking; each step's usable result still needs to be proven by its corresponding artifact, such as layout config, model files, operable pages, and test records.

Step	Delivered artifact	Issues to verify
Industry and scenario breakdown	Objects, indicators, events, users, data boundaries	Do indicators answer real business questions; are different statistical scopes mixed
Choose design baseline	Full-screen selected draft and fixed canvas	Are title, sidebar, scene, trend area proportions fixed
Split visual assets	Background, title, borders, icons, point assets	Which container draws a border; how much usable chart area is inside
Build 3D scene	Road curves, pavement, vehicles, terrain, camera	Is space continuous; do road, markings, vehicles share the same lane baseline
Connect interaction	Point positioning, single-vehicle selection, follow, day/night, pause	Do selected object, info panel, and camera target match
Verify and deliver	Code tests, run screenshots, inspection records	Are functionality, visual consistency, and target-device performance accepted separately

The page uses a 1672 × 941 design canvas; the central scene reference area is x=395, y=178, width 881, height 462. The outermost layer scales uniformly by the smaller ratio of browser width/height, so titles, panels, and scene share the same scaling relationship. Title background, panel base, and content layers each have clear responsibilities, avoiding repeated nested frames.

Code 1 | Full-screen proportional scaling

const scale = Math.min(size.w / 1672, size.h / 941);
const stageStyle = {
  left: (size.w - 1672 * scale) / 2,
  top: (size.h - 941 * scale) / 2,
  transform: `scale(${scale})`,
};

This code extracts the style expression from the original implementation for explaining the scaling relationship. It keeps the full-screen ratio and does not automatically change to a mobile card layout; when the target screen aspect ratio differs, centered margins appear. Charts still need plot area, axes, legend, and value area allocation; you cannot just stuff a small chart into a large border.

The current flow bar chart, vehicle type donut chart, and trend chart are React/SVG with their own viewBox and data mapping; event and equipment areas use tables. Even though the dependency list includes ECharts, you cannot claim these business charts are ECharts implementations.

04 | Rendering architecture: separating business state from per-frame computation

Module	Responsibility
main.tsx / default-dashboard.json	Register business blocks, import layout, set full-screen scaling
state.tsx	Hold node, vehicle, follow, day/night, pause, and light-trail UI states
ExpresswayScene.tsx	Create/destroy scene, pass React state to Three.js runtime
sceneLayout.ts / createExpressway.ts	Rebuild coordinates from selected draft, road and environment geometry, render loop, resource release
traffic.ts / vehicleModel.ts	Load GLB and textures, compute vehicle pose, update instance matrices, handle picking
sceneEffects.ts / cameraRig.ts	Road and point effects, target camera, vehicle follow, label projection

React manages business selection and page state; Three.js updates camera, vehicles, and material uniforms in requestAnimationFrame. In normal operation, vehicle info is posted back to React roughly every 500 ms, avoiding writing all instance matrices into component state every frame. This frequency is a UI info refresh policy, not a backend data sampling frequency.

The render loop advances elapsed using a clamped dt, freezes elapsed when paused, and shares this animation clock for vehicles, road light trails, and water surface. Camera transitions and day/night switching still use dt for operation feedback. The loop stops when the page is hidden; on unmount it cancels animations, removes listeners, and releases geometry, materials, textures, and renderer.

05 | Road reconstruction: screen coordinates, curves, and lanes share one baseline

Inverse-projecting the selected draft, solving main-view composition alignment

The design image only provides 2D pixel positions. The project fixes a perspective camera, converts road control points from the selected draft into normalized device coordinates (NDC), casts rays, and intersects them with a horizontal plane at a specified height. Each control point has x, y, and a manually set height; these 3D points generate Catmull-Rom curves.

Code 2 | Getting scene control points from design-image pixels

const ray = new THREE.Raycaster();
ray.setFromCamera(new THREE.Vector2(
  (x - SCENE_RECT.x) / SCENE_RECT.width * 2 - 1,
  1 - (y - SCENE_RECT.y) / SCENE_RECT.height * 2
), camera);
const point = ray.ray.intersectPlane(
  new THREE.Plane(new THREE.Vector3(0, 1, 0), -height),
  new THREE.Vector3()
);
if (!point) throw new Error('Reference point is above the reconstruction plane');

This adds a depth constraint to the 2D pixel: the plane equation y − height = 0 determines the ray landing point. It makes the road trend in the overview close to the selected draft, but a single image is not enough to recover an unambiguous real geometry. Once the camera moves to a side view, you still need to check bridge deck height differences, intersection relationships, and connection continuity. When connecting a real road network, switch to road data with coordinates and elevation processing.

API reference | Three.js Raycaster: NDC and camera rays (https://threejs.org/docs/pages/Raycaster.html)

Pavement, markings, vehicles, and light trails share one cross-section

The road uses a ribbon mesh swept along the curve. Each sample point takes curve position p and tangent d, uses the horizontal side vector (−d.z, 0, d.x) to spread the road to left/right edges, then connects adjacent cross-sections into two triangles. UV.x corresponds to cross-track position, UV.y to normalized arc-length position along the line.

Code 3 | Generating pavement cross-section and UVs

for (let i = 0; i <= segments; i++) {
  const t = i / segments;
  const p = curve.getPointAt(t), d = curve.getTangentAt(t);
  const side = new THREE.Vector3(-d.z, 0, d.x).normalize();
  for (const k of [-1, 1]) {
    const q = p.clone().addScaledVector(
      side,
      offset + k * (typeof width === 'function' ? width(t) : width) / 2
    );
    verts.push(q.x, q.y + height, q.z);
    uv.push((k + 1) / 2, t);
  }
}

carriageway() uniformly defines the central divider, road edges, lane width, and lane centers. Vehicle offsets, road markings, and Shader sampling all use this baseline, reducing misalignment like vehicles crossing lines or light trails crossing guardrails. The current side vector is computed on the horizontal plane; it does not build a full road cross-section with superelevation. It suits the compositional reconstruction of this demo, not a road engineering design model.

06 | Road Shader: how narrow bright bands and short light packets form

The road effect has two layers: MeshStandardMaterial retains the asphalt surface and basic lighting; a separate ShaderMaterial draws flowing light above the road. Geometry heights are about 0.03 and 0.06 scene units above the road curve, reducing coplanar flicker. The light trail keeps depth test on, turns off depth write, and uses additive blending, so it does not replace the road's own material.

The fragment shader first converts the cross-track UV into a road-space position across, then computes a local lane coordinate x from the central divider and lane width. Along-line distance travel comes from UV.y × roadLength, and direction distinguishes the two directions of traffic. This organizes animation period by road length, rather than forcing all roads into the same flat animation.

Code 4 | Short light packet moving along the lane

float across = (vUv.x - .5) * width;
float lane = (abs(across) - median) / laneWidth;
float x = (fract(lane) - .5) * laneWidth;
float direction = across > 0.0 ? 1.0 : -1.0;
float laneIndex = floor(lane);
float seed = laneIndex * 23.71 + direction * 11.3;
float travel = vUv.y * length * direction;
float phase = mod(travel - time * speed + seed, 61.0 + laneIndex * 8.0);
float tail = smoothstep(0.0, 6.0, phase)
           * (1.0 - smoothstep(6.1, 7.8, phase));
float headDistance = (phase - 6.0) / .85;
float head = exp(-headDistance * headDistance);
float aa = max(fwidth(x), .035);
float core = 1.0 - smoothstep(.055, .055 + aa, abs(x));

phase controls the light packet cycling along the road; tail uses two smoothsteps to form a short trailing streak; head concentrates brightness with a Gaussian shape; core narrows energy to a thin line at the lane center. fwidth provides a transition width related to screen-pixel variation, reducing aliasing of thin lines at distance. The excerpt depends on varying, uniform, and final color output in the full shader.

Code 5 | Limiting glow range and keeping a continuous thin band

float halo = exp(-x * x / .18);
float mask = step(median, abs(across)) * (1.0 - step(edge, abs(across)));
float ribbonDistance = abs(abs(across) - (median + laneWidth * .72));
float ribbonCore = 1.0 - smoothstep(
  .045, .045 + max(fwidth(across), .04), ribbonDistance
);
float ribbonHalo = exp(-ribbonDistance * ribbonDistance / .16);
float wave = .35 + .65 * pow(.5 + .5 * sin(travel * .035 - time * .8), 3.0);
float packet = core * tail * .55 + halo * (tail * .25 + head * .45);
float ribbon = (ribbonCore * .72 + ribbonHalo * .24) * wave;
float alpha = (packet + ribbon) * mask * flowEnabled;

mask limits the effect to valid pavement; packet handles discrete short light packets; ribbon handles the continuous thin band near the fast lane on both sides; wave adjusts the brightness rhythm of the continuous band. Simply thickening a light band would hide markings, while coloring the whole road bright would weaken layering. So width, glow, and transparency need separate control.

The project also draws short tail streaks for some moving vehicles that follow the vehicle matrix. Road light packets and vehicle tail streaks are not the same mechanism: the former is decided by time, speed, and road UV, the latter follows a specific vehicle. The current road light trail is not adjusted by measured flow, congestion level, or individual vehicle speed; it cannot be interpreted as a real traffic flow simulation.

07 | Vehicle implementation: model appearance, motion trajectory, and identity association

Model assets: load by type, instantiate by part

Cars, trucks, and buses load from sedan.glb, truck.glb, and bus.glb respectively. Asset conversion includes size and forward-axis normalization, wheel axle separation, material adjustment, and texture processing. The car source is Comrade1280's Generic passenger car pack, licensed CC BY 4.0; trucks and buses come from Rgsdev's Free Low Poly Vehicles Pack, licensed CC0. The project keeps author, source, license, and modification notes.

Model source | Comrade1280: Generic passenger car pack (Sketchfab) (https://sketchfab.com/3d-models/generic-passenger-car-pack-20f9af9b8a404d5cb022ac6fe87f21f5)

Model source | Rgsdev: Free Low Poly Vehicles Pack (OpenGameArt) (https://opengameart.org/content/free-low-poly-vehicles-pack)

At runtime the code iterates through model meshes and creates one InstancedMesh per part per vehicle type. Body, wheels, and lights are kept as separate parts, so wheels can rotate and lights can intensify at night. Instancing reduces draw calls for repeated models, but the call count still depends on the number of parts and materials; it does not automatically turn the whole fleet into a single draw call.

API reference | Three.js InstancedMesh: instance matrices and draw calls (https://threejs.org/docs/pages/InstancedMesh.html)

Wheel rotation is advanced by θ = elapsed × speed ÷ radius, i.e., travel distance divided by tire radius. This implementation depends on the axis and size conventions after asset conversion. The external car texture uses flipY=true in the current FBX→GLB conversion chain; this is a fix for this project's assets, not something to apply blindly to all glTF textures.

Arc-length motion: speed independent of control-point distribution

Code 6 | Computing vehicle road position and orientation

if (vehicle.stationary) {
  return { t: .5, p: vehicle.stationary.position.clone(),
    rotation: vehicle.stationary.rotation.clone() };
}
const t = wrap(vehicle.phase + elapsed * vehicle.speed
  / vehicle.road.length * vehicle.direction);
const p = vehicle.road.curve.getPointAt(t);
const forward = vehicle.road.curve.getTangentAt(t);
p.addScaledVector(
  new THREE.Vector3(-forward.z, 0, forward.x).normalize(), vehicle.offset);
p.y += vehicle.kind === 'car' ? .03 : .015;
forward.multiplyScalar(vehicle.direction);
const right = new THREE.Vector3().crossVectors(new THREE.Vector3(0, 1, 0), forward).normalize();
const up = new THREE.Vector3().crossVectors(forward, right).normalize();
return { t, p, rotation: new THREE.Quaternion().setFromRotationMatrix(
  new THREE.Matrix4().makeBasis(right, up, forward)) };

elapsed × speed ÷ road.length converts travel distance into normalized progress, and wrap loops progress into [0,1). getPointAt() maps points by arc length, reducing speed changes caused by control point density; getTangentAt() provides direction, and combined with the lateral and up vectors constructs vehicle orientation. This "constant speed" is still affected by curve arc-length sampling precision.

API reference | Three.js Curve: getPointAt and getTangentAt (https://threejs.org/docs/pages/Curve.html)

Vehicles in the same lane use the same speed to keep fixed spacing; there is currently no car-following, overtaking, lane-changing, congestion propagation, or ramp merging model. Mainline endpoints extend beyond the visible view, and ramp endpoints use transparency gradient to reduce loop jumps. Vehicles moving along 3D roads is implemented, but this cannot be claimed as a traffic micro-simulation.

The interface speed shows speed × 3.6 as km/h, containing a demo convention that scene units are interpreted as meters; since the road is not a surveyed model, this speed is not a real vehicle measurement. distance comes from elapsed × speed and is also synthetic travel distance. When connecting production trajectories, position, speed, and mileage should return to their respective data sources and coordinate baselines.

Runtime screenshot | After selecting V0869, showing vehicle type, road, and demo speed. Information comes from the current vehicle object and the same pose calculation, not tied to a real plate or measured trajectory.

Picking mapping: instanceId is not a stable vehicle ID

Each frame first writes visible vehicles into per-type slots, then updates instance matrices by slot. After camera movement, visible objects change, so instanceId is the current render batch's sequence number and cannot be directly used as a business vehicle ID. Picking needs to look up the vehicle in slots using "vehicle type + instance index."

Code 7 | Associating a ray-hit instance with a vehicle entity

const meshes = parts.map(p => p.mesh);
meshes.forEach(m => m.computeBoundingSphere());
const hit = raycaster.intersectObjects(meshes, false)
  .find(h => h.instanceId !== undefined);
if (!hit || hit.instanceId === undefined) return null;
const vehicle = slots[hit.object.userData.kind as VehicleKind][hit.instanceId];
return vehicle ? { id: vehicle.id, distance: hit.distance } : null;

After model updates, bounding spheres are recomputed to avoid stale bounds for dynamic instances. After hitting a vehicle, the outer layer also compares the distance of some opaque scene meshes to filter objects occluded by them; this is not a general occlusion solution for all transparent objects, instanced environments, or complex scenes. The final return is a stable ID, and both the info panel and follow camera look up the vehicle by that ID.

Parked vehicles use a separate stationary branch; position and pose do not change with elapsed, and output 0 km/h, 0 travel distance. This clearly distinguishes parked state from mainline motion and also makes it easy to verify object identity through repeated picking as time advances.

Runtime screenshot | Service area P001 parked close-up. The parked object also uses GLB assets and instance picking; the stationary branch keeps pose unchanged, and the info panel shows parked state.

08 | Points, camera, and day/night: same object stays consistent across viewpoints

A point consists of a 3D base, a light pillar, and a DOM-projected label. The base Shader builds a ring from radius, a discontinuous rotating arc from angle and time, and a diffusing pulse; the selected state changes color and intensity. The label uses Vector3.project(camera) to go from world coordinates to in-scene pixel coordinates.

This split keeps text sharp while letting the marker bottom follow the 3D position. Currently the base and light pillar have depth test off to stay readable across bridge decks; they are semantic overlay markers, not physical lights, and their occlusion cannot be used to judge real field visibility.

Code 8 | Transition into follow-vehicle view and sustained following

progress = Math.min(1, progress + dt / 1.35);
if (progress < 1) {
  const t = progress * progress * (3 - 2 * progress);
  camera.position.lerpVectors(from.position, desired, t);
  target.lerpVectors(from.target, look, t);
} else if (instantTrack) {
  camera.position.copy(desired);
  target.copy(look);
} else {
  camera.position.lerp(desired, 1 - Math.exp(-dt * 7));
  target.copy(look);
}
camera.lookAt(target);
camera.updateMatrixWorld();

Entering follow mode uses a ~1.35-second smoothstep transition; after stable follow, position interpolation uses coefficient 1 − exp(−7dt) to reduce frame-interval variation's effect on smooth speed. Node view also saves both position and target endpoints and supports re-selecting a target during transition. The above code is the follow branch excerpt; the node branch uses the same easing form.

Selecting a node clears vehicle selection; selecting a vehicle exits the fixed point view. When the followed object loops its path, the runtime detects a large jump in normalized progress, ends the current follow, and returns to overview, avoiding the camera jumping across the road network with the object.

Runtime screenshot | East Hub view. Camera target, point label projection, and 3D scene update synchronously; surrounding business panels keep their layout.

Day/night switching is driven by a continuous variable night ∈ [0,1] that uniformly interpolates ambient, sunlight color and intensity, background, fog, environment map intensity, streetlights, glass emission, and vehicle lights. Night is not just a black overlay; exposure also rises slightly to preserve pavement and vehicle outlines.

Code 9 | Coordinating lighting with a single night parameter

night = THREE.MathUtils.damp(night, nightTarget, 4, dt);
effects.night.value = night;
ambient.intensity = THREE.MathUtils.lerp(1.3, .45, night);
sun.intensity = THREE.MathUtils.lerp(3.1, .45, night);
renderer.toneMappingExposure = 1.1 + night * .12;
scene.environmentIntensity = .035 * (1 - night * .7);
lampMaterial.emissiveIntensity = .1 + night * 3.5;
glass.emissiveIntensity = night * .6;
serviceLights.forEach(light => { light.intensity = night * 260; });

The excerpt omits color, background, and fog interpolation, plus a branch that snaps directly to target when close. Vehicle headlights use instanced planar beams, road light pools are computed by material, and service areas have separate light objects; they are not independent light sources configured to cast real shadows for each vehicle. Full lighting effect and runtime cost need to be evaluated together on the target GPU.

Runtime screenshot | Night overview. The night parameter simultaneously affects environment, pavement, facilities, and vehicle lights; business panels still show the same demo snapshot, not real traffic at the capture moment.

09 | From demo to operating system: what data capabilities need to be added

Visual model, continuous motion, model picking and demo object association, and real business data are four independent capabilities. The current project implements the first three; production integration still needs trajectory sources, spatiotemporal matching, data quality, event states, and operation acknowledgments. The following interface requirements breakdown is not backend functionality already implemented by this project.

Layer	Info an interface should at least explain	Display and processing strategy
Entity and space	entityId, entity type, roadId, direction, laneId, coordinate system, elevation baseline	Use a uniform business ID; bind model and panel only after coordinate conversion
Time and source	observedAt, receivedAt, source, quality state, validity period	Show data cutoff time; after expiry keep last known state or stop extrapolation
Trajectory	Continuous observation points, sampling interval, speed source, positioning quality	Interpolate only for smoothing; do not mark interpolated positions as new observations; handle dropouts separately
Statistics	Time window, section scope, aggregation and dedup methods	Compute flow, speed, and vehicle count separately; do not replace operational statistics with scene instance count
Event	eventId, level, detection and confirmation time, responsible unit, state, evidence, acknowledgment	Present state transitions for detection, confirmation, dispatch, execution, recovery
Operation	User role, authorization scope, command number, confirmation and execution result	Separate viewing, suggestion, and command execution; make failures and unacknowledged results visible

When connecting real vehicle information, public dashboards and business terminals need different information granularity. Exhibition pages can use simulated objects; business pages show anonymous target IDs, category, last observed time, and data source by task. Real vehicle trajectories involve personal information boundaries; the actual processing basis, permissions, and retention requirements need to be determined separately per applicable scenario. Displaying a number on the frontend does not equal compliant processing.

10 | Finally

Starting from the current smart highway demo project, we need to keep deepening the entire production pipeline for visualization dashboards. The core direction is: heavy interaction, lightweight performance, smooth animation for a visual intelligent platform.

Stage 1: Unify interaction and layout foundation

We have completed basic development of a drag-and-drop npm library, and existing dashboards are built on it. But the problems are evident:

• Layout resources in edit and preview modes are not unified: Drag-time layout data, preview-time rendering logic, and export-time coordinate mapping are fragmented. A unified underlying layout model is needed so all modes share one coordinate and size baseline.
• Component state sync complexity: After each component is changed in drag mode, it needs to sync to preview, to data structures, and to export formats; the flow is long and error-prone.

Solution: Build a unified layout engine. Editing, preview, and export all run on that engine, reducing conversion cost between modes.

Stage 2: Accumulate component and chart libraries

The core of intelligent visualization is your own component library, and this is a long-term process.

Open-source component libraries:

My platform component library (being built)

Current state:

• Some extension points are reserved
• ECharts resources and Three.js official component resources are integrated
• A custom component set exists, but it is not yet ideal

What needs to be done:

1. Deepen the chart component library
   • Basic charts like bar, line, scatter need a unified data interface
   • Continuously improve chart visual effects and interaction feedback based on the data samples accumulated from earlier design drafts
   • Build a minimal API for chart configuration so the platform can automatically recommend the most appropriate chart type
2. Integrate 3D components
   • Based on Three.js official resources, wrap easy-to-use generic modules for 3D scene containers, roads, vehicles, flowing light
   • 3D components should support drag-to-adjust viewpoint, camera preset switching, object picking and other interactions
3. Build a function library and feedback loop
   • Create calculation functions for each component (coordinate mapping, data aggregation, animation interpolation, etc.)
   • Feed these functions to the platform for learning, so the platform can understand "what data fits what chart and what configuration"

Stage 3: Visual intelligent agent platform

With a unified component library and function library, the next step is making the platform capable of intelligent production.

Core capabilities:

• Auto recommendation: user gives a business scenario and data source, the platform automatically recommends suitable component combinations and layout plans
• Intelligent configuration: based on the function library and style preferences from historical design drafts, automatically generate draft configurations; users only adjust details
• Batch production: the same dashboard template quickly adapts to different data sources, business objects, and regions, enabling template-based production

This stage is essentially turning design knowledge and technical decisions into learning material for the platform, reducing the cost of starting every new project from zero.

Final goal: interaction innovation, users enjoy it

All this work points to the same original intention:

Use visualization and automation technology to improve user experience, letting users enjoy smooth, intelligent interaction on the web.

Specifically:

• Smooth: drag without lag, stable animation frame rate, quick 3D scene response
• Intelligent: the platform understands business needs, quickly generates high-quality plans, reduces repetitive user work
• Usable: mature component library, unified interfaces, users can build dashboards without deep learning

This is not just technology stacking; it is a complete loop centered on user experience and production efficiency. Every step needs to be validated by actual results.

After all that vision, back to the point. I have organized the design drafts and the smart highway 3D source code.

If you need the source for reference, you can get it from the same-titled post on the 柳杉前端 WeChat public account.