fix wasd speed during training

[kmeirlaen]

Summary

After commit eeaa9ed95dd171deb8cbba881e071ac85ca16837, WASD movement speed became scale-dependent. This worked correctly when viewing/editing a splat, but during dataset training the movement speed became much too fast.

The fix is surgical: exclude core::NodeType::DATASET container nodes from the whole-scene bounds used to derive the camera movement scale.

Root Cause

computeWholeSceneBounds() already skipped several container node types:

• GROUP
• PLY_SEQUENCE
• CAMERA_GROUP
• IMAGE_GROUP

However, it did not skip DATASET.

Scene::getNodeBounds(DATASET) recursively aggregates child bounds. During training this produced a huge dataset-level radius, which dominated the combined scene extent and pushed wasdMoveScale() to its clamp maximum.

In editing mode, switchToEditMode() clears the dataset hierarchy and re-adds only the trained splat as Trained Model, so the movement scale was based on the expected splat bounds.

Solution

Treat DATASET like the other container node types when computing the whole-scene movement bounds:

if (node->type == core::NodeType::GROUP || node->type == core::NodeType::PLY_SEQUENCE ||
    node->type == core::NodeType::DATASET ||
    node->type == core::NodeType::CAMERA_GROUP ||
    node->type == core::NodeType::IMAGE_GROUP)
    continue;

This prevents the dataset root aggregate bounds from poisoning the movement scale while still allowing the actual point cloud or training model nodes to contribute their trimmed bounds.

Expected Result

During training, sceneExtent() should now be based on the actual visible/training geometry, approximately matching the edit-mode radius around 200-213 for the investigated dataset, instead of the dataset aggregate radius around 751894.

WASD movement during training should therefore feel consistent with editing/viewing the resulting splat.

How this was investigated:

Symptom

During training, the viewport reported:

wasdMoveScale: 100, effective_speed: 800, scene_extent: 751893.8

After switching to editing mode, the same scene behaved normally:

wasdMoveScale: 4.125218, effective_speed: 33.001743, scene_extent: 206.2609

Because WASD speed is computed from scene_extent / 50 and clamped to 100, the training extent forced movement to the maximum scale.

Investigation

Temporary logging was added around InputController::computeWholeSceneBounds() and expandNodeWorldBounds() to print each contributing node's bounds and the combined radius.

During dataset/training mode, the logs showed:

sceneExtent node 'LFS' type=DATASET ... local_radius=751894 ... world_radius=751894
sceneExtent node 'PointCloud' type=POINTCLOUD ... local_radius=212.96 ... world_radius=212.96
sceneExtent combined ... radius=751894

After switching to editing mode, the logs showed:

sceneExtent node 'Trained Model' type=SPLAT ... local_radius=201.44 ... world_radius=201.44
sceneExtent combined ... radius=201.44

This proved that the training speed was not caused by the active splat or point cloud bounds. It was caused by the dataset root node contributing a recursive aggregate AABB that included the full dataset hierarchy.

[Copilot]

Pull request overview

This PR fixes camera WASD navigation speed during dataset training by preventing dataset container nodes from inflating the whole-scene bounds used to derive movement scaling.

Changes:

• Exclude core::NodeType::DATASET nodes from InputController::computeWholeSceneBounds() so the movement scale reflects actual visible/training geometry rather than the dataset-root aggregate.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[MrNeRF]

Ok, that was easy