I have have this:
modular arithmetic AABB.pdf (112.9 KB)
I am not sure if your thing handles the case when A > B correctly, that is when the interval loops around. If that happens then you can have X<A and yet it can still be within <A,B>.
I have an example in the PDF where I have the logic for it
if the space wraps around by N=5, that is: only numbers 0,1,2,3,4 exist, then
if you pick the interval going from 4 across the boundary to 2 (interval A=4, B=2) then the number X=1 is within that interval <A,B>
but your X>A at the begining does not handle it
EDIT:
Hey actually you can make it quite simple:
bool a = A<=X;
bool b = X<=B;
return (a && b) || (A>B && (a || b));
where 0 <= A,B,X < M
A is the beggining of the interval, B is the end of the interval, M is the boundary (the modulo).
this is the number line when A<B:
0--------X1---------A=====X2=====B-------X3-------M
X2 is inside the interval
when A>B:
0=====X1=====B---------X2--------A====X3====M
X1 and X3 are in the interval
A > B is not supposed to happen, why the fuck would it happen in a programming environment, unless somehow the bounding box is bigger than the entire world
And yes my case should handle B going out of bounds and looping back to A > B just fine. But A > B in on itself should not happen otherwise
wait why do you say my case doesnt handle it? there is very specifically a handler for it??? Like that handler was the very point of my post?
Again, copypasting my handler, can you not see the part of X%M < B%M ?
X>A and (if (B>M or B<A) then (X%M < B%M or X<M) else X<B)
oh i see a bug in the handler, yeah when it wraps around the X>A needs to be on an OR instead of an AND
point is, it is possible to figure it out just fine, and therefore its possible to use modulo for wrapping bounding boxes without needing to slice them into pieces.
The condition changes depending on if A < B or A > B. As I put it before:
bool a = A<=X;
bool b = X<=B;
return (a && b) || (A>B && (a || b));
which means (is equivalent to):
bool a = A<=X;
bool b = X<=B;
if(A<=B) {
return a && b;
}else{
return a || b;
}
you forgot to modulo B by the boundary which is crucial in case B overflows the border
Thanks for all the help, i think i got something proper that doesnt make multiple boxes implemented now
I assumed that all the numbers are already modulo M, that is they actually fall within the existing world. There is no way it should overflow the border, otherwise your code sucks. Its like saying that you have an unsigned integer and wanting to put -1 into it. Its an error. Its is like saying that you want to have a byte and store a number bigger than 255 into it.
some funny results. You can see that the blocks get stretched in 2 ways when going up. The first is because i dont use an exponential function to correct the aspect ration height wise when going up.
And the second stretch is that the block gets wider one side than it gets another. This is a fundemental mathematical flaw i believe. But there is actually one case where the XZ aspect ratio stay consistent… When the world XZ size is the same, But this would result in a self intersecting world.
Also for the OG 2d version gravity beetwen planets has now been implemented, which means you can actually orbit around them now. i also had to figure out a bug on why gravity was reversed a little in space. turns out my on planet and off planet Y coordinate is reversed. this isnt fixed yet, but i should really fix it asap. (with many other issues that comes from moving in and out of planets)
You might have noticed in some earlier post that suddenly there was a small part of the torus on the other side which wasnt rendered. This was due to some bug in the code where it didnt handle worlds of even numbers correctly.
Its now fixed(ok it was 2 lines of code) regardless enjoy this photo of the inside of a hyperdonut