Frame Studio
- Gaussian splats (PLY, SPZ v2-v4), PLY vertex colours, panorama skies
- Copy, cut, paste and duplicate for objects, splats and world items
- Walkable-area rebake moved off the UI thread; viewport one frame sooner;
refresh-locked pacing (FS_PACE=timer for the old one)
- Fixed: bundle thumbnail use-after-free crash, auto-save deleting
environments, saves into scratch copies, edits lost on non-ASCII paths,
unopenable manifests with inf/nan, bundle save data loss, opening a home
marking it changed, gizmo NaN, long paths, many malformed-file crashes
- Updater verifies sha256, journals the swap and never leaves the exe missing
Frame Home
- Seats turn you to face their way
- Draw batching (Hand Tutorials up to ~20% less GPU time), cut-out EQUAL pass,
late head-pose read before submit
- Proper queue-family hand-over to the compositor layer; layer descriptor
generations and seqlocked slots; structural SPIR-V check
- Fixed: hangs/crashes on damaged .fenv files and shaders, render-pass
validation error, sync hazard in the foveation smoothing pass, unverified
update downloads, half-done installs
Tests: tests_loco/env_share/spv_check wired into CMake (FRAME_TESTS) and CI.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VsaXGU27gsrXjDoFtyFJP9
v<VERSION>.<commits on main> (VERSION starts at 0.1), with release notes since the
previous numbered release, marked as GitHub's latest release; only when no build
failed, and a re-run leaves an existing one alone. The rolling "latest" pre-release
stays: installed Studios and headsets update from it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Those targets still build locally with scripts/build-studio.sh; releases now carry
Windows x64/arm64, Linux x64/arm64 and macOS arm64. Studio's updater already skips a
release with no file for its computer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- CI installs libdeflate-dev and CMake prefers its static library: APK homes
unpack as fast as with the headset-built programs, with no new dependency.
- build-frame-home.sh --ci fails when a headset program needs a library
beyond libc/libm/libdl/libpthread/libstdc++/libgcc_s.
- Studio's CMake requires a complete payload only in CI (or with
FRAME_HOME_REQUIRE_PAYLOAD); a developer build without one warns, leaves out
frame/, and Install on Steam Frame says the headset files are missing.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Also add title and description to actions
Move the FrameHome build-info.txt artifact to the build stage,
since it's not needed for the release.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Build Frame Home payload in CI
Build the ARM64 headset payload against the glibc 2.39 baseline, validate its ABI,
and pass the generated artifact to Studio packaging.
Add provenance attestations and document CI and local build modes.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The committed frame/payload still had Frame Home from Oct 21, which opens baked
scenes up to v13, while Studio has saved v14 since wall spots were removed: every
environment saved and sent from a release failed on the headset with "baked scene
from a different Frame Studio version".
- frame/payload: frame-home and fenv-tool rebuilt on the Frame from this source
(byte-identical to what is installed there now).
- frame/payload/SOURCE + scripts/frame-payload.sh: records the source the headset
programs were built from; CI checks it in the installer job and in the release
job, so nothing is published beside an outdated headset build.
- fenv-tool version prints the newest baked scene it opens; Studio asks before
Send to Frame and Calculate Best Settings and says to update Frame Home instead
of sending a file the headset can't open.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CI stamps every Studio build with its commit (FRAME_BUILD) and the
release gets latest.json: the commit, Frame Home's identity (a hash of
the headset programs in frame/payload) and the files in the release.
Frame Studio (studio/updater.h): checks a few seconds after start and
every 6 hours (Help > Check for Updates any time). A newer build shows
"Update Available" in the top bar; Download and Install fetches this
computer's build with the system's curl, unpacks it with tar, and swaps
each item in (the old one renamed aside first, so the running copy
keeps working and a failure rolls everything back). Restart Now closes
through the normal unsaved-changes prompt, then starts the new copy;
the next start deletes what was set aside. Local builds never update.
New platform calls: systemTool (System32's curl/tar on Windows) and
launch.
Frame Home (src/switcher.cpp): on the Steam Frame the Environments
panel checks a minute after it starts and every 6 hours. When the
installed programs' hash isn't the release's, "Update Frame Home"
shows beside Restart Frame Home; it downloads FrameHome-installer.zip
and runs its install.sh in its own session (which restarts Frame Home
and the panel), and the new panel says "Frame Home is updated". Also
frame-switcher --check-update / --update from a terminal.
frame/payload: frame-switcher rebuilt on the Steam Frame with this.
Tested: Studio's full cycle (check, download, unpack, swap, relaunch,
cleanup) and its rollback against a local fake release on Windows; the
headset's check and update against a fake release on the Frame (old
panel and Frame Home replaced, then up to date); Linux compile of
Studio; Studio --selftest unchanged (98 passed, same 6 known fails).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The macOS x64 job used the macos-13 runner, which GitHub retired in
December 2025, so it sat in the queue until a newer run cancelled it and
no Intel Mac build was ever made. macos-15-intel is GitHub's remaining
Intel Mac runner (supported until August 2027). It stays a native Intel
build, since the MoltenVK bundled from Homebrew is the runner's own arch.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every Windows job and Linux x86 were failing; reproduced each locally (MSVC 18
x64/x86, gcc -m32) and fixed:
- studio.cpp: thumbnail buffers were named `small`, which Windows' rpcndr.h
#defines to `char`, so MSVC saw `std::vector<u8> char(...)`. Renamed to
`scaled`. (All three Windows builds.)
- 32-bit x86: astcenc's SSE4.1 code calls __builtin_popcountll on 32-bit
MSVC, which doesn't exist; 32-bit builds now use astcenc's plain backend.
- opus defaulted to the DLL C runtime while the app links the static one;
x86 MSVC can't link that mix (__except_handler4_common). OPUS_STATIC_RUNTIME.
- 32-bit gcc/clang: turn on SSE2 (-msse2 -mfpmath=sse) as MSVC does; rtm
(under ACL) uses SSE intrinsics on any x86.
- CI Linux x86: install the i386 X11 dev packages; GLFW couldn't find a
32-bit libX11 to link.
The x86 and x64 Windows builds pass the same --selftest checks (97/104; the
7 failures are pre-existing and identical on both).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The release job depended on every build job, including the macOS Intel
runner, which can sit in GitHub's hosted queue for hours. Because a new
push cancels the in-progress run (concurrency: cancel-in-progress) and a
cancelled run skips Publish (if: !cancelled()), no run ever lived long
enough to create the "latest" release. Drop macOS from the release job's
needs so it publishes once Linux, Windows and the installer are done;
both Mac builds still run and are attached whenever they finish in time.
Also add timeout-minutes to every job so nothing can hang on GitHub's
6-hour default again.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Deletes pc-streaming/ (the experimental Windows D3D11 compositor proxy that
tried to make a home SteamVR's environment on a tethered PC, with its .def,
installer .ps1/.bat and notes) and everything that pointed at its files:
- CMakeLists: the frame-home-d3d11 proxy target.
- build-studio.sh: the Windows pc/ staging and the d3d11.dll build step.
- CI: the pc-home-windows job and the Windows Studio job's download/staging
of FrameHome-PC-windows-x64.
- Studio: the Windows branch of the "This PC" installer (it ran the deleted
.ps1); the feature is now Linux-only, where it installs the Vulkan layer.
- README and docs: the Windows PC download row, the PC-streaming highlight,
and the dead Frame-Home-on-a-PC / pc-steamvr.md links.
FRAME_HOME_PC and the runtime OpenVR/Vulkan loader stay, so Frame Home still
builds for a PC; only the pc-streaming folder and its wiring are gone. The
Linux PC layer (layer/) and its install path are untouched.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The PC compositor-layer work (the Direct3D 11 proxy, its installer, its notes) now lives in pc-streaming/, clearly
separate and marked experimental, so the main project is the Steam Frame build and the fixes that help it. The PC
layer can't change the Steam Frame's home (the Steam Frame renders it on the headset), and this keeps it from
crowding the Steam Frame release while preserving it for a tethered PC headset.
The shared Windows renderer support (src/, behind #ifdef _WIN32 / FRAME_HOME_PC) stays put: it only compiles into a
PC build and never touches the Steam Frame build. Build and README references updated to the new paths.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
On the Steam Frame a layer inside SteamVR's compositor draws the home where it would draw Aurora, so the home is the
environment itself: at boot, during game loads, behind the Steam menu, with the controllers and passthrough, and it
steps aside for a game the instant it opens. On a PC this was faked with SteamVR's home-app slot and a flat 360 photo
in the gaps, which launched and handed off like an app and showed a picture, not the live home. This does it properly
on any PC that runs SteamVR, the Frame's way:
- Windows: the compositor is Direct3D 11, so the layer is a proxy d3d11.dll beside the compositor (layer/
frame_home_layer_d3d11.cpp, built from the .def that forwards every other export to the real d3d11.dll, kept as
fh_d3d11real.dll). It wraps the compositor's device, finds Aurora's draws by their shader bytecode and draws the
home over the sky, leaving the floor and stars off; everything else passes straight through. Pure pass-through in
any process that isn't vrcompositor.
- The home's frames cross from Frame Home (Vulkan) to the compositor (D3D11): the layer owns kSlots shared textures
and hands Frame Home their NT handles over a named pipe; Frame Home imports them (VK_KHR_external_memory_win32) and
renders into them. No cross-API lock — a slot is published only once the GPU has finished it and the four rotate,
as on Linux. The shared State stays Frame Home's.
- The Environments panel runs frame-home --system and keeps it alive (one at a time, a pid file across panel
restarts), the same systemEnv path as the Frame. The installer places/removes the proxy and marks the layer with a
root/layer folder, in place of the old home-app registration and background pictures.
- Safe like the Vulkan layer: no home, or one stale over half a second, and the compositor draws Aurora as usual;
the layer turns itself off after two unhealthy compositor starts, and root/layer/off turns it off by hand.
Linux keeps its Vulkan layer (unchanged). Verified without a headset on the null driver: the proxy loads and wraps
the compositor without crashing, recognises Aurora's shaders, and the frame hand-over completes (Frame Home connects,
imports the textures, renders). The compositor only draws the environment while presenting to a headset, so the final
on-headset image is the one step the null driver can't exercise.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- src/home_platform.h: what Frame Home and the panel need from the system (paths, finding and stopping each
other, running a tool, restarting, priorities) for SteamOS, Windows and Linux PCs. On a PC the environments are
Frame Studio's My Environments; Frame Home's own files in %LOCALAPPDATA%\Frame Home (Windows).
- src/openvr_loader.cpp: a PC build finds SteamVR's own OpenVR library at run time (openvrpaths.vrpath), so it runs
on any PC with SteamVR; Vulkan through volk. CMake: FRAME_HOME_PC (default on Windows and x86-64 Linux); the Steam
Frame build is unchanged.
- Windows: Frame Home is SteamVR's home app; SteamVR's classic environment shows a 360-degree picture of the current
home from its spawn (frame-home --panorama --spawn, made by the panel when the home changes) instead of Aurora
while Frame Home starts. Linux PCs: the Steam Frame's compositor layer, as on the headset.
- frame/pc: install-frame-home-pc.ps1 (+ .bat): online through SteamVR's API or offline in its config files; the
SteamVR settings it changes are saved and restored exactly on -Uninstall (tested in a sandbox both ways).
frame-switcher --uninstall. Studio: Properties > Headset > This PC installs it from pc/ beside Studio.
- Packaging and CI: pc/ in the Windows x64 and Linux x64 Studio downloads; FrameHome-PC-windows-x64.zip.
- Thumbnails come from where Frame Home starts you (the first spawn, eyes 1.6 m up): Studio's saves and the
panel's (frame-home --snapshot --spawn).
- docs/pc-steamvr.md.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- LICENSE: GNU Affero General Public License v3 (as the author's MetaDB),
shipped in every package; third_party/qhe/LICENSE.md keeps Quest Home
Editor's MIT terms for the code that started there
- Install on Steam Frame lives in the Inspector's Headset tab (no floating
window); FS_INSPECTOR_TAB=<tab> starts Studio on a tab
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- a newer push to the same branch cancels the run it replaces
- the Latest build pre-release gets every build that worked; a v* tag needs all
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Frame Studio now builds for Windows (x64, x86, ARM64), Linux (x64, x86, ARM64)
and macOS (Apple Silicon, Intel):
- studio/platform.h with Win32 and POSIX implementations (dialogs through
tinyfiledialogs on Linux/macOS), a GLFW window beside the Win32 one, and a
platform-neutral frame pacer
- MoltenVK support in the renderer (portability enumeration) and bundled in
the macOS app
- 32-bit builds: large-address-aware, LZMA packing within a 32-bit address space
- unaligned file reads in the loaders go through loadUnaligned (no UB)
- scripts/build-studio.sh, studio/build_windows.bat [x64|x86|arm64],
cmake/llvm-mingw.cmake, and a GitHub Actions workflow building every target
Frame Home installs without Studio: frame/install-frame-home.{sh,ps1} and
"Install Frame Home.bat" (packaged as FrameHome-installer.zip).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
