I’ve been tinkering with my voxel engine, and I’ve hit a bit of a snag that’s got me scratching my head. So, each chunk in my engine is structured as a 3D array of blocks, specifically sized at 17 x 100 x 17. The width and length of these chunks are technically supposed to be 16, but I decided to pad the array to accommodate some neighboring chunk data.
When I want to set a block type, I need to convert the world coordinates into local chunk coordinates. The thing is, I’m not quite sure what the proper range of local coordinates should be. Should the conversion yield values from 0 to 16—because, technically, that’s the whole range including the edge—or should I only consider the valid data range between 1 and 15? This is crucial for how I access the block data.
To give you a better idea, here’s the code I’ve been working with for the world-to-local coordinate conversion:
“`cpp
//return range: from 0 to 15 (which is chunk_size – 1)
ivec3 world_to_local_coord(vec3 world_coord) {
ivec3 local_coord = {
static_cast
floor(world_coord.y),
static_cast
};
if (local_coord.x < 0) local_coord.x += 16;
if (local_coord.z < 0) local_coord.z += 16;
return local_coord;
}
```
From this code, it looks like I’m ending up with a range that spans from 0 to 15 for the x and z coordinates. However, with the padding, I'm concerned that I might be accessing out-of-bounds data or wrongly interpreting those edge cases. If the valid block data exists only from indices 1 to 15 in those dimensions, I might need to adjust my approach.
So what’s the consensus here? Should I be treating the coordinate space starting from 0 up to 16, or is my logic pushing me towards a range that's more like 1 to 15? And how do I properly implement that if I need to make the adjustments? I'd appreciate any insights or suggestions you might have!
Sounds like you’re having a classic voxel engine dilemma! From your description, it looks like the local chunk coordinates are effectively being rendered in a 0 to 15 range, which means you have 16 valid slots for blocks in both the x and z directions. This range includes the edges of the chunk—specifically, positions 0 and 15.
Since you’re using 17 x 100 x 17 for the chunk size, the extra padding around the edges is typically meant for handling neighboring chunks without causing out-of-bounds errors. So, you should definitely be using the full range from 0 to 15 for your local coordinates.
If the blocks you want to access are actually meant to be from indices 1 to 15 for some reason, then this could lead to out-of-bounds access for coordinates (0, y, 0) or (15, y, 15). Given your current logic that calculates local coordinates, it’s actually optimal to treat the coordinate space as 0 to 15.
So here’s what you can do:
local_coord.xandlocal_coord.zsince they will range from 0 to 15.To sum it up, maintain the range of 0 to 15 for accessing your blocks. You’re doing great for a rookie, and it’s totally normal to get tangled in these concepts. Just take it one step at a time!
In your scenario, since the chunk is internally padded to 17x100x17 to account for neighboring chunks, the valid block data for your actual chunk typically spans indices from 1 to 16 inclusive, where indices 0 and 16 represent padding or neighboring chunk data. Your current conversion function produces local coordinates from 0 to 15, corresponding to a regular 16×16 chunk without padding. This indeed leads to potential confusion or indexing errors, as you’re not properly leveraging the padding area you’ve intentionally added.
To correctly handle your padded chunk structure, you should offset your local coordinates by 1, effectively adjusting the range from 1 to 16 inclusive in both x and z directions. Specifically, after computing your coordinates (0-15), simply add an offset of +1 before accessing the chunk array data. For example, something like
local_coord.x += 1;andlocal_coord.z += 1;immediately before indexing. This minor adjustment ensures that your function correctly aligns with the data grid and safely utilizes padded regions intended for neighbor chunk interactions without introducing indexing issues or causing off-by-one bugs.