Skip to content

React Native surface for the orbit camera #6

Description

@Xget7

What is missing

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestproposalSomething the engine should do that it does not do today

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions