<cite>@wezrule said:</cite>
Oh rly? I wouldn't have expected it to work at all ^^ so that's surprising
Also I had a look at the transformInverseVector() source, and it would be useful for what you want. Although it does reverse all transformations, so you would need to add scale and translation again. Or you could implement the parts you need. I think this should work (not tried it though).
[java]
Vector3f vec = collisionVec.substract(cube.getLocalTranslation ());
Vector3f anotherVec = cube.getLocalRotation ().inverse().mult(vec);
Vector3f originalVec = cube.getLocalTranslation ().add(anotherVec);
[/java]
Another way I potentially found while messing around with this on paper is (completely untested):
(Original Normal - Collision Normal) + Collision Point
You can calculate the “Original normal” using the first equation I posted. I’m quite tired, so I might be talking jibberish right now xD
The first equation sort of works, though it’s still giving me just close numbers and not exact numbers. I’m wondering if I’m just not going to be able to get the exact point but only really close. I tried the equation you made on paper, but it didn’t work at all 
There’s a reason it needs to be so precise, and it’s because the cube is actually a giant cube made up of hundreds of smaller cubes (48x48x48 cubes). I need to find the cube that was clicked, and remove it, or if I am adding a cube I need to find the face clicked and add a cube relative to the face clicked. Finding the face clicked is simple when the cube isn’t rotated, because when you click any face of the cube, one of your coordinates will be a whole number, since the cube is sized exactly 3f x 3f x 3f. So on one face it may look like (48.0, 31.2639, 24.4475) and another maybe (45.3423, 42.0, 13.4250). Notice how the whole numbers are divisible by 3f, the size of the cube. So determining which axis is divisible by 3f, I can determine which face was clicked. This is a problem when “unrotating” the point, because it doesn’t give me exact numbers. So what should be 48.0 may be 48.0009 or 47.6653 or something close. You would think, well, just round the number! But that doesn’t work sometimes as there are times when two numbers end up being rounded to whole numbers divisible by three, so the code picks the first axis it encounters divisible by three, and you end up replacing cubes sometimes. I hope that made sense.
Of course none of this would work if the wrong block was selected, and that also happens sometimes. Because the cube selected is determined by dividing the vector by the size of the cube, 3f, and flooring it, if one number is even a little off, it can choose the next cube over. So sometimes when I select the cube which should be 0,0,0 I get a cube 0,-1,0 or 1,0,0 etc.
I hope a tiny bit of that made sense. If it helps I can make a video later.
(You might be noticing by now where the Minecraft idea comes into play. I am making planets out of cubes… cube planets. 
)
