3d Collision method that allows rotation

[Omninaut]

So what im looking for is a little complicated to explain, but it feels like it should be pretty easy. ill explain the best i can.
Im making a 3d project and i currently have AABB collision implemented and it works great but it feels limiting since nothing can rotate (other than appearance, the collisions dont follow rotations). im trying to think of a method to calculate the points or apply an offset to the variables to create a rotation. Basically, the AABB collision i have gets 3 size variables and adds each size from origin to create a box:
Not the code but a simplified example

create_bb(8,8,8);

function create_bb(_1, _2, _3) {

//create 6 sides for cube
xmin = x - _1;
xmax = x + _1;

ymin = y - _2;
ymax = y + _2;

zmin = z - _3;
zmax = z + _3;

}

this makes each side the check. so the center, all 4 sizes of each side have the same location on whatever axis they're made from. so the Xmin wall has all 4 verts the same x value. thats normal and pretty standard for AABB collisions. but what im wondering is if theres an easy way to add a transform variable to the locations or something that makes rotation possible. even if its only on the Z axis. (in case i get my rotation axis mixed up i mean the way you could rotate a cube on a desk without it ever balancing on an edge). The main reason i want to add this is i use this collision method for the player and for buildings. it works because both are boxy, but when the player rotates for changing facing direction, id like the collision box to rotate as well. this axis rotation is the same as image_angle for a top down 2d games. i just need that rotation type but in 3d.
if it isnt possible to add rotations without making an entirely new system what would be the next simplest and easiest collision check method that would allow rotation. i dont need any other collision shapes. at most id like to have access to all 3 axis rotations for cubes because things like walking up slopes for stairs or bridges would be nice. I would think it would be most accurate and forward thinking to define all 8 verts x,y,z positions. but idk how the checks would go and it seems like couple hundred line script that i wouldnt know how to make. any thoughts or information would be much appreciated. Thank you in advance.

 

[kburkhart84]

I don't have the code, but more often than not, efficient 3d collisions are faked using spheres and axis aligned capsules(just elongated spheres). Most games I've seen just approximate like that and don't actually drill down into anything more specific. In many cases, you can just check for multiple spheres that take up the space of the model for an object, and that will be faster than trying to mess with rotated primitives(or even worse triangle-based collisions).

If you really need more though, you can always look up formulas for primitive based collisions. They would include AABBs, rotated BBs, spheres, cylinders, capsules, and likely a couple more primitives as well. But I highly suggest just approximating with spheres instead. Spheres only need a quick distance check to confirm collision, and that is much faster than most if not all the alternatives.

Final note, if you need more performance, and/or really need the other collision stuff(like primitives), you can always add on some basic early-outs. That means you can use an AABB or sphere check to early-out, and then check the actual primitives only if the sphere/AABB check passes. On top of that early-out, you can ALSO add an actual space partitioning system, which can be more complicated, but serves for early outs as well, as you avoiding ever checking things that aren't close to each other. There is overhead with such a thing though, both in performance and in dev time. But if you have lots of objects that can all collide with each other and sphere checks aren't good enough, you may need to add such a system.