hi,
I am having trouble with two AABB boxes and the collision response / resolution. The main problem is, that I do not know how to get out a overlapped box from another AABB box.
What is the receipe to resolve a detected collision?
screenshot: you can see three boxes. the blue one is the origin and the red one is the new position. the target/end position should be the green one (manually positioned)
are you calculating by hand or use bullet?
If all your boxes are unit boxes starting/ending at exact coordinates, then this problem becomes a lot simplier. Do a raycast, find contact point and convert it to 3d cell coordinates.Only tricky point will be to check which direction they ray is crossing the plane on boundary, as contact point will give you location exactly (within epsilon) between the cells.
Thats if you want to do it for manual interaction/positioning blocks following the mouse etc. If you want to do actual physics simulations of this block moving, hitting obstacle and then sliding down into proper position, it is going to be a lot more complicated and probably jbullet will be a starting point rather than plain collissions.
thank you for quick answer :). I can not use jbullet, because my “world” is endless and dynamic. all boxes have a fixed/unit position (and size 1x1x1). I want to programm my own player movement with gravity so I have to slide the blue box (player) along the wall. Is there another way than just to raycast? Not shure if this works. The collision must be as fast and accurate as possible because of there will be some npcs and other player which need to collide with the world.
Are you just trying to figure out where to place the box? On a grid this is super easy. Just step over the grid until you find a collision.
For player collision just see how far each axis penetrates and take the shortest one.
if i take the shortest, the result would be this 
:
vel2
x 0.45123863
y 0.36369467
z 1.3165388
vel3
x 0.45123863
y 0.36369467
z 0.3165388
this is how I obtain the values
[java]
public float calculateXOffset(BoundingBox bb, float x)
{
Vector3f min = bb.getMin(null);
Vector3f max = bb.getMax(null);
if (this.maxY > min.y && this.minY min.z && this.minZ 0 && this.maxX >= min.x)
{
offset = min.x - this.maxX;
if (offset < x)
{
x = offset;
return x;
}
}
if (x < 0 && this.minX x)
{
x = offset;
}
}
}
}
return x;
}
[/java]
x is the original velocity vector from the blue box to the red box
I can not post my code correctly oO
http://www.alrik-online.de/code.txt
@alrik said: if i take the shortest, the result would be this :/ :vel2
x 0.45123863
y 0.36369467
z 1.3165388
vel3
x 0.45123863
y 0.36369467
z 0.3165388
Your player can move more than a block in a single frame?!?! You will have lots of problems then.
I use multisampling to make sure, that the collision is detected. one block has a size of (1,1,1) so if the player moves faster than 0.5, I split the velocity and check the collisions multiple times.
@alrik said: I use multisampling to make sure, that the collision is detected. one block has a size of (1,1,1) so if the player moves faster than 0.5, I split the velocity and check the collisions multiple times.
In your picture, the player would be moving almost three blocks or so. If they are one meter than that’s 3 meters per frame… or at 60 FPS that’s 180 meters per second. That’s really fast.
On the other hand, it would be bad to have player teleporting through the wall just because of gc hicckup 
in these screenshots, I only simulate collision detection… the important part is the collision response. regardless which speed, the collision is always detected (because of multisampling)
Then clip the ray to the box and place the other box on the side of the ray’s origin. This math is not very hard so I have trouble understanding the issues sometimes.
in this case the ray does not work
how did you solve this in mythruna`?
In Mythruna, players can’t move at 180 meters per second. And if they could, they could walk through a single block.
When I did the camera collision manually, I made sure to iterate the camera physics extra times if FPS was slow. Now my physics engine operates at a fixed tick no matter how slow it is actually running. On a crappy machine, everything will just move slower… but it cannot be otherwise. Physics engines really hate large time steps unless you implement sweeps for everything. And as you’ve discovered, that’s slow and painful. Also, sweeps will never be accurate without getting really complicated. For example, what if the gray block was also moving?
For world picking, I just step over the grid. I keep steps in each of the x,y,z planes and add whatever delta grows the final ray by the shortest amount and then check to see if I’ve hit the side of a block. If not… keep going. Maybe it could be adapted for sweeps… but in Mythruna, not everything is a block which complicates physics-style collision detection.