[Question] Rendering XYZ files via Azure Remote Rendering

[DinethD-VM]

Looking to render xyz files through Azure Remote Rendering onto a Hololens 2.

Running into an issue when rendering the data in ARRT it renderers nothing.

Is there some conversion setting I'm missing? Or is there a preprocessing step that needs to happen before uploading to Azure?

Example file (GitHub wouldn't attach the file): https://virtualmethod-my.sharepoint.com/:u:/g/personal/dineth_dissanayake_virtualmethod_com_au/EWKzBAvNtzBBiLV_kHd1itIBz3nOqAyVnfdGHF5Ka0u7ig?e=qAw4YH

[AdamCichocki]

XYZ files are expected to provide points formatted "position_x position_y position_z red green blue", as mentioned here https://learn.microsoft.com/en-us/azure/remote-rendering/how-tos/conversion/model-conversion.

Below is an example of a very simple point cloud in supported XYZ format, which includes 3 points: 24.536 -0.161604 8.06659 18 31 21 23.9794 -0.159089 7.73088 10 19 14 23.9828 -0.159214 7.71797 9 18 13

This is also how your asset is being interpreted. Currently it's not recognized as a failure, so the import succeeds but data is broken. Note that apart of the points data, your input file also contains a header which specifies the data layout within the file, and sections. The header and sections are not expected to be there even if the points layout meet our guidelines.

In order to work around this issue, please use the supported layout within XYZ , or any of the other supported formats (binary-PLY, E57, LAS, LAZ).

[WikkidEdd]

The conversion goes through fine reporting 164456 points and a bounding box of 495101.27m x 7027558.50m x 495100.83m along with a warning

Point cloud contained vertex positions very far form the origin. These large offsets have been moved to the scene graph instead.
{"centerDistanceHardLimit":7000.0}

As you mention @AdamCichocki the format clearly doesn't match the specification.

One point in the point cloud being. 493776.97 7026383.62 -26.88424883 26.93734150 2017/03/21 07:12:43 203580 1331.00 27729.60 27733.59 27734.00 27734.00 27746.089 27746.733

With such a mismatch, is this something you could detect and throw an error for?

In our case, our app is designed to be an off the shelf solution for people to use ARR. If there is no error or even a warning about the file specification then we can't inform our users that they are doing something wrong. This would probably result in our users trying multiple times to convert the same file and getting frustrated when it doesn't work.

[AdamCichocki]

Yes we'll improve this.

[AdamCichocki]

Improvement in question is included in latest release.