Who owns your 3D data?

At first glance a 3D model looks like a single file or an embedded viewer. In practice, though, a digital object consists of much more: the original footage, project information, metadata, processing states, export files and the presentation layer. Whoever holds only a link to an externally hosted viewer does not automatically control the digital object itself.

Precisely because 3D data is gaining weight in product communication, museums, documentation, photography and the crafts, the question of ownership becomes practical. It concerns more than copyright or data protection. It also concerns whether raw data survives, whether results can be exported into open formats, whether a project outlives a change of provider, and whether your own costing stays stable as volumes grow. DFX SplatCore positions itself explicitly here as a local application without cloud compulsion, with open exports such as GLB, PLY and HTML output, and with the claim that the export stays with the user.[The product twin: e-commerce]

A model is more than a link

In many 3D workflows a project appears to end with a web viewer. The model is embedded, can be turned, looks convincing and works on a product page or in an exhibition. But that visible surface is only the last layer.

A robust 3D asset comprises at least the original photos or video, the link to the object, details of the shoot, metadata, project files, export formats and an independent way of presenting it. Whoever does not hold or cannot export these layers is, in an emergency, dependent on a platform, a service provider or a single hosting model. Practical guides on data sovereignty in virtual tours put the same problem this way: a hosted link is not identical with owning the underlying raw data, panoramas or reuse rights.^[1]

The real question is therefore not: Can I look at my model? But: Can I back it up, migrate it, reprocess it, document it and reuse it independently?

Three levels of control

The ownership question for 3D data has at least three levels, which projects often mix up.

A company can be legally entitled to use a model and still remain technically dependent on a provider. Conversely, a studio can hold local files but, without a clean chain of rights or a client agreement, cannot dispose of them freely. Only when all three levels fit together does real data sovereignty arise.

The wrong cloud debate

The most important distinction is not "cloud good" or "cloud bad". Cloud services can make sense in many scenarios: for quick test runs, public campaigns, joint review or distributed collaboration.

It becomes problematic where the cloud appears as an invisible default setting, without data paths, export options and cost consequences being deliberately assessed. With unpublished products, prototypes, client commissions, cultural assets, damage documentation, collection objects or confidential industrial installations, the question of where original data goes is no side issue.

Data sovereignty therefore does not begin with the privacy policy, but with the decision about where the first original shot is sent. Anyone uploading images should know beforehand which files are stored, how long they stay there, under which jurisdiction they are processed, whether they may be used for product improvement or training, and whether all relevant results stay fully exportable.

Raw data is the actual substance

The most important layer of a digital object is neither the finest screenshots nor the viewer. It is the raw data.

Original images or original video are the basis of any later reprocessing. They enable quality checks, alternative reconstructions, future export paths and the evidence of what a digital representation rests on. If this layer is lost, often only the last surface remains.

In e-commerce this basis is becoming more important. Convincing but synthetic product depictions are appearing there in growing numbers. Whoever works from real footage can build a traceable image basis for a digital product model instead. That is not automatically a metric digital twin, and no guarantee against every misreading. But it is an essential difference from purely generated images that have no direct relation to a physically captured object. The e-commerce text on the DFX website puts this difference clearly: in a growing flood of AI-generated product images, the real thing becomes the value promise itself, and the all-round consistency of a genuinely photographed product cannot simply be prompted into existence.[The product twin: e-commerce]

Open formats are an insurance policy

A digital object is only as independent as its export paths.

If a model exists solely inside a proprietary viewer, its usefulness stays bound to that one system. Open, widely used formats do not solve every long-term problem, but they reduce the risk of a dead end. DFX SplatCore names exactly this as a central architectural principle: instead of locking users in a proprietary cage, the application exports GLB for web, engines and DCC tools, as well as PLY and SPLAT for further use; on top of that comes an HTML output for standalone web embedding without external servers or API calls.[The product twin: e-commerce]

In practice this separation makes sense:

The simple rule is: if only the presentation survives, most of the digital object is missing.

Who owns the workflow?

Ownership of data is always ownership of the process too.

That becomes particularly clear when it is not a single object but a series. A photographer with an established studio setup, a dealer with two hundred articles, a museum with a pilot series of depot objects or an agency with recurring clients needs no one-off effect but a repeatable routine. For e-commerce, DFX describes exactly this model: the rig stays in place, light, distance, camera settings and background are frozen, and after that every article runs through the same rhythm of placing, circling, assigning and backing up.[The product twin: e-commerce]

At that moment the decisive cost question shifts. It is not the first 3D model that settles the economics, but the two hundredth. Whoever remains dependent for every asset on upload, tokens, platform rules or additional retrieval costs owns the workflow only in part. Whoever works on local hardware with standardised shooting and export paths can plan their cost structure better.

That does not mean local processing is free. Hardware costs purchase, maintenance, power, storage, backup and, where necessary, replacement. The difference lies in the structure: platform or token costs can keep growing with every additional asset, every computation or every retrieval, while a local production environment is tied more to initial investment, utilisation and working time. Precisely this predictability is highlighted on the DFX website as the advantage of a single licence, local processing and "zero token costs".[The product twin: e-commerce]

Local processing as technical sovereignty

Local processing is no magical guarantee of security. Your own computer also needs access control, clean backups, clear folder structures, updates and disciplined project filing.

But it creates a different starting position: original images, project states and export files do not automatically become part of a foreign platform’s logic. DFX SplatCore is described as an application that runs entirely locally; the website stresses that data, models and workflows do not leave your own system and that there is no SaaS dependency or compulsory cloud.[The product twin: e-commerce]

This form of technical sovereignty is relevant in several fields. For museums, archives and archaeology it concerns sensitive collection data, rights and long-term archiving. For trade and industry, unpublished products, collections and prototypes. For photographers and agencies, client material, raw images and repeatable production. For crafts and workshops, one-off pieces, constructions and details of the work.

Local processing never replaces legal and organisational responsibility. But it is an infrastructure decision that makes later control possible in the first place.

Machine readability is not ownership

Another misunderstanding concerns visibility online.

Structured data, clean product information and machine-readable contexts can improve how technically reusable a digital asset is. The DFX e-commerce page stresses that product information is embedded into the export page and that such data becomes relevant in an increasingly AI-mediated web.[The product twin: e-commerce]

That is right and important. But it must not be confused with ownership. An asset can be well indexable and technically readable and still remain inside a closed platform model. Visibility is valuable. Ownership arises only when raw data, export files, metadata and presentation paths are all under your own control together.

Different audiences see the problem differently

The ownership question presents itself differently in every sector, but it disappears nowhere.

The question "Who owns your 3D data?" sounds abstract. In truth it is highly concrete: who can export, migrate, recompute, archive, publish or carry on working after a change of provider?

The practical minimum standard

Before a project begins, four questions should be answered.

First: where is the original data? Second: which formats can be exported in full? Third: who may publish or pass on the model, the images and the presentation? Fourth: how does the whole thing stay accessible after a change of provider, a change of hardware or the end of a contract?

Whoever cannot answer these questions often owns only the visible surface of a digital object. Whoever can answer them is building a holding.

A digital object does not belong to someone because it appears in a viewer. It belongs to whoever controls its original data, its open export files, its metadata and its path to independent presentation — even at the two hundredth model.

Sources

1. [1] fotoestate — https://fotoestate.de/praxiswissen/datenhoheit-rundgaenge