As for the performance, well overall there is not a big difference but the Morton version may be slightly faster. I think the main reason it is interesting is that it makes some other operations easier such as downsampling the volume data.

But really I’m just giving information on how you implement this scheme. Whether you actually want to may depend on your exact use case.

It looks good at low values, the distance from (-1,-1,-1) to (1,1,1) around 7,7,7 is only 3080 (still more than the 2048+ a little it would require)… so okay
at 1,1,1 the distance is only 56. But as the values increase so does the distance spanned in memory.
doing 1,1,1 to 32,32,32 the average is 14336 min/max range.

Having reasonably sized sectors (16x16x64 or even 32x32x32) is more likely to have near values cached. It also complicates the indexing between sectors for near points.

I think we need to do some more tests with these lookup tables vs. computing the offset at run time with the tricks you describe. I do agree that the calculations should be faster in principle due to touching less memory. It’s surprisingly difficult to test these things accurately though.

Thanks for your blog post, very interesting !
I’m the original author of the code you link for generating Morton offsets at compile time (https://github.com/aavenel/FastMortonKeys/blob/master/mortonkeys.h).
However, I’m not very proud of this, and it’s possible to implement this in a much easier way :/
I agree with Fabian comment, only one table should be better.

If you want, I have some code snippet for additionning morton-encoded coordinates in xyz form, you can have a look here :
https://gist.github.com/aavenel/a5349516aa33b7499eef

It looks like really cool stuff. You and Fabian Giesen have got me thinking again about computing some of this on the fly (rather than using the lookup tables) as in principle such bitwise operations are supposed to be faster than memory accesses.

Edit: Maybe that was too negative. Here I said “The tests which are very heavy on sampler access show a 40-50% increase , but practical algorithms such as the Marching Cubes extractor show only a few % increase.”

I think overall it is worth it, but your mileage may vary 🙂

For the rest it depends; a small table is certainly not bad.

One thing that might be useful for you is that morton256_y[i] = morton256_x[i] << 1 and morton256_z[i] = morton256_x[i] << 2, and the same goes for the delta tables. So you can reduce the amount of tables you store (and cache misses you might incur accessing them!) by a factor of 3 for the cost of 2 bit shifts per access, which is a pretty good deal.