fix for New spatial mapping drops frames every update period

[darax]

Fixes #264
Fixes #207

[izatar]

I just tried this out, and the flickering issue is fixed.
However, I did notice two new things I have not seen before.
First, the button panel that is put up is under the finalized mesh, so I can't see it. It appears to be too close the mesh plane and the z-ordering is inaccurate.
The second is that the finalized mesh is not 'water-tight' anymore, there are gaps that have no polygons.

UPDATE: I just tried this with my geometry-shader free material, and I am now seeing up to 60fps on the finalized mesh. This is the good news. The bad news is that meshes don't match up, have holes in them, and float around relative to each other when the anchor drifts.

[izatar]

The attached image shows an example of the gaps in the finalized mesh. It looks worse in holo-reality.

[izatar]

After some false starts (like normal calculation), I did find the change that seems to trigger this problem:

 if (GetComponent<WorldAnchor>() == null)
            {
                gameObject.AddComponent<WorldAnchor>();
            }

I don't understand why. But, there it is. Wasn't easy to discover.

[darax]

I reverted to having an anchor per mesh rather than one anchor. That seems to have fixed the seams.

[darax]

I've also added a change to get rid of the unreachable code warning.

[izatar]

This is better, but there are still some seams.
Converting:
AddSurfaceObject(null, string.Format("SurfaceUnderstanding Mesh-{0}", meshSectorsIndex), transform).AddComponent<WorldAnchor>();

to
AddSurfaceObject(null, string.Format("SurfaceUnderstanding Mesh-{0}", meshSectorsIndex), transform);

seems to remedy this situation. That is to say, just don't do the worldanchor at all. It works without them so I'm not sure if they are necessary?

EDIT:
Unfortunately, even with this fix, there is still a problem with seams when you use a different material from the wireframe, like anything that relies on normals for lighting which is most materials.

It turns out my investigation into normal calculation was not a false start.
MeshObject.RecalculateNormals();
is setting the normals incorrectly at edges, which makes a tiny seam.

The right answer is to manually set the normals correctly. If you merely want parity with the previous code base, remove this line of code and don't put in the normals at all. Doing this will force shaders to do more work, and will limit some effects they can do however. However this is still better than incorrect normals!

If you really want to do it right, UVs could be set too.

[darax]

We are ignoring the normals that come from the native layer. I can refactor to use them to see if it helps.

Regarding the anchor, if you don't have an anchor and lose tracking the meshes will likely be off the surfaces after tracking is restored.

[darax]

The normals from the native layer seem to be all zero. However, in doing so I was forced to remove an optimization where a single vert could be reused multiple times, and I think that will fix the normal problem. Let me clean this up and I'll push it so that you can try it.

Thank you very much for the time you spent on this!

[darax]

I think I got it. :)

I tested with a shader that rendered raw normals, and they look consistent, even at the edges (I saw how they weren't before). I had to stick with a single world anchor or the seams would appear when rendering with wireframes.

I still do see some artifacts when using the wireframe.

[izatar]

This is looking good to me. I did not notice artifacts on the wire mesh, but I didnt spend much time at it.

[StephenHodgson]

Looks good, just one question about the need of Linq (totally understandable if it actually does help) and just a single space nit.

[StephenHodgson]

Nit: extra space

[StephenHodgson]

Are we actually using Linq in this class? If so, do we need to?

[NeerajW]

True. Nothing I saw in this change seemed Linq related.

[darax]

Is there a better namespace to get the ElementAt extension from?
// Get the next MeshData.
MeshData meshData = meshSectors.Values.ElementAt(meshSectorsIndex);

[darax]

I'm going to merge this now.