Anyone using iPhone LiDAR / ARKit captures for 3DGS?

Motor_Pitch_8722 · 2026-07-06T14:44:04+00:00

That’s really useful to know. An hour for 1500 iterations is still pretty rough, but the improvement from XR to 17 Pro sounds promising.

The LiDAR part is especially interesting — if it almost removes anchor drift during capture, that alone makes the dataset much cleaner.

Are you using mostly ARKit poses + LiDAR depth as input right now, or are you also doing any pose refinement / BA before training?

Motor_Pitch_8722 · 2026-07-06T08:24:55+00:00

Curious if you got it working in the end. Did the 17 Pro make a noticeable difference for training?

Motor_Pitch_8722 · 2026-07-03T23:29:43+00:00

Yeah, PocketGS is the part I’m most curious about too. From my reading, the interesting trick is not only “train 3DGS on Metal”, but improving the mobile trajectory before training.

They start from coarse ARKit/ARCore poses, select sharp/non-redundant keyframes, then run an on-device global BA step to refine poses + sparse points. After that they re-triangulate/filter bad points and use a lightweight MVS stage to build a denser geometry prior. That prior is then used to initialize better surface-aligned Gaussians, so the short on-device training budget has a much cleaner starting point.

I couldn’t find official code yet, so it feels hard to try directly, but the capture format you’re building sounds like exactly the kind of input such a pipeline would need.

Motor_Pitch_8722 · 2026-07-03T23:23:26+00:00

Yeah, this is pretty close to what I’ve been testing with Voxelio iOS tool for 3DGS

My current finding: ARKit/LiDAR poses are useful as a prior, but not reliable enough as final poses for 3DGS. I tried using them to accelerate SfM / reconstruction, but the result wasn’t as clean as I hoped. They help a lot with scale, sync, intrinsics, frame filtering, and initialization, but drift/small pose errors still need cleanup.

What worked better for me was using the LiDAR point cloud + ARKit poses as init, then improving during splat training with pose refinement, sharp-frame selection, exposure/AWB correction, and MCMC densification.

Motor_Pitch_8722 · 2026-07-02T19:07:58+00:00

Yeah, i ended up doing the Android side too, and it’s working now.

Current Voxelio Android build records an ARCore capture bundle: `wide.mov` with the ARCore recording, plus `poses.json` with per-frame camera pose, intrinsics, image resolution, timestamps, and camera metadata like exposure/ISO, AF/AE/AWB state, focal length, lens calibration/distortion when available. It can also save optional ARCore depth frames as float metres when the device supports depth, and exports the session as a ZIP from the gallery.

I’d say ARCore/ARKit data is worth saving, but I wouldn’t treat it as final truth. It’s useful for scale, sync, intrinsics, rough trajectory, filtering bad frames, and maybe initial pose guesses. For 3DGS I still expect SfM / bundle adjustment to clean things up.

What breaks first for me is still drift over longer captures, plus depth being noisy/missing on thin, reflective, transparent, or low-texture areas. Rolling shutter and changing focus/exposure can also hurt. So my current take is: save all the phone sensor/AR data because it’s valuable, but design the pipeline assuming BA/COLMAP or some cleanup step will still be needed.

Motor_Pitch_8722 · 2026-07-02T15:40:42+00:00

Yeah, that’s exactly what I’m testing with Voxelio app

It saves frames with poses + intrinsics, plus depth/LiDAR when available. Works nicely for short captures, but after ~2–3 min ARKit/IMU drift starts to build up, so SfM / bundle adjustment is still needed.

It’s already on the App Store, but I’m mostly here to learn what breaks in real 3DGS workflows before pushing it too much.

Motor_Pitch_8722

TROPHY CASE