A photoreal scan of a substation, a port berth or a training facility is not just a pretty model. It is a detailed record of a site someone has a duty to protect. When that scan becomes a simulation scene for training robots, the question a security team asks first is simple: where does the data go?
The honest answer is that the Real2Sim workflow can keep site data in Australia from capture to training. It does not do that by default, and it does not make anyone compliant on its own. Here is what the workflow allows and what you have to set up.
The three stages, all onshore
Capture. A handheld scanner such as the SHARE C1 Pro records lidar, poses and photos to its own storage. Getting the job off the unit is a copy of the raw folder to a workstation. The scan itself needs no internet. RTK corrections over NTRIP do, so either scan without RTK or treat the corrections link as an online step.
Processing. There are two onshore routes for SHARE data. You can run SHARE's Point Cloud Studio yourself, which builds the point cloud and the Gaussian splat on a local NVIDIA GPU. Or we process it for you: our SHARE processing runs in house, in AWS's Sydney region only. NVIDIA's 3DGRUT and NuRec tools that convert the splat into an OpenUSD scene are open source and run on your own Linux machine. Our Real2Sim pipeline post walks through those steps.
Training. Isaac Sim installs on a local workstation, and NVIDIA states that its Nucleus, Cache and Hub services are not needed. Isaac Lab and the COMPASS navigation code run on the same machine or an onshore cluster.
Put those together and the scan, the reconstruction and the trained policy can all sit on machines in an Australian building.
Where the tools still reach online
This is the part vendor slides leave out. None of these send your scan anywhere by themselves, but each is an online step your security team should know about.
| Tool | Online step | What to do |
|---|---|---|
| SHARE C1 Pro with RTK | NTRIP corrections during capture | Scan without RTK, or allow only the corrections link from the scanner |
| SHARE Point Cloud Studio | Account login before 3DGS processing | Ask SHARE what the login transmits; run it on a segmented network |
| Isaac Sim | Licence and privacy consent prompts, an optional Omniverse login, anonymous usage data | Switch the usage data off before any real scan is loaded |
| Isaac Lab | Robot and scene assets download from cloud storage | Mirror the assets locally and point Isaac Lab at the mirror |
| NuRec and COMPASS | Containers and model weights pulled from GitHub and Hugging Face with a token | Pull once on a connected machine, move them across, then run offline |
The pattern is the same for each: download the tools on a connected machine, then do the work with site data on a machine that does not need to call out. That is a normal arrangement for air gapped engineering networks. Test each tool offline before the first real scan, starting with the Studio login.
What this does and does not prove
A workflow that keeps data onshore is a precondition, not a certificate. We are not claiming that this setup meets any particular defence, government or critical infrastructure framework, and you should be wary of anyone who claims that for a toolchain on its own. Those frameworks cover your people, facilities, networks and processes as much as the software.
What the workflow gives your security team is something they can assess: every stage named, every online step listed, and no stage that requires site data to be uploaded to a service outside your control.
Questions to settle before the first scan
- Who owns the scan, the splat and the trained policy, and where is each stored?
- Will processing happen on your hardware, or on a contractor's? If a contractor's, where is it and who can access it?
- Which machines are allowed to touch the internet, and for what?
- Is anonymous usage data switched off on every machine that opens site data?
- Will anything be shared in a browser viewer? If so, where is that viewer hosted?
Those answers belong in the project plan before anyone switches a scanner on.
How we help
We supply the scanners and set up capture for splat quality. Our processing runs in house, in AWS's Sydney region. If you would rather run SHARE's software yourself, we help you specify a workstation for it and the NVIDIA steps, and help you put the login question to SHARE. If your project has data rules, bring them to the first conversation and we will build the capture plan around them.