How to calculate translation with respect to rotation

Hi, everyone!

I’m a little new and know what I’m missing should be pretty obvious, so please excuse me…

Please check this playground:
https://www.babylonjs-playground.com/indexStable.html#UTINNB#3

Initially the camera faces “Object 0”. When you click any of the objects, the camera faces the clicked one.

What I’m failing to understand is how to make the camera to move in parallel of the line of the objects, keeping it’s rotation and traveling the distance between the “current” and the “new” (clicked) object.

Please check line 123 - the object pick handler is there.

I understand what should be done with the vectors to obtain the correct path - just don’t understand how to do this in BJS. Have read the 101 documents and other links and playgrounds multiple time - my head is just too thick for this at the moment.

Best regards,
Ilia.

Hi Ilia,

I think I understand the effect you’re going for, but I’m not 100% sure; does this look like what you’re intending?

https://www.babylonjs-playground.com/indexStable.html#UTINNB#4

(Disclaimer: I just put my additional animations in the _camera_point() function because that was convenient, even though they’d probably make more sense somewhere else. :upside_down_face: Sorry about that, but it should be easy to refactor if it’s actually what you were going for.)

Whether that or some other effect is what you’re going for, I’m guessing the confusion most likely arises from the ArcRotateCamera. The ArcRotateCamera is a bit of a special case that takes a little getting used to. You can’t (or, more accurately, you can but shouldn’t) try to control it using its position and rotation directly; instead, you’ll probably want to manipulate its alpha, beta, radius, and target (the last of which you’re already doing).

In the Playground I linked above, the only thing I changed from your code was to add extra animations that do nothing except keep the alpha, beta, and radius constant while the target is changing. Setting these causes the camera to recompute its position relative to its new target, giving a fairly smooth-looking interpolation. Not 100% sure if that’s what you were going for, but hopefully it’s at least a step in the right direction. :smiley:

2 Likes

@syntheticmagus

Thank you! This is exactly what was trying to accomplish. And the way you did it really elegant - now that I saw it…

Could you please tell me where will be the more appropriate place for the animations?

Also, as I’m trying to develop something moderately large, when have more questions should I start new thread every time or continue in this one?

Best regards,
Ilia.

Hi @ilia and welcome from me. It is better to mark this thread as solved and start a new thread for a new question. You can always add a link to a previous thread when necessary.

1 Like

Thank you!

Done :slight_smile:

1 Like

Glad it worked out!

+1 to what JohnK said, it’s best to open a new thread for each new problem you encounter. Threads are cheap. :smiley:

Regarding the “more appropriate place for the animations,” I only made that comment because you have a function called _camera_move, but I put the code that actually moves the camera someplace else; that just makes the names a little confusing. However, if the implementation above is doing approximately what you want, maybe the best way to solve the naming issue would be to just delete the _camera_move function and rename _camera_point to something like _animate_camera_target, just so that its name matches up with what it does.

@syntheticmagus

I see your point, thanks, had it restructured in the project…

Hi gang.

I made another one. :slight_smile:

https://www.babylonjs-playground.com/indexStable.html#UTINNB#6

Many/most BJS cameras have a property called .lockedTarget. It can be a mesh or a vec3.

It sort-of “freezes” the camera->target relationship/orientation, so when you move the .lockedTarget, the camera rides-along, automatically.

Lines 3-11… is an overload of camera… adding .aniLockedTarget() func. Most people say that overloading is unhealthy, but I don’t know any better. :slight_smile:

Doing this… makes things easy down at line 136 of the pick handler. No camera-pointing animation needed, in most cases. And we sneak-in a little nice easing, too.

Interesting/fancy code, ilia!

My code is not that pretty/structured, sorry. I code like I eat - a messy pig with no closures, and lots of grunting noises. :smiley:

2 Likes

Thanks @Wingnut!

Tried this - works like a charm :smile:!

About the code - usually work is big projects and mess is not a friend there… So try to have some clarity - sorry if this breaks some unspoken JS/3D coding rules.

For one that writes so many detailed answers on so many topics, you don’t strike neither as a beginner, nor as a messy person. But you got me wondering how do you get all that time…

Best regards,
Ilia.

1 Like

I know this is an old post, but thanks @Wingnut your explanation and example really helped me out just now :sunglasses: