Can't figure out math for converting negative indices of my voxels and chunks to positives

Question

In my voxel game, I'm trying to spawn chunks in all directions. But since my world starts at 0,0,0, some chunks can spawn at negative positions like -1,0,-1.

My chunks are 16x16x16 size.

When generating(or not) a block, somewhere in the process, I need to find what block is at position A(xyz 0-15) in chunk B(xyz -max +max), based on block's world position.

So for example, block at world position(can be xyz-max +max) 1, 0, 1 should give me chunk 0, 0, 0 and block's relative position inside chunk is 1, 0, 1.

block at world position -1, 0, -1 should give me chunk -1, 0, -1 and index of block relative to this chunk 15, 0, 15.

But as you see, there is an inconsistency and loss of symmetry(-1 relative to 0 gives -1 and 1 relative to 0 gives 0) relative to 0, 0, 0, that I can't figure out how to fix.

Currently I find relative index in chunk from world position using this:

    int size = 16;

    int x = -1;
    int y = 0;
    int z = -1;

    int chunkRelativeX = x % size; 
    int chunkRelativeY = y % size; //0
    int chunkRelativeZ = z % size; 

    if (x < 0)
    {
        chunkRelativeX += size; //15
    }
    if (z < 0)
    {
        chunkRelativeZ += size; //15
    }

And I find chunk position itself using:

    int chunkPosX = Mathf.FloorToInt((float)x / size); //-1
    int chunkPosY = Mathf.FloorToInt((float)y / size); //0
    int chunkPosZ = Mathf.FloorToInt((float)z / size); //-1

Problem is, with positives, its correct, since before 1st chunk comes 0st, but before -1st chunk, doesn't come 0st.

I'm really confused and not sure what to do :D

Thanks in advance.

Answer 1

I think your problem might be partially due to the way the % operator works with negative numbers. I have a vague memory of tripping up in the same way - I present you my method of dealing with this. I have created a special struct that holds 5 numbers - the local XYZ and the chunk position - I use this in a lot of terrain related stuff. I don't use voxels but terrain is still stored in chunks (128x128 but it really doesn't matter here I believe).

What you're probably specifically interested in is creating such coordinates from an arbitrary XYZ - one of the methods in my struct takes a Vector3 and then applies this Normalize method to figure out all the numbers.

   //chunk size
   public const int Stride=128;
   //local coordinates
   public float X;
   public float Y;
   public float Z;
   //chunk coordinates
   public int BX;
   public int BY;
   //make sure local coords are within range of 0...127
   public void Normalize()
   {

        this.BX += ((int)Math.Floor(X / (float)Stride));
        this.X = ((this.X % (float)Stride+(float)Stride)% (float)Stride);
        this.BY += ((int)Math.Floor(Z / (float)Stride));
        this.Z = ((this.Z % (float)Stride+ (float)Stride)% (float)Stride);

       
    }
    //Convert a standard XYZ to local XYZ + chunk coords
    public static implicit operator WorldPosition(Vector3 a)
    {
        WorldPosition result = new WorldPosition();
        //set to XYZ
        result.X = a.X;
        result.Y = a.Y;
        result.Z = a.Z;
        //figure out chunk/local coords
        result.Normalize();
        return result;
    }

What it more or less does is that after the first % that may turn up negative it adds the chunk size again - which for "proper" modulo does not change the result but fixes it for negatives.

Answer 2

Problem was, as @htmlcoderexe mentioned, the way % works in c#. But I'll accept solution from @DMGregory, which is the simpler one.

@stephane-hockenhull also explained this thing in more technical detail of bitwise & (Under my question), but I'll still write my own answer as a bit simpler interpretation for people like me who get confused easily :)

Modulo in c# is "symmetrical": 15%16 = 15 and -15%16 = -15, 16 % 16 = 0, -16 % 16 = 0.

But in my case(Where chunk 0 is actually a starting point and it goes 0 -> 15), this "symmetry" is actually what broke my count. Since first negative chunk starts at -1 and last block of that chunk will be -16th. So its -1 -> -16 rather than 0 -> 15 as at positives.

To find block position relative to chunk(in negatives), I added 16, so -1 + 16 = 15, which is seemingly correct so far(-1st block is indeed 16th block(or index of 15, we start at 0) in chunk).

Say, we want to find -15th block, -15 % 16 = -15, + 16 = 1, indeed, -15th block is 2nd block in the chunk.

But what block comes next before 2nd? Lets check: -16 % 16 = 0, + 16 = 16, and its wrong. -16th block is not 16th block in chunk, but actually its the 1st one. Hence, we need to make an exception here.

So "correct" version of my initial implementation would be:

if (x < 0)
{
    chunkRelativeX += size; //15
    if(x & size == 0){
      chunkRelativeX = 0;
    }
}
if (z < 0)
{
    chunkRelativeZ += size; //15
    if(x & size == 0){
      chunkRelativeX = 0;
    }
}

But instead of doing this as a multi step Ifs, it could be written using bitwise &(Which in itself contains that "exception" for n%16 = 0 cases at negatives, but for numbers that are power of 2 - 1) simply as:

if (x < 0)
{
    chunkRelativeX = x & (size - 1);
}
if (z < 0)
{
    chunkRelativeZ = z & (size - 1);
}