Download

Best way to change the point around which an actor rotates without moving the actor itself?

I’m trying to make a ball-rolling game where the user controls and rotates the world around the ball rather than the ball itself. I made a container Actor that is pretty much just a simple sphere component. The actual level and tangible obstacles are children of this container, which is what I rotate to rotate the rest of the world.

The problem is that the location of the container’s rotation point is its center, so if the ball is far away from it, it’ll wind up getting catapulted and whatnot. I’ve been trying to have the rotation point follow the ball by having the actual container follow the ball, while all of the children pieces of the container get translated in the opposite direction to give the appearance they are staying still.

Is there a better or more efficient way to do something like this? I feel like my hacky method is really inefficient as my game’s performance is pretty poor despite its simplicity. Another thing I tried was programmatically changing the pivot point of the container actor, but it seemed like it had no effect at all.

You are looking for the RotateVectorAroundAxis blueprint node
It takes a vector (A: your point you want rotated), an angle (B: the amount of rotation), and an axis as a vector (C: this would be 0,0,1 if you wanted it rotated by the Z-axis).

So if you want to move point A relative to something else, you subtract the “something else” so that you have point A in terms of your other object, you do RotateVectorAroundAxis to calculate where your point A will move to, then you re-add the location of “something else” giving you the new vector of where you would be had you rotated around the other object by the given rotation. If you need this as a world rotation you can then use the vector of point A minus “something else’s” location to get you a rotator in world space.

Hope that helped :slight_smile: if so +1 is appreciated

Moving the entire world sounds expensive - all that geometry will be moving inside the physics engine every frame, which isn’t cheap. Plus if you have any other physics objects and constrains in the world all that needs to move every frame too. To me this is a question of relative frame. Rather than moving the world around the absolute geometry-frame, you could try keeping the level static and moving the camera, whilst changing the direction of gravity to be camera relative each frame ? Your problem then becomes one of managing inertia, but depending on your game mechanics this could be a large or small problem.

It’s worth playing with this approach though, as it’s going to be much much lighter performance-wise.