
Scan Your Own Reality: Sourcing Free, High-Resolution 3D Models for VAMS/SDM Demos with a LiDAR Phone
How a free smartphone app and a Rocketdyne H-1 rocket engine solved one of the most annoying problems in building spatial-data proofs of concept.
The problem: good 3D models are hard to get for free
If you have ever stood up a proof of concept or demo environment for Visual Asset Management System (VAMS) — the AWS open-source solution — or a Spatial Data Management (SDM) solution, you already know the quiet bottleneck: content.
The platform is the easy part. The hard part is finding 3D models that are:
- High resolution — a flat, low-poly placeholder undermines the whole point of a spatial demo.
- Freely usable — most high-quality models in online marketplaces come with licensing and IP strings attached that you do not want anywhere near a customer-facing POC.
- The right kind of subject — free libraries are full of game props and furniture, but genuinely useful industrial and mechanical assets (pumps, engines, valves, machinery) are scarce, expensive, or locked behind restrictive licenses.
So you end up either paying for models, compromising on fidelity, or burning hours hunting for something that is both good and license-clean. None of those are great when you just want to show what the platform can do.
There is a better option, and it fits in your pocket.
The idea: scan real objects with a LiDAR phone
Recent high-end smartphones ship with a built-in LiDAR depth sensor — the same class of sensor used for depth-aware photography and augmented reality. Paired with the right app, that sensor turns your phone into a capable, pocket-sized 3D scanner.
The app I use is Scaniverse — it is free, and critically, it does the entire job on the device:
- It drives the phone's LiDAR and cameras to capture the object.
- It reconstructs a textured 3D mesh on the phone itself — no desktop software, no cloud processing step.
- It exports directly to standard formats, including
.glb, which is exactly what you want for a web-based VAMS/SDM viewer.
That is the whole toolchain. A free app, a phone you probably already have, and a few minutes of walking around an object. No Blender, no CloudCompare, no photogrammetry farm.
A quick note on tooling: I used Scaniverse, but it is not the only option. Several other LiDAR capture apps follow the same on-device scan-and-export model and can produce comparable results — so treat the app as a choice, not a requirement. The workflow and the end result (a textured mesh you can export to
.glb) are what matter; use whichever capture app you prefer or already have installed.Why self-scanned models solve the licensing problem
Here is the part that makes this more than a neat trick: when you scan an object yourself, you created the model. You are not downloading someone else's asset and hoping the license permits your use — you captured it, so there is no third-party IP riding along into your demo environment.
That said, "I scanned it" is not a free pass to scan anything, anywhere. Respect the usual boundaries:
- Get permission for the location. Scanning on private property or at a facility means asking first.
- Avoid proprietary or sensitive hardware unless you have explicit clearance to capture it.
- Be mindful of what is in frame — people, badges, documents, and anything you would not want baked into a texture.
For public, display, or decommissioned objects you have permission to capture, this is a clean, owned source of demo content.
The workflow, start to finish
The beauty of a Scaniverse-only flow is how little there is to it. Here is the process I follow.
1. Pick a good subject. The best demo subjects are physically interesting — lots of surface detail, mechanical complexity, and texture. Smooth, featureless, or highly reflective objects are harder. Something matte with recognizable geometry scans beautifully.
2. Set up the capture. Even, diffuse lighting is your friend — harsh shadows and bright glare confuse the reconstruction. Make sure you can physically walk all the way around the object (or close to it).
3. Orbit the object in passes. Move the phone slowly and steadily, keeping the subject centered, and make multiple orbit passes at different heights — low, eye-level, and high. The goal is to give the sensor a look at every surface from several angles. Pay special attention to occluded areas — undersides, recesses, and anything tucked behind another part — because whatever the sensor never sees becomes a hole or a guess.
4. Let Scaniverse reconstruct. When you finish capturing, Scaniverse processes the scan into a textured mesh right on the device. You can rotate and inspect the result immediately and decide whether to keep it or rescan a weak area.
5. Export to
.glb. Once you are happy, export. Scaniverse offers several formats — I export .glb because it bundles geometry and textures into a single file and is the native language of web 3D viewers.That
.glb is now ready to drop into your VAMS/SDM environment. No cleanup stage required.The result: a rocket motor, captured by a phone
Here is a real example. This is a Rocketdyne H-1 rocket engine on display at NASA's Johnson Space Center in Houston — the engine that powered the first stage of the Saturn I and Saturn IB launch vehicles. I scanned it, exported it as
NASA-Rocket-Motor-v1.glb, and ingested it straight into a VAMS/SDM environment, where it renders in the browser.About the subject: The H-1 is a liquid-fuel engine built by the Rocketdyne Division of Rockwell International, burning RP-1 (kerosene) and liquid oxygen. Eight of them clustered together powered the first stage of the Saturn I and Saturn IB — the launch vehicles that paved the way for the Saturn V and Apollo. The design traces back to the Jupiter missile engine, with development starting in 1958 under what was originally the Juno V program. The later variant put out roughly 188,000 pounds of thrust from an engine about 100 inches long and weighing some 1,800 pounds — a dense, intricate mechanical subject, and exactly the kind of thing that makes a compelling spatial demo. (Background drawn from the Smithsonian National Air and Space Museum.)
A wide shot is impressive, but the real test is whether the detail survives up close. It does.
The materials are just as convincing as the geometry — and this view also shows where the technique has limits.
For a free scan captured by walking around an object with a phone, the result is suitable for a demo or proof of concept.
Honest limitations — and how to work around them
This technique works well, but it has limits. Setting expectations up front keeps your demo credible:
- Thin, shiny, and reflective features struggle. Cables, thin rods, polished metal, and glass tend to come out as webbed or stringy artifacts (visible on the linkages in the nozzle shot above). The sensor simply has a hard time with surfaces that are too narrow to resolve or that scatter light unpredictably.
- Occluded geometry becomes guesswork. Anything the sensor never saw gets filled in or left as a hole.
- Ground-plane bleed. Scanning an object sitting on the floor usually drags some of the surrounding ground into the mesh around the base.
Mitigations are mostly about capture discipline, not post-processing:
- Make more orbit passes, especially around problem areas, and get the phone closer to thin features so the sensor gets more data on them.
- Improve and even out the lighting to reduce glare on reflective surfaces.
- Rescan weak spots on the spot — Scaniverse shows you the result immediately, so you can catch gaps before you leave.
- Set the right bar. This is for POC and demo content, not metrology or engineering-grade reference. For showing what a spatial platform can do, it is more than good enough.
Getting it into VAMS/SDM
This is where the
.glb choice pays off. The browser-based viewers in Visual Asset Management System (VAMS) and Spatial Data Management (SDM) are built around web-friendly 3D, and .glb — the binary form of glTF — is the format they handle most directly: it packs geometry and textures into one self-contained file that renders in the browser with no conversion step.Getting your scan into a VAMS environment is straightforward. (If you have not stood VAMS up yet, deploy it first from the VAMS implementation guide or the source on GitHub — note the OpenSearch Serverless service-linked role prerequisite before you deploy.) Once it is running, here is the end-to-end path:
- Transfer the file off the phone. Export the scan from Scaniverse as
.glband move it to the machine you will upload from. Give it a clear, descriptive name (for example,NASA-Rocket-Motor-v1.glb). - Open VAMS and choose a database. Sign in to your VAMS web interface. Assets live inside a database (a logical container). Select an existing one or create a new database to group related assets — in the screenshots above, the engine lives under the
Demo1database. - Create a new asset. From the database, create a new asset and give it a name and short description. This is the record your
.glbwill attach to. - Upload the
.glbfile. Add the.glbas the asset's primary file — drag it onto the upload area or browse to it. VAMS stores the file and registers it against the asset. - Let processing finish. VAMS ingests the file and generates what the viewer needs (including a preview). This takes a moment for a typical scan; larger meshes take a little longer.
- Open it in the viewer. Select the asset to open the built-in 3D viewer. You can orbit, zoom, and use the preset views (Front / Top / Right / Iso) — exactly the views shown in the screenshots earlier. If it renders and navigates smoothly, you are done.
A couple of practical notes:
.glbis the smoothest path, but not the only one. Scaniverse can also export.objand.ply. Those are useful if your pipeline needs them, but for direct in-browser viewing.glbkeeps geometry and textures together in a single file and avoids missing-texture surprises.- Watch the file size. A dense scan can produce a large mesh. If uploads are slow or the viewer feels heavy, decimating the mesh (reducing polygon count) before upload keeps things responsive while still looking great in a demo.
That is the whole trip: scan with a phone, export a
.glb, and a few clicks later it is a navigable 3D asset in your VAMS/SDM demo environment — as the rocket engine screenshots show.Build your own free, owned asset library
The next time you need content for a VAMS or SDM proof of concept, look around you before you open a model marketplace. That interesting piece of equipment on the shop floor, the display engine in a lobby, the decommissioned hardware nobody is using — with a LiDAR phone and a free app, any of them can become a high-resolution, license-clean, demo-ready
.glb in minutes.Scan a few, and you build up a practical resource: a library of high-fidelity 3D assets that are entirely your own, cost nothing, and are ready to drop straight into your spatial-data demos.
Go scan something.
Visual Asset Management System (VAMS) is published by AWS as an open-source solution. See the source and implementation guide on GitHub: https://github.com/awslabs/visual-asset-management-system
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations



Loading article