Build and publish a scene

Everything you have built so far is a draft. It is saved, but nobody outside Scenes Studio can see it.

This step turns it into something operators use, in three distinct acts. You compose the screen, you commit a revision to freeze it, and you publish to say which frozen version is the live one. Keeping those three apart is what lets you keep editing a screen that people are watching.

Create a scene and place the entity

A scene is a screen built around your site laid out in space. Create one and add your entity to it.

Now give it a position. Scene coordinates are in metres, with Y pointing up, so a value like (0, 0, 0) puts the entity at the project’s origin — fine for one entity.

You do not need a 3D model. An entity with no asset falls back to a simple shape, which is enough to see it and click it. Importing real geometry is a later concern, and the scene works the same way once you do.

Add a widget

Place a widget on the scene and point it at the interpretation you made in the last step.

Notice what you are not doing: you are not telling the widget which dataset to read, what unit to print, or how many decimals to show. It reads the interpretation, and the interpretation already knows. That is why the chain you built matters — the widget is the last link and the thinnest one.

The value should appear. If it does not, the reading never reached the entity; check that fanout was 1 in the last step.

Commit a revision

A commit takes everything you have authored and freezes it into an immutable snapshot, with a message describing what changed.

Commit now, with a message like First room and scene.

Committing is a restricted action. If you are told you do not have permission, ask an administrator of your organization to grant it or to commit on your behalf.

From here on, that snapshot never changes. You keep working on the draft, and the draft moves on, but the revision you just made stays exactly as it is. That is what makes a published screen stable while its author keeps editing.

One thing is deliberately not in the snapshot: the data. Datasets are operational — they keep collecting whether or not anyone is authoring — so they live outside revisions. What is frozen is the wiring that points at them. Declaring a dataset again never requires a commit; changing where its value lands does.

Publish

Committing froze a version. It did not show it to anyone.

Publish the scene, choosing the revision you just committed. This sets a pointer: this scene, in operations, means that revision.

Three consequences are worth knowing now.

• Operators only ever see published revisions. Your drafts and your other commits are invisible to them. You can leave a screen half-rebuilt and nothing in operations flickers.
• The pointer moves without a commit. Publishing a different revision later — or rolling back to an earlier one — is just moving the pointer, because it lives outside the snapshots it points at.
• You can only publish what you committed. If the scene is not in the snapshot you chose, publishing is refused and tells you to commit first. There is no way to publish a draft by accident.

---

The scene is live. Next, see it in the Viewer the way the people who use it will.