PTX files with normals

[framed]

Hi Daniel,

It's now common for PTX files to include normals. Leica Register360 now has this option for exported PTX files. They have 10 columns in total: X Y Z int R G B Nx Ny Nz. Any chance you can add support for this extended PTX format?

[c3kkos]

Is it plain ASCII file?

if so, rename extension to whatever ASCII format CC support and the wizard form will let you choose what gives what based on any number of columns

[daniel]

Yep, good trick for now. But we should definitely add this to the PTX I/O filter as well.

[framed]

Thanks for the suggestion. Yes the ASCII method works, but the station info doesn't come through which is critical to my workflow.

[daniel]

Ok, I've made the change in the latest 2.14.beta version online (for Windows). Tell me if it works.

And even better, if you could send me a sample file, that would very useful to check that I've done things correctly.

[c3kkos]

The sensor is not imported correctly because the I/O filter for ASCII files is parsing data -> to points only.

Hence, CC will need a better, ad hoc filter for that format, in order to get the job done.

For now, you can painfully use the data to craft by hand the sensor item..... or can you?

is CC able to add a sensor and editing data into it by hand?

[daniel]

So, the I/O filter has been updated already. I'm just waiting for some feedback from someone owning real PTX files with normals.

[framed]

Hi Daniel,

No luck with the latest beta. Still getting a malformed error.

Here is a PTX file with normals. It has been exported from Leica Register 360. This is one setup in a project of registered point clouds.

https://www.dropbox.com/scl/fi/lb1qyxt9 ... nxz2i&dl=0

NB: The file is 1.5GB in size.

Also, here is an e57 version of the same cloud that imports fine: https://www.dropbox.com/scl/fi/f841ksj7 ... ruyms&dl=0

[c3kkos]

framed,

the .ptx files you shared is a bit weird.

let me paste the first data in it:

Code: Select all

10168
4166
0.000000 0.000000 0.000000
1.000000 0.000000 0.000000
0.000000 1.000000 0.000000
0.000000 0.000000 1.000000
0.637030 0.770839 -0.000195 0.000000
-0.770839 0.637030 0.000483 0.000000
0.000497 -0.000157 1.000000 0.000000
1.135838 1.126922 0.620313 1.000000
0 0 0 0 0 0 0 0 0 0
-0.034154 -0.002539 0.300672 0.551171 175 180 173 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
-0.034154 -0.004539 0.300672 0.499992 175 180 173 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0

and so on....


There are A LOT of zeroes...

the header will not be read as sensor data at all, for now, in CC, using the ASCII I/O filter, as EVERY row will be interpreted as points and/or normals or scalar fields, or RGB channels. This can be set at import time.

Screenshot 2026-06-05 143534.png (57.59 KiB) Viewed 10532 times

please note the trick. .ptx edited to .pts
opened with ASCII filter
set up things in the import wizard form (note the arrows)

result:

Screenshot 2026-06-05 144142.png (266.89 KiB) Viewed 10532 times

normals and RGB are valid

[framed]

Thanks c3kkos,

The reason for the zeros is that this is gridded data, measured from a single terrestrial scanner setup. Zeros represent no return measurement (eg. sky). Yes the ASCII import option works, but the sensor data is critical to my workflow.