Use octee for normals and uvs seperatly

[QuantumEntangledAndy]

This PR applies some of the features discussed in #27 namely using an octree for normals and uv coordinates and caching them in separate tables.

• Cache positions, normals and uvs in seperate octrees
• Store only the index of the position/normal/uv in the vertex (node) data.

This is currently just during baking and it is converted to the same list of verts and normals as before during the Meshify::build step. But in future we could make obj like that exported in blender using the separate tables.

This reduces the number of normals and uvs kept in memory during caching as most normals and uvs are duplicates

[QuantumEntangledAndy]

p.s the reason its a draft is because I cannot seem to get the terrain example to run, not quite sure why but it just hangs infinitly. Thought I'd post it here though for comments though while I work out why.

[norman784]

Also one thing that will be cool is to run the benchmark to see how this PR performs against master, you can go to the gaiku-3d crate and run there cargo bench the only one I care about right now is Voxel, the last time I did that the numbers where:

Voxel/Terrain	Voxel/Planet	Voxel/Small tree
90.003 ms	37.642 ms	378.72 us

** I saw sometimes a difference of 2% between runs.

[QuantumEntangledAndy]

I've gotten the mesh part to work well but for some reason the texture is mostly transparent. Without textures applied the mesh looks good but with texture it look like this:

I will keep working on it

[QuantumEntangledAndy]

Ah fixed :)

Also can we get #31 merged so we can remove these lines in the texture

[QuantumEntangledAndy]

Running benches now

[QuantumEntangledAndy]

Here are the benches, mine are a lot slower than your as my mac is not that fast

• This PR

Marching cubes/Terrain  time:   [1.0115 s 1.0902 s 1.1700 s]
Marching cubes/Planet   time:   [283.66 ms 305.17 ms 326.85 ms]
Marching cubes/Small tree
                        time:   [12.270 ms 13.776 ms 15.417 ms]
Voxel/Terrain           time:   [3.0444 s 3.2841 s 3.5259 s]
Voxel/Planet            time:   [1.0960 s 1.1966 s 1.3004 s]
Voxel/Small tree        time:   [5.9511 ms 6.8635 ms 7.7714 ms]

• Master:

Change here is relative to this PR, improved results here means master is faster

Marching cubes/Terrain  time:   [655.90 ms 715.03 ms 777.32 ms]
                        change: [-41.420% -34.413% -26.695%] (p = 0.00 < 0.05)
                        Performance has improved.
Marching cubes/Planet   time:   [171.36 ms 191.82 ms 213.18 ms]
                        change: [-45.028% -37.144% -27.819%] (p = 0.00 < 0.05)
                        Performance has improved.
Marching cubes/Small tree
                        time:   [10.458 ms 11.387 ms 12.297 ms]
                        change: [-28.421% -17.341% -5.2276%] (p = 0.01 < 0.05)
                        Performance has improved.
Voxel/Terrain           time:   [1.0673 s 1.1657 s 1.2663 s]
                        change: [-68.624% -64.504% -60.188%] (p = 0.00 < 0.05)
                        Performance has improved.
Voxel/Planet            time:   [398.15 ms 437.01 ms 477.02 ms]
                        change: [-67.795% -63.480% -58.558%] (p = 0.00 < 0.05)
                        Performance has improved.
Voxel/Small tree        time:   [6.8469 ms 7.3748 ms 7.9186 ms]
                        change: [-7.2969% +7.4495% +25.938%] (p = 0.35 > 0.05)
                        No change in performance detected.

Seems to be slower :(, which is a shame because I like this implementation as it dosen't treat the uvs and normals as anything special just as another set of data to cache

[QuantumEntangledAndy]

I am beginning to wonder if the benchmarks I made here are accurate. I cannot seem to get a consistent timing on my machine even when I run the same bench mark twice in a row with no changes it will have +-50% change

[norman784]

I get usually single digit % diff between runs.