How to create a TrackballCamera with the ArcCamera

I looked for a solution for a long time and took a closer look at the source code of the camera. I noticed two public variables: upperBetaLimit and lowerBetaLimit.

if these two variables are set to zero, the camera can be rotated on any axis!

        camera.upperBetaLimit = null;
        camera.lowerBetaLimit = null;

joyful programming! :slight_smile:


Hi Necips! Two months, and no further comments from others? hmm.

I’m not sure how a “trackball camera” should operate…

I noticed you mention “set to zero”, but then your demo lines set them to null. The two conditions are different, as you may now know.

In a “strict” sense, arcCameras never rotate around ANY local-to-themselves axis. They instead… “orbit” around their target. In a way, they are actually an “orbiting target camera”.

Under “standard” arcCam operations… arcCamera.beta is ALWAYS a value between 0.010 (lower limit) and 3.131 (upper limit). By default, arcCamera.beta values are NOT allowed to go completely to zero (directly above target) or to 3.14 (directly below target)… due to “epsilon values”. Epsilons are tiny values that are MOSTLY used to prevent divide-by-zero errors, which computers dislike.

Unfortunately… the terms “upper” and “lower” refer to the beta VALUES and not to the camera’s position… relative to its target.

In other words, upperBetaLimit sets how far downward the camera is allowed to vertically orbit BELOW the target, and lowerBetaLimit sets how far upward the camera is allowed to vertically orbit ABOVE the target. With me so far? The arcCamera is quite a complex piece of work… making it very powerful.

The primary first step is… in your mind… grapple with the difference between camera rotation, and camera-to-target orbit-angle (which affects camera rotation).

There is a scene that I used to test an arcCamera property named noRotationConstraint in line 48… which appears to do nothing, or I am not using it correctly. I think line 47 allowUpsideDown DOES work… under certain circumstances, but stretching the default limits… like lines 35/36 of PG #31… seem to allow camera inversion at “the poles” of the orbit, too.

Even though these playgrounds have no GROUND… keep in mind that we are NOT spinning the boxes, ever. We are orbiting the colored boxes, so take notice of the colors on the boxes… to know when you are nearing north-pole or south-pole of the orbits (or a straight/flat on-target beta==1.57 orbit-view).

Beta 0… looking straight-down at target from above vertical-orbit north pole.

Beta 1.57… looking straight-on at target from vertical-orbit equator.

Beta 3.14… looking straight-up at target from below vertical-orbit south pole.

(vertical orbits are sometimes called polar orbits)

Weird, huh? Goof around with this playground series… do some tests, make some more saves… get to know MY FAVE camera (if you wish). It’s got a rather complex personality… but is, generally, friendly and intelligent. :slight_smile: I hope I’ve been helpful, somehow. Sorry for the long wait… for discussions.

Got questions/comments? Let 's hear 'em. And if you learn something about the “beyond defaults” settings… and how they work-with arcCamera.allowUpsideDown and arcCamera.noRotationConstraint, DO teach us, okay? I need to tour the docs on arcRotateCamera a bit more.

And… you know… with docs… not always are the advanced things taught… because they make the docs too detailed and scary for us youngsters. :slight_smile: That is why the Docs Gods have both the “how to” series and the “101” series… speak nothing of the “legacy” series, or the “Notes from the Author/Source” info from API land. And don’t forget to search the old forum, too.

Needless to say, you COULD get a brain tumor… from studying all the magical things… about arcCam beta. After you learn it real well, then YOU have to teach it to ALL future beta-noobs… forever and ever. heh. Oh goody, eh? :smiley:

This subject MIGHT BE a good candidate for a semi-new thing called Playground-Based Tutorials (PBT’s)… a playground that teaches (in English, mostly) and auto-animates and highlights code-sections, teaching in a step-by-step walk-thru way. Only a few have been done, and is seemingly not important enough to receive dev funding.

can you see now the difference or how a trackball-camera should work? ^^

1 Like

Yeah, thx. Twin nulls. Cool. Totally free orbiting… or ALMOST totally free.

Drag diagonally… across imaginary vertical line thru center of screen, and the camera changes something as it crosses.

To see it happen, you might need camera inverted. Start by dragging downward until red sides face camera. THEN do the diagonal drag across screen X-center-line.

After further investigation, it is not always screen x-center. Sometimes the diagonal drag needs to continue further… before we see the “sudden direction change even though the drag direction was consistently diagonal”.

Likely caused by a sign-bit toggling at some point… either alpha or beta or both. It seems… that when .beta crosses from positive to negative or vice-versa, the camera does its sudden-direction-change (during the diagonal drag).