instant-meshes

instant-meshes copied to clipboard

I'm using the Windows 64 bit build on Win7/64, 32GB RAM. I exported a .ply point cloud file from CloudCompare: https://www.dropbox.com/s/hlavw11ekv9be51/market_reduced%20-%20Cloudsubsetbinary.ply?dl=0

However, when I try to import this, I get the error message "does not contain vertex indices".

There aren't any options in CloudCompare to add vertex indices -- what is going wrong?

Thanks,

Eliot

I have a similar problem with .obj from Blender. The file is correct, contains all vertices coordinates, it does something in instant mesh (one CPU is used pretty long) but when finished, nothing appears (no errors either).

Hi,

to use the point cloud feature, you will need an ALN file (made e.g. by Meshlab) which references a number of range scans (e.g. sheets of geometry that were acquired using a laser or structured light scanner).

The ALN format is just a text file with the number of range scans in the first line, and the remaining lines reference a bunch of PLY files of each scan with an associated rigid transformation.

See here for an example: https://www.mitsuba-renderer.org/files/repository/gargoyle.zip

Instant Meshes requires position + normal information -- the latter is easy to extract from a range scan but harder to obtain from a raw point cloud, hence the latter option is not supported by the software the moment.

Best, Wenzel

So it doesn't work with photogrammetry either at the moment? Blender supports exporting vertex normals, I'll test with this. Or does it really have to be an ALN format?

Blender doesn't seem to be able to export vertex normals actually, nor .ply containing only point clouds (faces are ok). I tried with the latest version of meshlab (1.3.3) but couldn't find an ALN export (ply, dxf, etc... but no aln). I'll try to find a way, but do you plan to compute point normals directly in instant mesh some day?

It's unfortunately not a priority right now, we are working on a different project atm. I would accept patches that add this functionality though.

Hi,

I have been doing some work with pointclouds and can contribute to this somewhat. Currently instant-meshes computes vertex normals from the attached faces. A workaround is to precompute vertex normals (e.g. using meshlab) and export them to a PLY file. This requires modification of the PLY reader in instant-meshes to read vertex normal properties.

I have modified the PLY reader in my version and this seems to work on the sample from @eliot-lightcraft and photogrammetry data. I am happy to create a pull request of this if you want.

That looks great! Much cleaner than the clouds of polygons I encounter with Poisson reconstruction.

Did you use any unusual settings when precomputing the mesh normals?

On Tue, Nov 17, 2015 at 5:57 PM, Stuart Mead [email protected] wrote:

Hi,

I have been doing some work with pointclouds and can contribute to this somewhat. Currently instant-meshes computes vertex normals from the attached faces. A workaround is to precompute vertex normals (e.g. using meshlab) and export them to a PLY file. This requires modification of the PLY reader in instant-meshes to read vertex normal properties.

I have modified the PLY reader in my version and this seems to work on the sample from @eliot-lightcraft https://github.com/eliot-lightcraft and photogrammetry data. I am happy to create a pull request of this if you want.

[image: marketreduced] https://cloud.githubusercontent.com/assets/11204684/11230062/a1d71440-8def-11e5-9d7e-a27180e3357b.PNG

— Reply to this email directly or view it on GitHub https://github.com/wjakob/instant-meshes/issues/7#issuecomment-157572269 .

Hi Stuart, Nice job. Would it be possible to also add it for the obj import?

@mirlip it is probably possible to read vertex normals from an OBJ file. However, care needs to be taken when using vertex normals that aren't computed from polygon faces. Orientation/direction of the normals plays a part in how instant-meshes works (at least based on my reading of the paper) and normals computed directly from a point cloud can be inconsistent. This inconsistency can result in a very disconnected and incoherent mesh. I am in no way associated with instant-meshes or the team that created it, so it is probably best to wait for Wenzel to comment on whether point cloud surface reconstruction is something they want this program to do.

@stuartmead: I'd be interested in a pull request as long as it doesn't break any of the existing functionality (working with meshes & structured light scans with an ALN file).

One thing I should point out is that the extraction phase of our method currently assumes that the input geometry is reasonably uniform in terms of vertex coverage.

For non-uniform input meshes, this is not a problem: we can simply subdivide down to a uniform resolution. For range scans, the resulting point clouds will generally be fairly uniform, so not much is needed. But to deal with this kind of extremely non-uniform input (e.g. from a LIDAR), the extraction phase will likely need some modifications to avoid producing lots of holes.

Yep, in my test, point clouds from Photoscan are very non-uniform, just like Lidar. @stuartmead, when your patch for the point cloud normals is pushed, I can test it with photogrammetry data :)

Hi,

I'd also be interested in your version @stuartmead. I tried to patch the load_ply method but I got the same result as @mirlip (nothing appears in the end).

And for the records, here's what I get with PoissonRecon V8 once I managed to compute relatively good normals (which is very hard without the sensor positions).

Hi, no surprises here -- if your pointcloud is non-uniform, you may currently be better off doing poisson reconstruction and then running instant meshes on top of that to get better element quality.

We will probably work on changes that make the extraction stage more robust to non-uniformity in the future.

"We will probably work on changes that make the extraction stage more robust to non-uniformity in the future." That's would be nice :)

Using commit d45f97a I had to patch it to load my own file: http://devaux.fabien.free.fr/head.ply.xz

--- src/meshio.cpp.orig 2015-11-27 17:27:09.079382810 +0100
+++ src/meshio.cpp  2015-11-27 18:08:52.209337669 +0100
@@ -90,7 +90,7 @@
     if (vertexCount == 0 && faceCount == 0)
         throw std::runtime_error("PLY file \"" + filename + "\" is invalid! No face/vertex/elements found!");
     else if (!pointcloud && faceCount == 0)
-        throw std::runtime_error("PLY file \"" + filename + "\" is invalid! No faces found!");
+        pointcloud = true;

     F.resize(3, faceCount);
     V.resize(3, vertexCount);

@fdev31 nice fix, please push it to master with @wjakob

Hello! i'm picking up this thread as I'm very interesting to processing my point clouds with instant-meshes. If I'm reading this thread correctly, it looks like @fdev31 made a change here that would allow a PLY with computed vertex normals embedded in the .ply to open? is that correct? it also look like that change hasn't made it back into master?

looks like this a solution to getting the clouds with normal (without manually creating ALN) is close to possible. Hoping to trigger, contribute to a solution for loading clouds from either PLY or OBJs.

@stuartmead were you able to import a cloud from OBJ in a normal build, or your own build? also is there a path for your changes to make it into master or another working branch?

Below is my experience attempting to follow on from your comment "it is probably possible to read vertex normals from an OBJ file."

In meshlab I attemped this from a cloud which already has normals)

to make sure that i have normal in an export, I chose Normals, Curvatures and Orientation -> Compute normals for a point set` (see below)

With these options:

in the result, normals continue to be visible in meshlab ;

I exported this as an OBJ with the following options:

The resulting file looks to have normals (as expected).

####
#
# OBJ File Generated by Meshlab
#
####
# Object test-vertex-normals-002.obj
#
# Vertices: 72402
# Faces: 0
#
####
vn 0.320425 0.947210 0.011039
v 3.047233 3.079154 7.661845 0.070588 0.058824 0.050980
vn -0.826264 0.218880 0.519018
v 5.587306 5.232621 4.503028 0.164706 0.200000 0.141176
vn 0.229501 -0.908775 0.348506
<<clipped>>

The output OBJ file can be downloaded here - test-vertex-normals-002.zip

Opening this in the windows build, get the following console output (no joy)

Loading "C:\Users\user\Desktop\detailed\detailed\test-vertex-normals-002.obj" ..
 done. (V=0, F=0, took 308.0ms)
Computing point cloud statistics .. done. (took 1.0ms)
Generating adjacency matrix .. allocating 0 B .. done. (took 2.0ms)
No target vertex count/face count/scale argument provided. Setting to the defaul
t of 1/16 * input vertex count.
Output mesh goals (approximate)
   Vertex count         = 0
   Face count           = -1
   Edge length          = -1
Processing level 0 ..
    Coloring .. done. (0 colors, took 0.0ms)
Building multiresolution hierarchy ..
  Collapsing .. done. (0 -> 0 vertices, took 0.0ms)
    Coloring .. done. (0 colors, took 0.0ms)
<<<CLIPPED>>>
    Coloring .. done. (0 colors, took 0.0ms)
Hierarchy construction took 176.0ms.
Setting to random solution .. done. (took 0.0ms)

Multiresolution hierarchy statistics:
    Field data          : 0 B
    Vertex data         : 0 B (level 0: 0 B)
    Adjacency matrices  : 0 B (level 0: 0 B)
    Tree connectivity   : 0 B
    Vertex indices      : 0 B
    Edge connectivity   : 0 B
    Parallel phases     : 0 B
    Total               : 0 B

Bounding Volume Hierarchy statistics:
    Tree nodes         : 0 B
    Index buffer       : 0 B
    Total              : 0 B

GPU statistics:
    Vertex buffers      : 0 B

Any pointers? or are there code changes that individuals have made that we can pull in?