Workflow for exporting .las files as .obj?

[Helenium]

I am new to CloudCompare. From looking around online, it looks as if CloudCompare could be used to translate a .las LIDAR scan of a large landscape form to a mesh that is editable in 3D editing software. I haven't found a direct way to do it though. An OBJ file is ideal, and I'd like to keep the color information. Is there a resource already online somewhere that I can follow? The file I am experimenting with has 17M vertices, although there are sections around the periphery I would be happy to eliminate as they are unnecessary. Here's what I've tried:

Applying the Delaunay 2.5 in CloudCompare to the unedited scan creates 34M faces which is way more than my hard drive can handle.

If I don't apply the Delaunay 2.5 and export it, I can open it in Meshlab but it's just the 17M vertices and no faces, and I wasn't sure what to do next. I found an old article that says how to do mesh point clouds in Meshlab there but the first step, Poisson Disk Sampling, just hangs.

I don't mind slicing the file first to get smaller chunks as a first step for any of these processes (if they will work), but is there a way to slice it so I can match the chunks up precisely later? Also, since the landscape is so large, it does not have to be resolved down to a tiny measurement for my purposes, so if there is something I can do about that when I'm opening the file, let me know.

Thanks,
H

[daniel]

Well, before the sad news, you can indeed reduce the number of points easily with the 'Edit > Subsample' tool (either with the 'distance' or the 'random' modes - see http://www.cloudcompare.org/doc/wiki/in ... CSubsample).

The real issue is that OBJ files can't store per-vertex colors, and the only way to color them is to associate them to texture images. However CloudCompare can't convert per-vertex colors to textures. Therefore I won't see how to achieve your goal. Note that the FBX or PLY formats are able to store per-vertex colors...

Otherwise, if you can live without the colors, you can indeed use the Delaunay 2.5D tool to generate a mesh easily (but it's quite sensitive to the point cloud noise). Otherwise there's the PoissonRecon plugin (see http://www.cloudcompare.org/doc/wiki/in ... n_(plugin)). However you'll need to compute normals first (should be easy for a landscape cloud, you should get good results with the '+Z' direction as preferred direction to orient the normals). You should also compute the normals before subsampling the cloud.

[Helenium]

Thanks for the quick reply. So for the computing of Normals, do I set it to Plane and the "use octree" to "Auto"? Those were the defaults. When I apply the Poisson Surface Reconstruction plugin, It closes up the front of the landscape with a big rounded surface, and drastically reduced the file to only 59128 triangles. So that's no good.

Applying the Delaunay 2.5 and saving as OBJ provided something easier to see in Meshlab than an STL, but they both have 27.5 million faces, but oddly enough, the side that is articulated in light gray is the underside of the landscape and not the surface, which is almost black. I'm not a Meshlab expert by any means so I don't know what to make of that.

Anyway, I won't go into everything I've tried, but I've spent hours trying various things none of which work.

[daniel]

For Poisson, you can increase the octree level to increase the output mesh precision. And you can remove the closing triangles afterwards by playing with the 'Density' scalar field (see the small explanation about this in the plugin's dialog or on the wiki).

[Helenium]

Thanks for the tips. I tried just working on a small segment of the file. With just that small piece, I realized that when I ran the Compute Normals that the texture projection was on the bottom instead of the top of the landscape, so I tried the invert normals function, which fixed that so the colors were on the correct side. Then when I ran the Poisson Reconstruction, the closing triangles were on the back and bottom of the form, instead of covering the front -- and the form resolved really nicely. They do still bulge out on the back and bottom, and I haven't tried removing them with the Density scalar field, yet, but I did export the form as an STL to my 3D editing software and it opened (only 2.2 million faces, which is fine), and the bulging parts are not hard to remove there by selecting and deleting them.

If I understand you correctly, there is no way to extract the texture layer as a JPEG or image file that I could project onto that STL? It looks great in Cloud Compare with the Poisson applied so clearly it's hiding in the data somewhere...

--H--

[daniel]

Yes, the color is stored as per-vertex RGB info. But neither OBJ nor STL are able to store that kind of info! You need PLY and maybe FBX.

[Helenium]

Someone on the 3D Scanning forum on Facebook, where I was looking for suggestions on how to approach this, wondered if Cloud Compare could add saving extended .obj with vertex coloring, which he said Zbrush can save and Xnormal can load. Also, I don't see .fbx among the saving options on Cloud Compare. I'd be able to open an .fbx file in my 3D editing program. Am I overlooking something?

[daniel]

Ah, I don't like to propagate this kind of 'heresy' (I mean hacky and non-official OBJ files, instead of using more evolved open formats such as PLY). But it's true that Meshlab also exports such OBJ files... Once too many program use it, it will become a de-facto standard :D

And for the FBX export, what version are you using? And on which OS? (FBX is only available on Windows).

[Helenium]

I was using CloudCompare for Mac, but I also have Windows PC, so I tried it on the PC, and now I see that the FBX option is there. I did a quick test of Poisson Reconstruction and the file was much too soft and lacking in detail compared with the Mac, but I will try again when I have time to experiment, increasing the Octree level more. I was also surprised because my PC is newer and usually faster than my Mac for 3D applications, but the Poisson ran very slowly by comparison -- it was using 96% of my CPU (though only 21% of my RAM) even though that was the only program running.

Also, I did export the file as FBX from Cloud Compare, and I do see the colors in Cloud Compare, but when I opened the FBX in my 3D editing software (Modo), it still didn't have any color information.

When you say "play with the Density scalar field" to reduce the puffiness of the closing triangles, I looked at the documentation (p. 131 of the User Manual), but honestly, I don't understand what the implications of any of those are. What happens if you have more neighbors vs. fewer neighbors? How do you know whether to select Number of Neighbors, Surface Density or Volume Density? If the Precise radius number when I open the Density dialog box is 0.6, do I want to increase that number or decrease it? How do I know whether to choose Approximate or Precise?

Thanks,
H

[daniel]

1) Not sure why it's slower on PC. The algorithm uses all available cores (it runs in parallel, this is why it can take almost all the available CPU). Maybe your Mac has more cores? Or this kind of things are handled in more clever way by MacOS?

2) Well, FBX files can store per-vertex RGB color, but it doesn't mean that the software reading this file will support it :D. Too bad...

3) I was referring to the PoissonRecon 'density' scalar field (see http://www.cloudcompare.org/doc/wiki/in ... n_(plugin)). Forget about the PDF documentation, it's clearly outdated. Only the wiki is updated now.