Skip to content

v1.0.2

Choose a tag to compare

@amariichi amariichi released this 24 Aug 14:44
· 7 commits to main since this release
1d33f90

Housekeeping, with one thing worth knowing if this shares a GPU with anything else. Nothing here changes what the app does — the scenes you make and the way you look at them are identical to v1.0.1, and the PLY files come out byte for byte the same.

  • The renderer is now PlayCanvas 2.21.4, up from 2.14.4. It was pinned because the newer engine rendered a blank canvas: unified rendering became the default at 2.15, and the two things this viewer reached for through an undocumented sorter — the cue to draw, and the gaussian positions it frames a scene from — both stopped being reachable that way. Both are published API now, and the cue is read from the engine's own constant, so a rename upstream becomes a build error rather than a blank canvas. The pin existed to buy time, and non-unified rendering is documented as going away, so this was when rather than whether.

    A second break came with it, and was not in anyone's release notes: 2.21.4 chooses how to read a scene from the file extension of the name it is given, and "open a .ply from this machine" hands the viewer a blob: address, which has no name at all. Scenes from the server were never affected, so checking only that route would have shipped a viewer that could not open a local file.

    Stereo is unchanged and was measured rather than assumed: the two eyes still carry projection matrices identical in every vertical term and opposite in the horizontal skew — not within a pixel, the same bits. Drawing still happens only when something moved: with a scene loaded and nothing touched, 180 frames pass and none are drawn.

  • The scene generator gives the GPU back between images. The resident ml-sharp worker keeps the model in memory so that each scene costs about 3 seconds instead of 16.5, and that model is 2.7 GB. It was also keeping one image's working memory for the rest of its life, so an idle worker held 11.5 GB. It now holds 3.1 GB.

    This costs nothing: the same image three times took 2.63 s with the memory kept, then 2.38 s and 2.37 s with it released after each. If you have been running this on a card where 11.5 GB was awkward, that constraint is gone.

Verified by generating a scene and looking at it on a phone, which is the only check that catches this kind of fault — the upgrade passed typecheck, lint, all 142 tests and the build at a point when it was rendering nothing at all.

The full description of what this project is, and the two external conditions worth reading before installing, are in v1.0.