[Solved] OrbitControls max polar angle = Infinity?

Questions
,
1

Hello everyone,
First, I want to thank all the people working on this awesome library! I hope one day I’ll join you as well.
I started using it recently, so please be gentle if my question is somehow stupid :innocent: .
So, my question is very simple : why is Orbitcontrols max polar angle clamped at math.pi?
I want to have something like trackballControls which can rotate my camera to infinity vertically .
If I’m not wrong trackball is deprecated.
Is there a way to do this ?

2

There is no such thing as a stupid question but this one… nah I’m kidding :slight_smile:

Imagine you’re in a museum and your observing a vase that’s on a stand in the middle of the room. You can crouch, you can rise up on your toes, stick your head real close to the glass. The floor is below you, the ceiling is above you no matter what you do.

Go around the stand, still the same situation.

What would happen if you grabbed the vase and did a hand stand? Trackball controls.

If you go past the pi limit you end up upside down and it’s simply ends up not being orbit controls.

There is a gimbal lock problem but i think that can be avoided, but i think the end result would feel weird. Once past the limit you’d only be upside down (not sideways) so you’d end up doing the same thing the orbit controls do normally just upside down. Until you go past the poles again, and flip back. Where would this be useful?

3 Likes
3

A more technical answer to this limitation is the relation of OrbitControls to the lookAt() function. @WestLangley has described this fact in the following thread:

When the camera passes over the “north” and “south” poles, it flips so as to stay right-side-up. The camera’s up-vector is (0, 1, 0) by default.

The limitation of the polar angle is necessary to avoid these mentioned flips. lookAt() needs the rotation of the camera but also the up vector for correct orientation.

So no, with the current implementation of OrbitControls it is not possible to implement your desired behavior.

That’s new to me. Where have you read that?

1 Like
4

Thanks for your reply. Very explanatory example, I understood the issue clearly!

5

Thanks for your reply!

I got the general idea. I see now why it’s implemented this way.

Well actually i couldn’t find it anywhere on the documentation(if i’m not wrong again, it used to be along with other controls) .
Plus all the posts I saw regarding it were at least one year old, and I couldn’t properly import it from the npm three module so I assumed it was not used anymore.
Anyway I imported it manually from js/example/controls and it seems to be working great. :sunglasses:
EDIT : Spell check + got it to work

1 Like
6

I actually landed on this question because I was searching for the same functionality. To answer your question of where this would be useful is in a space application where there is no such thing as “upside down” and I need a full 360 degree rotation horizontally and vertically.

7

As mentioned in the thread you can use trackball controls for this behaviour… three.js examples

1 Like
8

Ah, thanks for pointing that out. I didn’t read the replies carefully enough. :man_facepalming:

1 Like
9

the question is relivant, the trackball can be usefull with flight simulation, this can be achieve by disabling the orbitcontrols

10

In my case, I have a building in the center of my scene. I want to rotate around it via OrbitControls and I want the autoRotation of OrbitControls. I don’t want the 360 degrees rotation and I don’t want that the floor gets upside down (no camera rolling). So OrbitControls fits all my needs. There is just one thing: I want to be able to toggle my perspective and lock it when I click on a button. Therefor, I limit my min and maxPolarAngle to be 0. That way, all my controls work as desired and just the rotationY is fixed. However, this would mean, that my camera goes above the target and I get a gimbal lock.

1 Like