RubbleVox is the project I do not know what to do with. So I am letting it go.
The destruction works. The voxel grid loads. Buildings come apart on impact and the camera does not throw up. Those are wins. They are not enough wins to keep me in the editor.
So I asked AI to take the rewind layer from RubbleRewind and graft it onto RubbleVox. Same snapshot ring buffer, same easing curves, same parameter sliders. A few prompts later RubbleVox had a rewind button.
That is what ships. RubbleVox plus rewind, renamed RubbleVoxRewind, parked on the released page next to its older sibling. One more downloadable tech demo. One more chassis-heater for anyone with a card to spare.
The honest part: the rewind does not fix what is wrong with RubbleVox. The actual problem is the one I outlined the first time around. I assumed voxels would be cheaper than Voronoi-fractured polygons because the mental model was simpler. The mental model was simpler. The runtime was not.
Teardown is the reference everyone reaches for, and Teardown is also why the answer is “rebuild your engine.” Tuxedo Labs did not bolt voxel destruction onto a generic 3D pipeline; they built a voxel engine first and made the rest of the game fit it. Lighting, occlusion, physics, audio, all aware of the same grid. Off-the-shelf Godot plus a voxel-shaped ambition is not the same thing.
So in this branch RubbleVoxRewind feels heavier than RubbleRewind on every axis I touch. Load is heavier. Destruction is heavier. The reset on R is heavier. The rewind I just bolted on does not feel like the bottleneck. The voxel grid does.
The right next move is not to keep paying for that grid. RubbleRewind already does the same trick on lighter geometry. RubbleVoxRewind ships because it is done, not because it is better.
If the gameplay is good, the prompts don’t matter. If the project is heavy, ship is sometimes the only way to put it down.