I have have this:
modular arithmetic AABB.pdf (112.9 KB)
2 Likes
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
2 Likes
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
3 Likes
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
2 Likes
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.
2 Likes
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;
}
3 Likes
you forgot to modulo B by the boundary which is crucial in case B overflows the border
2 Likes
Thanks for all the help, i think i got something proper that doesnt make multiple boxes implemented now
2 Likes
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.
4 Likes
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)
2 Likes
just did the exponential fix. and as imagined theres floating point problems, But fortunetly enough the exponential problems gets less noticable at larger planet sizes
3 Likes
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
3 Likes
Hello, work is slowly being done in the background. thought id just share this fun glitch i got when dealing with 3D worldgen noise and LODS, yes this glitch does in fact let you see through the world. thought it looked super cool.
4 Likes
quick question, For a regular minecraft world mapped to a cylindrical world, the transformation needed on the height and width would need to be exponential as the blocks go up on the world. but an issue ive come across is that the depth does not scale at all when going up, Thus leading to an inconsistent aspect ratio as the blocks go up. (the video shows me enforcing the aspect ratio)
so my question is, anyone know of a solution which maintains the aspect ratio?
preferably one which doesn’t include scaling the world to ginormous size to minimize the artifacts. Which is what my projects shown above do.
2 Likes
[I typed a whole thing just about solid tori because I misread what you were saying, though it still applies, everything about this cylinder shape is the same for a solid torus except solid tori also have unrelated extra difficulties in representation (though they are not that big a deal with scale)]
There is no solution, the shape you are making is the product of a disc and a line, when you move closer to the center of the disc the loop around the center becomes shorter, whereas nothing about traveling on the line dimension changes. The shape which would let you keep the same aspect ratio is a ball (a 3-disc) (not a sphere, a ball is the volume and a sphere is the boundary), though I suspect you don’t want to do this
edit: thinking about it, there might be some other shapes which would work?? but I am not a topologist, and also the ones I think of are all extremely weird and not things you would want lol.
2 Likes
I understand, i have a solution in the works which involves scaling the size of the cubes depending on how far you are from the center. This keeps everything correct locally at least, but it makes far away object (thinking up and down here) Short or Long.
Now for as to why i asked this in relation to a cylinder and not tori. I have not yet understood how conformal mapping works. Which is another problem needing to be solved to reduce artifacts
1 Like
it scales now based on the height of the player, hopefully larger worlds can reduce the far away artifacts
2 Likes
conformality was a much harder topic to solve than the previous problem, regardless, it has been solved. For now. this is currently only 2d to 3d so far, ill have to somehow merge the automatic exponential scaling from the previous work into the conformal torus.
2 Likes
would you rather, A or B
A: the simples solution, but causes blocks to be off grid
B: technically more correct solution, but would require changing box height as we move around the torus, not that bad tbh since we already need to change the width as we go up and down.
im thinking B might be better
1 Like