Just for clarify: This is not how the GPU “thinks”, it’s not how the calculations go.
The way calculations are performed is that each texel (pixel of the texture) occupies an area (not a discrete, infinitely small position) in the texture.
So the range [0…1] is just divided into 512 x 512 pieces.
So bottom-left pixel spans the area from (0, 0) to (1 / 512, 1 / 512).
So right neighbor of the bottom-left pixel spans area from (1 / 512, 0) to (2 / 512 / 1 / 512).
When the GPU “samples” the texture, it knows a position (x, y) which are floating-point coordinates at which we want to get “texture color”. So it looks in which pixel area is this (x, y). In case of “nearest” texture filtering, this is the final color.
In case of “linear” texture filtering, it gets more complicated, you can then think of texel centers forming a grid, and linear filtering is a linear combination of 4 colors.
It’s hard to explain it with pure words I cannot find a perfect image though. The https://en.wikipedia.org/wiki/Texture_filtering has nice links at the bottom.
In 3d, unlike my 2D texture, it’s not obvious how to tile them. If I create a bigger cube out of nine smaller cubes at the face boundaries two or more cubes will have overlapping co-ordinates. I can’t stack them the same way I can stack my textures.
If you want to have a cube with size 1, then it should have literally size 1, not something “a bit smaller”. So (-0.5, -0.5, -0.5) to (0.5, 0.5, 0.5) is a cube with size 1, with center exactly at (0, 0, 0). These are all floating-point numbers, or continuous numbers to speak more in “math language”, so the distance measurements work as you expect.
A smaller cube (like (-0.499, -0.499, -0.499) to (0.5, 0.5, 0.5)) will indeed have size < 1 and putting one such cube near another will reveal a small gap.
Note: I’m not sure what is the final goal, so just a word of warning: in 3D graphics on GPU, there are always inaccuracies. Be aware of this:
Take 10 cubes of size 1 (let’s assume size (-0.5, -0.5, -0.5) to (0.5, 0.5, 0.5) – you can experiment with it using X3D
Box node easily, or just doing it in Blender).
Duplicate and place them near each other, with centers as (0, 0, 0), (1, 0, 0), (2, 0, 0)…
Do their walls touch precisely? Mathematically speaking, yes, always.
Practically speaking, also yes… usually.
Since these are all calculations done on GPU using imprecise math, you may find that they don’t always touch precisely. It will be hard to see the problem using cubes actually, I think, but with an equivalent experiment using flat quads, you would sometimes (very very seldom, with certain specific camera angles) see black gap between quads. That’s because “vertex (0.5, 0.5, 0) translated by (9, 0, 0)” is not exactly the same as “vertex (-0.5, -0.5, 0) translated by (10, 0, 0)” due to imprecision of calculations.
E.g. that’s why Blender’s “Array” modifier doesn’t merely duplicate objects, it also merges the extreme vertexes. Same for Blender’s “Mirror” modifier. That is also why “T-junction” should be avoided when modeling, https://stackoverflow.com/questions/21593786/in-gouraud-shading-what-is-the-t-junction-issure-and-how-to-demonstrate-it-with .
If you want to have 2 polygons touching each other without any seam, ever, then edge vertexes of these polygons must be calculated using the same way (same positions in local space undergoing same transformations).
Does it matter? Depends on what you need to use. In some cases, you can completely avoid this note