use of normal vectors about cpu_tsdf

[sdmiller]

Hi Janos,

This is an example of one of those "Relics of a larger library" things. I believe I support normals because the PCL TSDF implementation on the GPU has use of them (for, e.g., the rendering and ICP step), and I wanted to remain compatible. But in my library they aren't used, and it isn't entirely clear what they would benefit.

[Janos95]

In my experience from using your code, it is tricky to reconstruct very thin objects. From my (shallow) understanding of the algorithm, the signed distance function will interfere with itself if the object is thinner than twice the positive(or negative, I am not entirely sure) truncation distance. I hoped normals would help to ameliorate this problem.

On another note, do you still consider putting the gpu code online at some point?

[sdmiller]

You triggered my memory! I do recall looking into this for a while in grad school -- the idea of tessellating the SDF, so it could keep track of fields separately depending on which angle was being queried.

The way the code is written, it would be relatively easy to experiment with this by creating a new Voxel type which contains an array of numbers (say, the observed SDF from X different angles). But to my knowledge there isn't a standard way of doing this yet -- though, admittedly, I've been out of the academic game for a while.

Unfortunately, I think the GPU code is toast. Though if you look at pcl::KinfuTracker, you might see some remarkable similarities in the way we defined certain methods.