You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SplatKitView exposes setWalkVelocity, look and setCameraPose. Nothing addresses an anchor, and nothing says that programmatic camera paths already work.
The surface should follow the idiom the other subsystems use: world, collider and policy are immutable transactions that native re-validates and reports back as an effective state.
A camera prop: an immutable transaction carrying a revision, a mode, an anchor, a radius, an azimuth, an elevation and the animated-orbit rate. Validated structurally in contracts.ts the way validateWorldRequest and validateRenderOptions are, with a CameraMode const object instead of bare string literals.
Commands for the per-frame path: orbit, dolly, setAnchor, focus.
An onCameraEvent reporting the effective camera state, the way onPolicyEvent reports the effective policy.
Both adapters: SplatKitViewComponentView.mm and SplatKitView.kt.
A documented recipe for worklet-driven camera paths. setCameraPose is a Fabric command, so dispatchCommand from a Reanimated worklet with useAnimatedRef already drives the camera on the UI thread; the repo never says so. Optionally a small react-native-splatkit/reanimated entry point with Reanimated as an optional peer dependency, so the core package stays dependency free and unpinned from Reanimated majors.
The example's flythrough moves from requestAnimationFrame (apps/react-native/App.tsx:301) to the worklet path, and an example screen orbits a loaded world with the new prop.
Depends on the engine-side orbit camera.
Why the engine should own it
The engine owns the behaviour; this issue is the host surface for it, plus host-side docs. The transaction shape is what keeps native authoritative: the host asks, native re-validates and answers with what it actually applied.
The Reanimated part is deliberately host side and deliberately optional. It is recorded here so the camera work does not quietly absorb a Reanimated dependency into the core package.
How it would be proven
The contracts tests that keep the codegen spec, both adapters and the TypeScript constants spelling the same values, extended to the camera transaction and event. The example's flythrough holds its frame rate with the JS thread deliberately blocked, which the current requestAnimationFrame version cannot.
What is missing
SplatKitViewexposessetWalkVelocity,lookandsetCameraPose. Nothing addresses an anchor, and nothing says that programmatic camera paths already work.The surface should follow the idiom the other subsystems use:
world,colliderandpolicyare immutable transactions that native re-validates and reports back as an effective state.cameraprop: an immutable transaction carrying a revision, a mode, an anchor, a radius, an azimuth, an elevation and the animated-orbit rate. Validated structurally incontracts.tsthe wayvalidateWorldRequestandvalidateRenderOptionsare, with aCameraModeconst object instead of bare string literals.orbit,dolly,setAnchor,focus.onCameraEventreporting the effective camera state, the wayonPolicyEventreports the effective policy.SplatKitViewComponentView.mmandSplatKitView.kt.setCameraPoseis a Fabric command, sodispatchCommandfrom a Reanimated worklet withuseAnimatedRefalready drives the camera on the UI thread; the repo never says so. Optionally a smallreact-native-splatkit/reanimatedentry point with Reanimated as an optional peer dependency, so the core package stays dependency free and unpinned from Reanimated majors.requestAnimationFrame(apps/react-native/App.tsx:301) to the worklet path, and an example screen orbits a loaded world with the new prop.Depends on the engine-side orbit camera.
Why the engine should own it
The engine owns the behaviour; this issue is the host surface for it, plus host-side docs. The transaction shape is what keeps native authoritative: the host asks, native re-validates and answers with what it actually applied.
The Reanimated part is deliberately host side and deliberately optional. It is recorded here so the camera work does not quietly absorb a Reanimated dependency into the core package.
How it would be proven
The contracts tests that keep the codegen spec, both adapters and the TypeScript constants spelling the same values, extended to the camera transaction and event. The example's flythrough holds its frame rate with the JS thread deliberately blocked, which the current
requestAnimationFrameversion cannot.