SIMSplat: Language-Aligned 4D Gaussian Splatting for Driving Scenario Generation¶

Conference: ECCV2026
Paper: ECCV
Area: Autonomous Driving
Keywords: 4D Gaussian Splatting, Scene Graph, Language Alignment, Driving Scene Editing, Multi-Agent Simulation

TL;DR¶

SIMSplat embeds appearance, motion, and location language features directly into the nodes of a scene-graph 4D Gaussian representation, making a reconstructed driving scene queryable by free-form text and letting object-level editing, multi-agent path refinement, and VLM-driven scenario mining all run on that same representation; on Waymo it raises open-vocabulary object grounding accuracy from 0.35 to 0.73, reaches an 87.2% task completion rate with human guidance (71.1% fully VLM-driven), and cuts the multi-agent failure rate to 20.0%.

Background & Motivation¶

Manipulating driving scenes built from real sensor data has become an attractive alternative to game-engine simulators such as CARLA and AirSim. Diffusion models, neural radiance fields, and Gaussian Splatting all reconstruct photo-realistic scenes from multi-view driving data, and adding a language model on top makes it possible to direct scene edits with natural language. Spread the pipeline out, however, and the problem turns out to lie not in any single capability but in how the pieces are stitched together. Language-guided editors such as ChatSim and SceneCrafter either carry an online 3D detector at inference time or require a human to supply instance IDs or attributes first, effectively translating a natural-language sentence into rigid structured attributes; when they do modify an object, they can only paste in a pre-stored virtual asset or remove the object outright, leaving little room to edit an existing object. Non-language editors such as MARS and OmniRe support richer object-level editing, but they ground targets through predefined instance attributes and offer neither language controllability nor automation. Both lines share a further blind spot: almost every framework focuses on rigid objects such as vehicles and leaves pedestrians out, even though pedestrians are precisely the agents that matter most in safety-critical scenarios. Verification is equally narrow — feasibility is typically checked only for the ego vehicle or a single target object, ignoring how one agent's behavior change cascades to the surrounding traffic. And scaling beyond hand-crafted scenarios demands manual intervention at every step.

These limitations share a common root: there is no shared scene representation that is both expressive enough for complex road dynamics and accessible enough to be addressed by natural language. If road elements were represented in a structured, language-addressable form that jointly carries their visual appearance, dynamic behavior, and spatial context, then querying, editing, and simulating could all happen within a single framework, and the whole pipeline could be automated. This paper follows exactly that route, combining scene-graph 4D Gaussian Splatting with language-aligned features: appearance, motion, and location features are written directly into the Gaussian scene-graph nodes, so the reconstructed scene is queryable by free-form text; language queries ground the target, edits act on the same graph, and multi-agent refinement validates consistency at the level of the whole scene. Because language alignment already connects natural language to the underlying scene structure, the pipeline plugs directly into a VLM for closed-loop operation — the VLM not only generates editing prompts but also inspects rendered outputs, iteratively adjusting assets and motion parameters to produce long-tailed driving scenarios without human intervention. Core idea: instead of bolting a detector and attribute matching onto the tail of the pipeline, train appearance, motion, and location semantics directly into the nodes of a 4D Gaussian scene graph, so that "find the car that is turning left" becomes an intrinsic property of the representation — and use that as the single entry point that carries editing, multi-agent simulation, and VLM-driven closed-loop mining.

Method¶

Overall Architecture¶

SIMSplat addresses one task: manipulating a real driving scene through language such that the modification stays physically and interactively coherent. Its answer is to pin the entire pipeline onto one data structure. The input is a multi-view driving sequence, from which a scene-graph 4D Gaussian representation is reconstructed — vehicles, pedestrians, and the static background each become nodes, and every node defines a set of Gaussians in a canonical space that is transformed or deformed into world coordinates over time. A language alignment stage then writes three kinds of features into these nodes: appearance (CLIP semantics), motion (trajectory), and location (position relative to the ego view). Everything afterwards operates on this language-addressable graph. Given a free-form sentence, the system first performs open-vocabulary grounding to find the target and anchor objects; it then applies an object-level edit on the graph (modify motion, insert new objects, replace, remove); the edited trajectories go through multi-agent path refinement, where all surrounding participants react together according to a prediction model; finally the scene is rendered and validated. Validation is carried out by a VLM, which loops back to adjust assets or motion parameters when the result is unsatisfactory — a closed loop that can also be overridden with fully human-specified parameters.

%%{init: {'flowchart': {'rankSpacing': 24, 'nodeSpacing': 28, 'padding': 6, 'wrappingWidth': 400}}}%%
flowchart TD
    A["Multi-view driving sequence"] --> B["Scene-graph 4D Gaussian reconstruction"]
    B --> C["Motion-aware language alignment"]
    C --> D["Open-vocabulary object grounding"]
    D --> E["Language-controlled object-level editing"]
    E --> F["Multi-agent path refinement"]
    F --> G["VLM-driven automated scenario mining"]
    G -->|validation fails: iterate parameters| D
    G -->|validation passes| H["Edited driving scene"]

One clarification is needed: SIMSplat produces edited versions of existing real scenes, not scenes synthesized from scratch. Its generative capability lies in inserting new assets into a reconstructed scene (drawn from an asset bank extracted from real sensor data), rewriting the behavior trajectories of existing objects, and propagating the edit through the whole traffic flow with a prediction model — thereby creating long-tailed and adversarial scenarios that do not exist in the original data.

Key Designs¶

1. Motion-aware language–Gaussian alignment: writing appearance, motion, and location semantics into scene-graph Gaussian nodes

The pain point is that driving scenes are densely populated and visually repetitive, so attribute matching on "the black car" is almost guaranteed to be ambiguous, while asking a VLM to emit bounding-box coordinates is unreliable. SIMSplat neither matches attributes nor asks for coordinates; it trains language semantics into the Gaussians themselves. For appearance, it does not attach a separate segmentation model to each node — it projects the Gaussians belonging to a node onto the image plane to obtain that object's mask, then extracts CLIP features inside the mask, removing the need for an external segmenter. Since CLIP features are high-dimensional, a lightweight autoencoder \((E, \Psi)\) compresses them into a low-dimensional latent space; the resulting latent code \(h_t(o) = E(f_t^{\text{CLIP}}(o)) \in \mathbb{R}^d\ (d \ll D)\) supervises a per-Gaussian appearance feature \(c_i^{\text{app}}\) optimized self-supervisedly. At inference, the rasterized \(c_i^{\text{app}}\) is decoded back into CLIP space and compared against the text query, enabling open-vocabulary selection at both the pixel and the Gaussian level.

Motion is the harder half. The authors observe that prior methods which embed language features into Gaussians (LangSplat, 4DLangSplat) simply cannot read the behavior of road objects — the dynamics they understand are indoor ones such as opening a cup, whereas driving queries look like "a pedestrian crossing the street on the left side of the ego vehicle" or "a vehicle crossing the intersection from right to left," which bundle motion cues (speed, direction, turning) together with relative position. SIMSplat therefore encodes each object's trajectory \(\mathbf{X}=\{(x_t,y_t)\}_{t=1}^{T}\) into a latent vector \(z\) with a trajectory encoder and pairs it with two codebooks: a motion codebook and a location codebook, each prototype vector standing for a typical road motion or spatial relation (turning left, moving right to left, in front of the ego vehicle, on the left side of the ego vehicle). Because rigid and non-rigid agents move differently, vehicles and pedestrians keep separate motion codebooks while the location codebook is shared across object types. Given the trajectory embedding, similarities against the prototypes are computed and the motion and location features are formed as convex combinations of the corresponding codebook vectors:

\[f^{\text{mot}} = \sum_{k} \alpha_k \, p_k^{\text{mot}}, \qquad f^{\text{loc}} = \sum_{k} \beta_k \, p_k^{\text{loc}}\]

This works because it decouples behavior from pixel appearance and represents it separately, and because the codebook form discretizes a continuous trajectory into a handful of nameable motion prototypes that can be aligned against text prototypes directly. Training combines the motion and location alignment losses with a commitment term:

\[\mathcal{L}_{\text{temp}} = \lambda_{\text{align}}\big(\mathcal{L}_{\text{mot}} + \mathcal{L}_{\text{loc}}\big) + \lambda_{\text{commit}} \mathcal{L}_{\text{commit}}\]

The first two terms measure cosine distance to the text prototypes, while the commitment term keeps the trajectory embedding \(z\) close to the codebook combination it selected, so that the codebooks are actually used. ⚠️ The similarity normalization, the \(\lambda\) values, and the codebook sizes are placed in the supplementary material; refer to the original paper.

Grounding then proceeds in two tiers. The text prompt is encoded with an E5 Sentence Transformer; rendered appearance features are decoded and compared against the prompt to produce pixel-level similarity maps, which are post-processed into binary masks selecting candidate instances. Separate trajectory encoders and text projectors for vehicles and pedestrians are then loaded, and the temporal features of candidate trajectories are compared with the prompt embedding by cosine similarity, taking the highest-scoring object. Appearance narrows the candidate set, and motion plus location pick out the candidate whose behavior actually matches — which is precisely why the model still succeeds when appearance-only prompts such as "black sedan" or "pedestrian with a red coat" become ambiguous in dense traffic. Each object node ends up extended as \(G_o(t) = \big(\{g_i(t)\}_{i=1}^{N_o},\, c_o^{\text{temp}}\big)\), binding the behavioral context \(c_o^{\text{temp}} = (f^{\text{mot}}, f^{\text{loc}})\) at the node level and turning open-vocabulary reasoning over object dynamics into a property of the node.

2. Language-controlled object-level editor: naming who to change and how, in free text

Once grounding works, editing falls naturally onto the same scene graph. Supported operations cover motion modification (accelerating, reversing, lane changing, turning), insertion of new dynamic or static objects (adding a following vehicle, placing a roadside obstacle), replacement, and removal — and they span both vehicles and pedestrians. The latter is the key difference from ChatSim, OmniRe, and similar editors: pedestrian editing (adjusting walking speed, inserting real human assets) was essentially absent from prior frameworks. Action parameters are flexibly specified — speed, direction, start time, relative distance, and start/end positions can all be given explicitly — so the same instruction can be coarse ("make the black car at the intersection go straight") or fine ("walk from \((x_1,y_1,z_1)\) to \((x_2,y_2,z_2)\)"), and group-level commands such as "remove all crossing pedestrians" are supported as well. When inserting new objects, the asset bank covers vehicles, pedestrians, traffic signs, and road objects such as barriers, cones, and construction equipment. Unlike conventional simulators that rely on synthetic or static pedestrian models, its pedestrian assets are dynamic real-world assets extracted from sensor data, each annotated with a descriptive caption (e.g. "a pedestrian walking from left to right with a red backpack"), so inserted pedestrians retain natural joint motions and gestures instead of sliding as flat cut-outs.

3. Multi-agent path refinement: making surrounding vehicles and pedestrians react to the edit

Trajectories produced by a predefined function set may be reasonable for the target object itself, but such a function set is not a multi-agent planner and does not consider how the modification affects surrounding traffic. Prior methods typically guarantee only that the target's path is collision-free, leaving every other car on its original trajectory — a scene in which a vehicle brakes sharply and the car behind shows no reaction is not a real interaction. SIMSplat instead targets reactive scenarios: not only the edited target changes, but surrounding agents respond naturally as well. The authors train SMART-1B on the Waymo Open Dataset as the motion prediction model. Given the target object's pre-generated trajectory \(\tau^{\text{edit}}\) from the motion controller and the observed history \(\mathbf{X}_{1:t}\) of all agents, the predictor \(\mathcal{P}\) produces a joint future rollout in one shot:

\[\hat{\mathbf{X}}_{t+1:T} = \mathcal{P}\big(\mathbf{X}_{1:t}, \tau^{\text{edit}}\big)\]

Because \(\hat{\mathbf{X}}_{t+1:T}\) covers both the target and the surrounding objects, an edited scene is the result of recomputing the entire traffic flow rather than rewriting a single trajectory. The behaviors reported in the paper include a following vehicle detouring or stopping when the edited vehicle ahead brakes abruptly, adjacent cars avoiding a collision when a jaywalking pedestrian appears, and a pedestrian halting at the edge when a newly inserted obstacle blocks the crosswalk. Since this module depends on a prediction model and is sensitive to uncertainty, the framework also offers the option to bypass it when deterministic editing is preferred.

4. VLM-driven automated scenario mining: closing open-loop editing into an iterable long-tail generator

Writing prompts by hand does not scale and limits diversity, which is the last bottleneck on the way to scale. SIMSplat brings a VLM into the loop: the VLM takes multi-view scene images as input and generates natural-language prompts describing potential scene modifications. Each prompt is first checked for feasibility against a predefined set of supported editing functions, then goes through visual grounding in the language-aligned Gaussian scene (for a prompt such as "make the black car turning at the intersection go straight," the VLM extracts the caption "black car turning at the intersection" and the grounding mechanism retrieves the matching object). At this point localization is entirely an intrinsic property of the representation, requiring neither an online detector nor manually specified spatial annotations. After execution, the scene is rendered back onto the 2D image plane for two levels of validation: hard invalid outcomes such as collisions or off-road driving are filtered out first, and the VLM then receives the edited RGB images, the BEV map, and the trajectories of the target and surrounding agents to judge whether the modification faithfully follows the original prompt. If inconsistencies are detected or plausibility is not satisfied, the system iterates on asset selection or motion parameters until all constraints are met. Full automation is supported, and a manual entry point for prompting and parameter tuning is retained.

A Worked Example¶

Take the first instruction in Figure 1: "Add a bulldozer 5m behind the black car crossing the street." The VLM generates this prompt from the multi-view images, and the feasibility check confirms it is a supported insertion. Grounding then runs in two stages — appearance similarity first narrows the candidates to the several dark vehicles in the scene, and motion features (currently crossing) plus location features (relative position to the ego view) collapse the candidate set to the single black car that is crossing. The system retrieves a bulldozer from the asset bank and places it 5 m behind that car along its heading, with the start position, orientation, and relative distance given explicitly by the prompt. The edit then enters multi-agent refinement: the prediction model sees a stationary bulldozer ahead and outputs a joint future rollout for all affected agents, in which the red vehicle gradually slows to a stop to avoid a collision. Finally the rendered RGB and BEV results go back to the VLM to check fidelity to the prompt; if they fail (for instance, if the insertion distance is too short to be plausible), the system adjusts the distance or the asset and iterates until it passes. The same pipeline handles instructions such as "Add a wheelchair user crossing the street from beside the pedestrian standing on the left," which require inserting a real pedestrian asset while preserving natural joint motion.

Loss & Training¶

Training has several parts. The appearance features \(c_i^{\text{app}}\) are optimized self-supervisedly, supervised by the compressed CLIP latent so that the autoencoder reconstructs \(\Psi(h_t(o)) \approx f_t^{\text{CLIP}}(o)\). Temporal alignment uses the \(\mathcal{L}_{\text{temp}}\) above, in which the motion and location alignment terms measure cosine distance to text prototypes and the commitment term pulls the trajectory embedding toward the selected codebook combination. Scene reconstruction is trained on the Waymo Open Dataset using the front, front-left, and front-right cameras, with 100 frames sampled at 10 Hz per sequence, every 10th frame held out for testing, on a single NVIDIA A100 GPU. The multi-agent predictor is SMART-1B trained on Waymo; motion generation takes the first 11 timesteps of each trajectory as input and predicts 80 future timesteps. The VLM automation stage uses Qwen3-VL-32B, with further training and evaluation details in the supplementary material.

Key Experimental Results¶

Main Results¶

The dataset is the Waymo Open Dataset. One honest caveat up front: the main paper does not evaluate reconstruction fidelity metrics such as PSNR / SSIM / LPIPS. The evaluation focuses on three far more application-relevant questions — can language find the right object, can the instruction be executed, and does the resulting scene cause accidents — using open-vocabulary grounding accuracy (Acc.) and video-level IoU (vIoU), task completion rate, and various failure rates. No reconstruction-quality numbers are reported in the main text.

Table 1 (capability comparison of scene editors, ✓/✗ as summarized in the paper):

Method	Pedestrian editing	Existing-object editing	Vehicle path refine.	Pedestrian path refine.	Language control	Automation	Object grounding
MARS	✗	✓	✗	✗	✗	✗	Instance ID
HUGSIM	✗	✓	✓	✗	✗	✓	Tracking ID
ChatSim	✗	✗	✗	✗	✓	✗	Attributes
SceneCrafter	✗	✗	✗	✗	✓	✓	Bounding box
OmniRe	✓	✓	✗	✗	✗	✗	Instance ID
SIMSplat	✓	✓	✓	✓	✓	✓	Description

Table 2 (open-vocabulary object grounding, Acc. / vIoU):

Method	Vehicle Acc.	Vehicle vIoU	Pedestrian Acc.	Pedestrian vIoU	Total Acc.	Total vIoU
LangSplat	0.27	0.47	0.30	0.32	0.28	0.40
4DLangSplat	0.33	0.53	0.37	0.44	0.35	0.49
Ours	0.83	0.81	0.63	0.78	0.73	0.80

Table 3 (editing task completion rate, %): ChatSim reaches 26.7 overall, OmniRe† (with editing functions added by the authors) 27.8, SIMSplat VLM-driven 71.1, and SIMSplat human-guided 87.2. Broken down, human-guided SIMSplat scores highest on "add pedestrian" (93.3) and "modify pedestrian" (90.0), whereas ChatSim and OmniRe score only 0.0 / 16.7 and 0.0 / 23.3 in those two columns respectively.

Ablation Study¶

Table 4 (ablation on language feature components, Acc. / vIoU, total):

Appearance	Motion	Location	Vehicle Acc.	Vehicle vIoU	Pedestrian Acc.	Pedestrian vIoU	Total Acc.	Total vIoU
✓			0.53	0.56	0.27	0.38	0.40	0.47
✓	✓		0.73	0.70	0.27	0.38	0.50	0.54
✓		✓	0.57	0.64	0.33	0.42	0.45	0.53
✓	✓	✓	0.83	0.81	0.63	0.78	0.73	0.80

Table 5 (motion generation failure rates, %, lower is better):

Method	Collision (vehicle)	Collision (pedestrian)	Off-road	Total failure
ChatSim	53.3	36.7	33.3	53.3
OmniRe†	63.3	30.0	26.7	70.0
GPT2Motion (GPT-5 used directly as motion generator)	60.0	73.3	36.7	80.0
Ours (w/o path refinement)	43.3	26.7	10.0	53.3
Ours	13.3	16.7	6.7	20.0

Table 6 (VLMs driving the automated pipeline):

Model	Avg. iterations	Task completion	Plausibility score
Qwen3-VL-32B	4.5	71.1	2.80
Qwen3-VL-8B	7.4	48.3	2.10
GPT-5	3.6	78.9	3.25
GPT-5-mini	4.1	73.3	2.95
Claude-Opus-4.1	3.9	80.0	3.10

Key Findings¶

Motion and location drive most of the grounding gain, and they divide the labor. With appearance alone the total accuracy is 0.40; adding motion alone raises it to 0.50 and adding location alone to 0.45, while all three together reach 0.73. The finer pattern is that motion helps vehicles most (Acc. 0.53 → 0.73) whereas location helps pedestrians most (Acc. 0.27 → 0.33) — intuitive, since vehicles differ chiefly in how they drive, while pedestrians are small with weak appearance cues and are better pinned down by relational descriptions such as "standing on the left side." Combining both benefits every object type.
Multi-agent refinement is the single largest contributor to the drop in overall failure rate. Removing it leaves a 53.3% total failure rate; with it the rate falls to 20.0%, pedestrian collisions drop from 26.7% to 16.7%, and off-road driving from 10.0% to 6.7%. The paper notes that baselines do acceptably when a static object is placed in isolation with no surrounding agents, but as soon as the edited object must coordinate with nearby agents, collisions and off-road driving become frequent — single-object collision-free planning is not enough in real urban traffic.
The form of language control and the strength of the VLM are matched to each other. ChatSim grounds objects by attribute matching, and OmniRe has scene-graph reconstruction without language controllability, while VLMs excel at producing rich semantic descriptions rather than precise boxes or pixel coordinates. SIMSplat grounds purely from free-form descriptions, which plays directly to that strength — the immediate reason its fully VLM-driven version (71.1%) beats every baseline.
Larger VLMs are worth the cost. GPT-5 converges in 3.6 iterations on average with 78.9% completion and a 3.25 plausibility score; Claude-Opus-4.1 has the highest completion (80.0%). The small model (Qwen3-VL-8B) needs the most iterations (7.4) and completes fewer than half the tasks, but remains attractive for inference speed and cost. SIMSplat defaults to the open-source Qwen3-VL-32B and the authors recommend trading off against the compute budget.

Highlights & Insights¶

Turning grounding from a downstream module into an intrinsic property of the representation is the cheapest and most effective move in the paper. Prior editors either attach an online detector or ask a human for instance IDs, so a conversion layer always sits between language understanding and the scene representation; SIMSplat trains semantics into the Gaussian nodes, so "find that car" degrades into a feature comparison that needs neither an extra model nor manual annotation.
Discretizing behavior into nameable prototypes via codebooks bridges the modality gap between language and continuous trajectories. Trajectories are continuous signals while text describes discrete concepts (turning left, turning right, crossing), and a set of learnable prototype vectors in between serves as the bridge — while also yielding a structured prior in which motion codebooks are per-object-type and the location codebook is shared, which is far more stable than regressing trajectories straight into text space.
The two-tier scheme of appearance-first narrowing followed by motion/location re-ranking is a retrieval paradigm that transfers directly. Any retrieval task where the target category is the same but the behavior or relation differs — action localization in video, instruction following in robotics — can adopt the same "static attribute recall plus dynamic attribute re-ranking" structure.
Multi-agent refinement upgrades scene editing from "change one object" to "change one traffic flow," and along the way gives an honest engineering answer: prediction models carry uncertainty, so the framework keeps a switch to bypass the module. Knowing when a module should not be used is more credible than claiming end-to-end perfection.

Limitations & Future Work¶

The main text reports no reconstruction quality metrics (PSNR / SSIM / LPIPS) and no fidelity results for novel-view or novel-time synthesis; evaluation is entirely about grounding, completion, and failure rates. If the framework is to be used for augmentation data in perception training, rendering fidelity is in fact a hard requirement, and the paper gives no direct evidence on it.
The ceiling of the multi-agent refinement is entirely set by SMART-1B, and the authors acknowledge that the module is sensitive to prediction uncertainty and failure cases. If the prediction model is itself weak on long-tailed scenarios — exactly the kind the system is meant to generate — refinement may introduce new implausible behavior.
Experiments are conducted only on the Waymo Open Dataset, using the front, front-left, and front-right cameras; whether the approach holds under full-surround coverage or genuinely long-tailed distributions such as night and rain is not verified. Even the best plausibility score in the VLM automation stage is only 3.25 out of 4, indicating that the automatic loop still needs retries or human fallback on a substantial fraction of cases.
Possible improvements: bring rendering fidelity into the evaluation and tie it to downstream perception-augmentation gains; attach an uncertainty measure to refinement so that high-uncertainty cases fall back to a conservative policy rather than bypassing the module entirely; and report sensitivity analyses for codebook size and motion/location alignment weights, which the main text also omits.

vs ChatSim: ChatSim uses collaborative LLM agents for editable scene simulation and has the strongest language controllability, but it does not explicitly model individual road agents or capture temporal motion, so it can neither modify existing objects nor edit pedestrians, and its attribute-based grounding is ambiguous in dense traffic. SIMSplat differs by writing semantics into the representation and modeling motion separately, at the cost of having to reconstruct a 4D scene graph.
vs OmniRe: OmniRe reconstructs city-scale scenes with a scene graph and supports object-level editing and even pedestrian insertion, making it the closest in capability; but its grounding depends on instance IDs, it has no language controllability, and it lacks multi-agent path refinement. SIMSplat effectively adds a language interface and interaction consistency on top of this class of scene-graph reconstruction.
vs 4DLangSplat / LangSplat: these are the representatives of language Gaussian Splatting and the direct baselines for grounding. Their semantic fields mainly capture object appearance and understand simple indoor dynamics; the core increment here is elevating motion and location to first-class citizens of the alignment objective, which lifts total grounding accuracy from 0.35 to 0.73.
vs HUGSIM / MARS: both are high-fidelity simulators for autonomous driving supporting existing-object editing and vehicle path refinement, and HUGSIM is automated, but neither accepts natural language or refines pedestrian paths. The relationship is more complementary than competitive: the language interface and pedestrian modeling are what SIMSplat adds, while expensive closed-loop real-time rendering is beyond its scope.

Rating¶

Novelty: ⭐⭐⭐⭐ Aligning motion and location semantics into 4D Gaussian nodes via codebooks and using that as the single entry point for editing and multi-agent simulation is a complete angle that no prior work has taken.
Experimental Thoroughness: ⭐⭐⭐ Task completion, failure rates, and a VLM comparison are all covered with a clean ablation, but reconstruction fidelity is missing, validation is on Waymo only, and the sensitivity analyses for refinement and codebook hyper-parameters sit in the supplementary material.
Writing Quality: ⭐⭐⭐⭐ The motivation builds layer by layer and the capability comparison table is immediately legible; the method is clearly described, though several equations are corrupted in the cached version and some implementation details (codebook sizes, loss weights) are only available in the supplementary.
Value: ⭐⭐⭐⭐ It offers a deployable unified route to language-controllable driving scenario generation, with pedestrian editing and whole-scene consistency validation particularly well aimed at safety-critical needs; if rendering fidelity is validated, its value for downstream perception data augmentation would be considerably higher.