If the upload fails, especially when working with large files, try the following tips:

• Start the upload and avoid switching to other browser tabs or windows during the process.
• Ensure your computer does not enter sleep mode — temporarily disable sleep if necessary.
• A stable Internet connection is essential. Wi-Fi interruptions can cause uploads to fail.

File size alone is not a limitation.

You can also use a file-sharing service (supported: direct download link, Google Drive, Dropbox, Yandex Disk) and instead of uploading the archive directly to the site, simply provide a link to the file. Our platform will automatically download it from the link and start processing the project.

Easily locate the Leica database file by following the steps below:

1. Launch Cyclone REGISTER 360.
2. In project settings, specify the folder where your project is stored.
3. Open this folder in the file explorer. Inside, you should see a file named something like project_deliv_*.db.
4. After locating it, upload the database file to our platform together with your JPG panoramas to generate a virtual tour.

This file contains essential spatial data required for precise panorama placement and alignment.

A TXT file stores the position and orientation of your panoramas. Two layouts are accepted, detected automatically from the file contents:

1. Position / orientation file (Leica)

One file per panorama, named exactly like its image (for example station_01.txt alongside station_01.jpg). It contains a position and an orientation:

position = [positionX, positionY, positionZ];
orientation = [rotationW, rotationX, rotationY, rotationZ];

Here is an example:

position = [-60.2344, 30.0544, -0.185128];
orientation = [0.804644, -8.74489e-06, -1.45999e-05, 0.593758];

The orientation is a quaternion in W, X, Y, Z order. Separate each value with a comma and a space, exactly as shown.

2. iQscene scene file

A single file that lists every panorama, recognised by the word iQscene on the first line. Two header lines follow, then one line per panorama, and the list ends with a closing brace }. Each panorama line is space-separated:

"path\to\station_01.jpg" posX posY posZ axisX axisY axisZ angle

The image path is quoted, posX posY posZ is the position, and axisX axisY axisZ together with angle (in degrees) describe the rotation as an axis and an angle. Example:

iQscene ...
...
...
"C:\Project\station_01.jpg" -60.2344 30.0544 -0.1851 0 0 1 90.0
"C:\Project\station_02.jpg" -58.1021 31.7765 -0.1820 0 0 1 92.5
}

Use a dot as the decimal separator and save the file in UTF-8 encoding. These structures let the platform place and orient your panoramas correctly in 3D space.

A CSV file stores the position and orientation of each panorama. Upload it together with the equirectangular JPG panoramas — the file name in every row (without its extension) must match the corresponding image. The platform auto-detects the layout, so several variants are accepted: A few things to keep in mind:

• Column names must match exactly (they are case-sensitive); their order does not matter and any extra columns are ignored.
• qw, qx, qy, qz (and Orientation(W...Z), pano_ori_w...z) are the quaternion components in W, X, Y, Z order.
• rot_x, rot_y, rot_z (OmniSLAM) are Euler rotation angles expressed in radians.
• RIEGL and Lixel files are recognized by their name (...ImageList.csv / ...panoramicPoses.csv); the remaining layouts are detected automatically from the header row.
• Use a dot as the decimal separator and save the file in UTF-8 encoding.

Here is an example of the generic comma-separated layout:

filename,x,y,z,qw,qx,qy,qz
station_01.jpg,-60.2344,30.0544,-0.185128,0.804644,-8.74489e-06,-1.45999e-05,0.593758
station_02.jpg,-58.1021,31.7765,-0.182004,0.799120,1.02000e-05,2.31000e-05,0.601171

Cyclone REGISTER 360
The image below shows the recommended settings when exporting your project to an LGSX file:

These settings help ensure compatibility and accuracy when using the file with our platform.

A point cloud composed of multiple scan stations must be pre-processed in FARO SCENE:

• Create Scan Point Clouds for each station to improve visualization.
• Disable the Edge Artifact Filter for clearer results.
• Register all stations and organize them into a single cluster.

Once this is done, export the cluster contents as shown in the screenshots below:

This process ensures correct alignment and compatibility for uploading to our platform.

Once your project is created, you can share it in several ways — all are available on the Project settings page.

The easiest option is to set the access mode to via link. In this case, registration is not required — anyone with the link can view the project.

Ideal for sharing with clients, stakeholders, or external reviewers without requiring them to create an account.

Yes — each project can be assigned a tag that works like a folder.

Use tags to group projects by client, sub-client, or any other category that helps organize your workspace. Note that only one tag can be assigned per project, so use a clear and structured naming convention.

The Links to other projects setting allows connecting multiple independent projects within a single virtual tour.

For example, when navigating a panoramic tour, users can click a transition and be instantly taken to a different project — for example, a neighboring building, another floor, or a related location.

This feature is especially useful for large facilities or multi-site properties.

Here is a real-world example where this is implemented:
https://360-for-you.com/projects/HLxVEP0d/

Yes — we can activate a test subscription for you, valid for 2 weeks. This trial includes nearly the same features as the Pro plan and is ideal for testing large-scale projects.

If your scan file (for example, 100 GB) is already stored on Dropbox, Google Drive, or another supported platform, you can paste the download link when creating a new project. The system will automatically fetch and process the file — no manual upload required.

Yes — there are no country-based restrictions. If the website loads and works for you, you can use the service from Peru or any other location.
Feel free to try it out! You can create projects containing up to 10 setups completely free of charge.

Thank you for your interest — we greatly appreciate your questions and suggestions!

We currently handle all communication by email, as it allows us to track requests more efficiently and respond thoroughly. We are happy to continue the conversation this way and address anything you would like to discuss.

We look forward to your message!

Of course — a simple method to manually align your panoramas:

1. When capturing images, always orient the camera in the same direction relative to the cardinal points. For example, you can choose to keep the front of the camera facing "north" as you move through a space.
2. Upload photos to the platform. By default, all panoramas will be placed at the origin (0,0) of the coordinate system.
3. (Optional) Move one of the stations along the X axis — for example, 10 meters — to begin laying out the scene.
4. (Optional) Prepare a background image (for example, a floor plan) with a visible scale bar to make station placement easier.
5. Upload the background and align it according to the scale.
6. Place each panorama point in the rooms or areas where it was captured.
7. Use the Delaunay triangulation option in station settings to automatically link points.
8. Open any panorama and visually check whether the positions of the other stations are shifted.
9. In Coordinate settings, adjust the "Rotate view direction for all stations (degrees)" field to correct this. Start with your best estimate.
10. If the rotation goes the wrong way, try rotating again using the formula: -2 × initial guess.

This method lets you precisely control panorama placement manually — even without GPS data!

Watch this short video to see how fast and simple it is: https://youtu.be/IGucR18yJM4?si=2E1MyKhxYIDJG-PD

The issue is that Insta360 panoramas do not contain north-facing orientation data, which is required to auto-generate correct directional links. There are several ways to resolve this:

1. Automatic orientation — for street-view projects where capture points are close together, try the "Use GPS coordinates to calculate rotation" feature on the site.
   Example project captured with an Insta360 X4 and an external GPS module, processed automatically:
   https://360-for-you.com/projects/Ik3R7NWu/
2. Shoot in a consistent direction — if you always face the same way (for example, keep the camera front pointing "forward"), you can later adjust the global rotation angle manually to align links across all images.
3. Manual alignment per panorama — open each panorama, face the (approximate) north, and click the alignment button to set the correct view direction.
   You can do this using the editor linked from the "Basic settings" page of your project.

Note: These methods work only if GPS coordinates are available for each capture point.

Yes — an interactive map view is available for JPG panoramas that contain GPS coordinates in their EXIF metadata.

View capture locations on a map and quickly switch between points. This makes navigation and project context more intuitive, especially for outdoor or drone-based panoramas.

You can also link the map view to any existing project — provided the coordinates are georeferenced. To do this, specify the EPSG code of your coordinate system in the project settings. Once set, the system will correctly interpret and display your geospatial data on the map.

Yes — to disable the map feature for a project, remove the EPSG code in the project settings. Once the coordinate system is cleared, the map will no longer be shown in the interface.

Yes — you can customize the level background color (and other styles) using custom CSS.

In Profile settings there is a field for entering a custom stylesheet. Once added, it will be applied automatically to all your projects.

You can fill this field using the same format as the placeholder example.

Yes — you can display live or recorded sensor data (temperature, humidity, vibration, occupancy, anything a device measures) directly on your panoramas.

What is MQTT, in plain terms?
MQTT is a lightweight messaging protocol widely used by sensors and IoT devices. A device publishes small messages (for example, a temperature reading) to a named channel called a topic, and anyone allowed to read that topic receives the value almost instantly. You do not run any server yourself — we host the message broker for you. Your device just connects and sends values; the tour viewer connects and shows them.

How a sensor sends data to us
1. In Profile → API keys, create a key with the mqtt:publish permission. The key is shown only once — copy it.
2. Point your device or script at our broker. There are two ways to connect:

• Native MQTT over TLS — for physical sensors, gateways and most IoT libraries. Server address: mqtts://360-for-you.com:8883.
• MQTT over WebSocket (WSS) — for anything running in a web browser, or environments that only allow web traffic. Server address: wss://360-for-you.com/mqtt/.

Both ways are equivalent — pick whichever your device supports. Use your numeric user ID as the username, and the API key as the password.
3. Publish your readings to a topic named users/<your ID>/sensors/<sensor name>. You may only write to your own branch — the <your ID> part must match your account.

How the data appears on a panorama
When you add a comment to a panorama, you can embed a sensor into it. From then on, viewers who are allowed to open that tour will see the sensor's latest value update live, with no page reload. Access follows the tour: if the project is public or shared by link, anyone with the link sees the data; if it is private, only its owner, invited users and group members do. Making a project private cuts off readers automatically within seconds.

Embedding a sensor in a comment (the span tag)
To place a value, the project owner edits a comment on the panorama and inserts a small <span> tag pointing at one of their own sensor topics. The text you put inside the tag is shown as-is until the first reading arrives — use it as a label or a placeholder like a dash — and is then replaced by the live value. The simplest form is:

<span data-mqtt="users/<your ID>/sensors/temperature">—</span>

The value shown is exactly the message your device publishes (plain text), so format it on the device side, for example 23.4 °C. The topic must be a concrete one your device publishes to — wildcards are not allowed for viewers.

Optional attributes let you control how the value is displayed:

• data-mqtt-json="<path>" — if your device publishes a JSON object (for example {"temperature": 23.4, "humidity": 45}), use this to pick a single field. Supports nested paths such as weather.temperature and array indices such as readings[0].value. Without this attribute, the entire payload is shown as-is.
• data-mqtt-suffix="<text>" — appended after the value, useful for units. For example data-mqtt-suffix=" °C" turns 23.4 into 23.4 °C.
• data-mqtt-show-last-update="true" — also show how long ago the value arrived, e.g. 23.4 (2m ago).
• data-mqtt-stale-after="<seconds>" — if no new reading arrives within this many seconds, the element is flagged as stale (a data-mqtt-stale attribute is added to it), so you can grey it out or highlight it with your custom CSS.
• data-mqtt-red, data-mqtt-yellow, data-mqtt-green — draw a small coloured dot before the value when the reading falls into one of the listed ranges (a "traffic light"). See Traffic-light indicator below for the range syntax.

A fuller example — pick the temperature field out of a JSON reading, append the unit, show how fresh it is, and turn it stale after two minutes of silence:

<span data-mqtt="users/42/sensors/weather"
      data-mqtt-json="temperature"
      data-mqtt-suffix=" °C"
      data-mqtt-show-last-update="true"
      data-mqtt-stale-after="120">no data yet</span>

If your device splits readings across subtopics, point the tag at the exact one by appending it, e.g. users/42/sensors/weather/humidity. You can put several tags in one comment or spread them across different panoramas — each updates independently, and the same sensor can be embedded in as many comments and projects as you like.

Traffic-light indicator
To draw attention when a reading goes out of bounds, attach a coloured dot to the value. Set one or more of data-mqtt-red, data-mqtt-yellow, data-mqtt-green to a list of numeric ranges; the dot takes the colour of the first matching range, checked in the order red → yellow → green. If no range matches, no dot is drawn; if a colour has no range set, that colour is simply skipped. The ranges are not validated against each other — if they overlap or have gaps, the red → yellow → green priority decides which colour wins.

A range list is one or more expressions separated by ;. Each expression is one of:

• <X — value is strictly less than X
• >X — value is strictly greater than X
• <=X / >=X — same, inclusive
• X-Y — value is between X and Y (both endpoints included); X and Y may be negative or decimal
• true, false, on, off — payload exactly equals this word, case-insensitive — handy for binary sensors. Mix freely with numeric ranges in the same list, e.g. <0;>100;off.

A range matches only its own kind: numeric expressions need a number, boolean tokens need that exact word. Anything not covered leaves the value dotless. If you use data-mqtt-json, the extracted field is what gets compared — not the whole JSON object.

For example, to flag a temperature as red below 0 °C or above 100 °C, yellow on the way out (0-30 or 70-100), and green in the comfort zone (30-70):

<span data-mqtt="users/42/sensors/weather"
      data-mqtt-json="temperature"
      data-mqtt-suffix=" °C"
      data-mqtt-red="<0;>100"
      data-mqtt-yellow="0-30;70-100"
      data-mqtt-green="30-70">no data yet</span>

Security
All connections are encrypted. A device can only publish to its own topics, and a viewer can only read the sensors embedded in tours they already have access to. Revoking an API key stops new connections immediately (existing connections drop on their next reconnect).

If you would like help wiring up a specific device or dashboard, contact our technical support team and we will suggest the best integration approach for your project.

Yes — KNX values can appear on your panoramas through the same MQTT sensor support described above. KNX itself does not reach the public internet (it lives on a wired bus inside your building), so a small KNX→MQTT bridge runs on your local network and forwards selected values to us. It is a one-time setup.

What you need

• A KNX IP gateway or router (KNXnet/IP, UDP 3671) on the same LAN as your KNX bus. Most modern installations already have one — ask your KNX integrator if unsure.
• A small always-on machine on the same network — a Raspberry Pi, a NAS that runs Docker, or any tiny Linux box.
• An ETS export (or just a list) of the group addresses and their datapoint types (DPT) for the values you want to publish. KNX is strictly typed: each address carries, for example, DPT 9.001 (2-byte float, °C) or DPT 1.001 (boolean) — the bridge needs to know which.
• An API key with the mqtt:publish permission (Profile → API keys).

How it works

1. The bridge connects to your KNX IP gateway and listens to telegrams on the bus.
2. For each group address listed in its config, it decodes the raw bytes into a human value using the DPT you supplied (e.g. 21.4 instead of 0x4C13).
3. It publishes that value to our MQTT broker over TLS/WSS under users/<your ID>/sensors/<name you chose>, using your API key as the password.
4. On the tour, embed the value with exactly the same span tag as any other sensor — see Embedding a sensor in a comment.

Choosing a bridge
Several mature open-source projects do this — for example xknx (Python, also the engine behind Home Assistant's KNX integration), or any standalone bridge you can find by searching GitHub for knx mqtt bridge. Pick whichever fits your hardware and skill level — any bridge that publishes to MQTT will work; the contract on our side is just the topic name and the value.

Sketch of a bridge config
Most bridges share the same shape — a KNX connection block, an MQTT connection block, and a mapping of group addresses to sensor names. Roughly:

knx:
  gateway: 192.168.1.10        # your KNX IP gateway

mqtt:
  url: wss://360-for-you.com/mqtt/
  username: "42"               # your numeric user ID, shown on Profile
  password: "sk_..."           # API key with mqtt:publish

mappings:
  - group: "1/2/3"
    dpt: "9.001"               # 2-byte float, °C
    topic: users/42/sensors/kitchen-temperature
  - group: "1/2/4"
    dpt: "1.001"               # bool, on/off
    topic: users/42/sensors/kitchen-light

Exact field names vary by bridge — consult its documentation. Map each KNX group to a friendly sensor name; that is the name you will write in the data-mqtt="..." attribute on the panorama.

Things to know

• The bridge runs on your network, not on ours. Once configured, start it as a service or a Docker container and it will keep publishing as long as your KNX bus is alive.
• Only the values listed in the bridge config leave your building. Everything not in the mapping stays on your bus.
• Revoking the API key in your profile stops the bridge from publishing immediately — useful if a device walks off or you switch installer.
• If a value is a JSON object rather than a plain number (some bridges publish {"value": 21.4, "unit": "°C"}), use data-mqtt-json="value" on the span tag to pick the field — see the previous question for details.

If you need help choosing a bridge or creating the initial configuration for your installation, contact our technical support team.

You can find a detailed PDF guide on how to use Potree's interface functionalities below: Open PDF in a new tab
Source: https://www.linkedin.com/pulse/complete-guide-potrees-interface-functionalities-abderrazzaq/

This guide covers the main tools and options in the Potree viewer to help you get the most out of point cloud visualizations.

Yes — even if your project is based on the metric system, it's possible to display measurements in imperial (US) units.

This is especially useful for teams working in international environments or presenting data to clients who prefer feet and inches. Display units can be switched in the viewer interface.

You can also set the default measurement unit in your profile settings. This ensures your selected format is applied automatically when viewing any project.

We agree — the ability to clean point clouds directly in the viewer would be extremely convenient, especially for removing artifacts such as steam clouds or passing vehicles.

With the current service architecture, this level of fine-grained editing is not technically feasible. Real-time point deletion in the browser would require a completely different processing model and data structure.

For now, external tools are recommended for point-level cleanup before uploading. Future options are being explored, but there is no timeline for this feature yet.

Your data is hosted in the European Union. Our main platform runs on servers located in Germany (operated by Hetzner, a long-established German hosting provider), so your data is processed in line with the EU's GDPR.

Backups are stored in a separate data center, away from the primary server, so that an incident at one location cannot affect both your live data and its backup at the same time.

If you use a dedicated server, you can choose its location — Germany or Finland by default, or another region on request.

You are always in control of who can see each project. A project is visible only to the people you authorize — its owners, users and user groups — unless you deliberately make it reachable by link or fully public. How to set this up is covered under Are there roles and permissions? and How can I share a project with a client?.

Aside from the people you grant access to, a small number of our support specialists may access a project only to help resolve a question or problem you have raised, and always under a strict confidentiality agreement (NDA).

Each project is access-controlled independently: a user only ever sees the projects they own or have been explicitly invited to, and there is no way to reach another customer's private projects.

On the shared platform, your data is logically isolated per account and protected by these access rules. If you require physical separation, a dedicated server hosts only your projects on hardware reserved exclusively for you (see What is a dedicated server and why do I need one?).

Yes. Access is controlled on two levels.

First, every project has a visibility setting: private (only authorized accounts), accessible via link (anyone with the link, no sign-up), or public.

Second, you assign roles to people: owners can view a project and change its settings; users and user groups can view the projects you share with them. You can also control, per project, who is allowed to leave comments. This lets you give each team member exactly the access they need — and nothing more.

Backups run automatically and continuously, so your projects and account data are protected without any action on your part.

They are stored in a separate data center, away from the live server, so a problem in one location cannot affect both copies at once. In addition, a snapshot of the database is taken automatically before any change is applied to it.

The platform is monitored continuously, and its services restart automatically if one of them stops responding, so short interruptions recover without manual intervention.

Your data stays safe regardless: because backups are kept off-site, the system can be restored to an earlier state even if a server is lost. Customers with strict availability requirements can also choose a dedicated server (see What is a dedicated server and why do I need one?).

Yes. We continuously monitor the health and performance of every part of the platform through dashboards and automated health checks, and we keep access logs. If a component becomes unhealthy it is detected and restarted automatically, and anything that needs attention is flagged for our team.

We keep the platform on the latest stable, security-patched versions of all its software components and libraries. Updates are reviewed and applied on a daily basis, so newly discovered vulnerabilities are addressed quickly rather than left to pile up.

We follow a fix-forward approach: if a problem appears after an update, we diagnose it and release a corrected version quickly, instead of reverting the whole system. In practice this restores normal operation faster than a traditional rollback.

Your data is protected independently of releases: a backup of the database is taken automatically before any change, and continuous off-site backups mean the system can always be restored to an earlier, known-good state if it is ever needed.

Yes — the platform is already in active production use by paying customers every day.

It is hosted in the EU and served over encrypted (HTTPS) connections. The application runs in hardened, isolated environments with restricted permissions; access to every project is controlled; secret keys and credentials are stored encrypted; the platform is monitored around the clock; and backups are kept off-site. The same software also powers dedicated and self-hosted installations for organizations with stricter requirements.

All users currently share the resources of a single main server. When many users are active simultaneously, resources are distributed equally — which in rare cases may cause minor performance slowdowns. However, most users do not notice any impact.

A dedicated server is a separate physical server created specifically for your use. Only your projects are hosted there — ensuring full performance, private data processing, and greater control over resources. It's a good option for teams with high data volume, many users, or strict internal policies.

Yes — you can use your own domain. This option is available on all plans with a dedicated server.

You can also use a third-level (sub)domain for the service. In other words, if your domain is example.com, we can make the platform available at an address such as 360.example.com — where "360" can be replaced with any word you choose.

We can provide a server hosted in Germany or Finland — depending on your preference.
All servers are connected to the Internet via a 1 Gbit/s link, ensuring fast and stable data transfer even for the largest point-cloud projects.

Yes — as part of a dedicated server plan, we can install and configure Nextcloud for you. This will allow you to use the server as a private file hosting and sharing solution.

Please note: we perform the initial setup; ongoing administration and management of the file storage system (for example, users, permissions, backups) will be your responsibility.

Yes — we offer a self-hosted version of the software for complete offline use, ideal for organizations that need to keep sensitive data in-house.

The self-hosted version is available for a one-time payment of €4,500. You will receive a Docker container with complete setup instructions and guidance for first-time deployment on your own server.

The container is provided with lifetime usage rights and includes 1 year of update access. After one year, you may continue using the container with its current features or purchase an extended support package to receive future updates.

Alternatively, dedicated server plans are available and include unlimited access to all features. Storage can be expanded up to 308 TB.

Requirements depend largely on the size of your point clouds. If working with 10-20 million points per station, we recommend the following:

• At least 64 GB RAM, plus a large swap file as a fallback.
• A fast SSD or NVMe drive for the container itself — project storage can be placed on a regular HDD.
• CPU is not critical; a dedicated GPU is not required.
• SMTP access to your mail server is required to send emails from the system.
• External internet access (domain, DNS, SSL certificate, reverse proxy) must be configured on your side — this is standard if you already have a managed server.
• You will also be responsible for creating backups.
• No database maintenance is required — everything is managed automatically inside the container.

When these components are in place, the platform will operate reliably and efficiently on your infrastructure.

Yes. Besides Google and Microsoft Entra ID, the platform can sign users in through any standard OpenID Connect (OIDC) provider — including Active Directory Federation Services (AD FS), Okta, Keycloak, and Auth0 — so you can keep using your existing IAM procedures. Accounts are provisioned automatically on first sign-in and matched by email address. Configuration is just a discovery URL plus a client ID and secret, set in the admin settings.

Yes — customization is available. Please contact our support team and specify what you would like to change — the visual theme, email templates, or other elements. We will discuss available options and help tailor the system to your needs.

Yes — if you use a dedicated server, your IT team can customize many parts of the user interface to reflect your company's branding.

The system uses Jinja2 templates for web pages and emails, and CSS stylesheets for styling. This allows modification of visual elements such as logos, colors, layouts, and wording.

If needed, we are always available to assist with custom adjustments — most changes can be implemented independently by your team.