ArcRotateCamera axes are confusing


Either I’m having a hard time understanding Babylon’s axes setup, specifically as it relates to ArcRotateCamera, or the API is unclear.

See the above playground. My goal is a rectangular ground, kind of like a soccer field, and I’m trying to line the field. Am I right in assuming that red is x, green is y, and and blue is z, by default?

I want the default view to be top-down (to start) and looking at the field horizontally. However, setting the alpha and beta to 0, 0 (like it seems to indicate in the docs) puts the “width” of the field “vertically” in the camera, and the “height” of the field “horizontally”. That’s my first issue.

Then I try to move the ball on the positive x axis, which I would assume should move the ball to the right, but instead it moves down.

Then I try to make a ribbon (my field lines, eventually), and when i try to make it from x=-2 to x=2 it stretches “vertically” rather than "horizontally, and is pointed at what seems to be the z direction (which I would expect to be “up”. If I also want the ribbon to lie 1 unit to the “right” I seem to have to use the Z axis.

Then in my own project, putting ribbons to the “left” side of the field or the “back sideline” of the field ended up having to use several different variations of the “directions” option…? I would understand if I had my “up” wrong and had to orient them all “up”, but having to trial and error different vector facings was driving me crazy.

I tried messing with some different values of alpha, beta and upVector based on this playground, but I honestly just got more confused.

That’s all to say I’m pretty sure I’m missing something fundamental about Babylon’s axis system or the API because after like 3 hours of banging my head, I only had lined about half of the field and gave up in frustration. Anyone have an idea what I’m doing wrong?? Many thanks in advance.

Hi and welcome to the Forum.
I can understand your frustration, but I think you’re not that far from it :hugs:.
May be the arcRotateCamera is not your best choice for modelling on axes. It’s an orbital camera and yes, speaking of which, the 0 on the alpha does NOT put it ‘in the width’ (as you say). In fact, the center is a quarter of a revolution (Math.PI/2), which will put it ‘in the width’, like this:

So, no, the ground is not sideways (width is X and height is Z). It’s just the camera.
And I’m also not sure about your other comments. The sphere and ribbon (in the PG you shared) seem to react normally on their axis. I can’t see anything wrong with this.
But then, if by any means you are making imports, it’s important to mention that BJS is a ‘left-handed system’. So when importing from right-handed the z-Axis will be inverted and the Y will be rotated 180° (in regards to the camera/world axis).

I hope this helps (a little) and hope you will eventually figure it out… and next, enjoy it :grin:
Else, let us know and meanwhile, have a great day :sunglasses:

Edit: Forgot to mention that I also found it weird at first, having the arc rotate camera not set a zero facing the z-axis… but eventually, you’ll get used to it (once you know it :grin:)


First, thanks for the reply, mawa.

I think I’m getting it, the Math.PI/2 part helped me make sense of it.

I DO think I want an ArcRotateCamera, because I also want the user to be able to move off from the top view, it’s just “top” that is the default.

I have my example updated to show some of my confusion with line facing: playground.

As you can see, the “front” and "back line renders as I’d expect, but only once I’ve set its direction to z=1, which doesn’t seem to correspond with my intuition that I’d like it to face “up” (y=1).

Then for the “goal lines” they need their own facing of x=1, which is even more confusing… I think maybe I’m not understanding something about greased lines and default non-camera facing direction.

I think my intuition was hoping I wouldn’t need a separate facing direction for each line, depending on where it is or the direction it runs, cause I want them to all face “up”.

I see. Sorry, it must be in the ribbon options of greasedLines ribbon (check the doc).
I suppose you want it to look something like the attach PG (warning: this is just a dirty mock-up :grin: :rofl:) I’m sorry I don’t have the time to double-check on the ‘clean’ version (but it’s certainly in the doc for greasedLines). I need to go rush make dinner :green_salad: :sweat_smile:. Cya later,


Ok, just quickly checked and may be there isn’t (not with the ribbon version or else I missed it). On the other hand if I create a plane or a standard ribbon, I’m kind of in the same situation. May be the ribbon is not what you need. Let me just quickly check this with the creator cc @roland

Hi there! :slight_smile:

When you use non camera facing mode by setting the ribbonOptions parameter and you draw lines in different directions by a single GreasedLine instance you must set the directions for each line. Just imagine how could the code guess in which direction you want to apply the width of the line when you define the line just by setting the start and the end of the line, just by to 3D points. Actaully there is a ribbonOptions parameter:

directionsAutoMode: BABYLON.GreasedLineRibbonAutoDirectionMode.AUTO_DIRECTIONS_ENHANCED,

which intended to solve this problem but it couldn’t do magic :magic_wand: or it’s not enough sophisticated. :see_no_evil:

After a while of thinking: :slight_smile:

I believe I could calculate the right slope (defined by one direction vector only in the directions parameter) of the ‘widhthened’ line just by taking that one direction and the direction of the line in 3D space. This way all the lines will be facing to the same one direction. I’ll have a look at it today while fixing another issue reported by @phill2mj Is there a way to lazy load lines of varying widths?

Thanks @phill2mj for playing around with GreasedLine and thanks for not loosing your mind :smiley:


Thanks for the response! I think they’re what I needed to create a dynamic field the way I want it to accept configurable lines and sizes. Glad I’m on the right track!

Guys, I thought about it and I think the best way will be adding a new GreasedLineRibbonAutoDirectionMode:

export enum GreasedLineRibbonAutoDirectionMode {

In this mode the slope of the line (directions property of ribbonOptions) will be automatically calculated ensuring that the line will face to directions: Vector3 when created.

@phill2mj in your case you could:

ribbonOptions: {
  directionsAutoMode: BABYLON.GreasedLineRibbonAutoDirectionMode.AUTO_DIRECTIONS_FACE_TO
  directions: BABYLON.Vector3.Up() 

and all th lines will be facing up.

1 Like


I’m new here, so what kind of timeline is realistic for changes like this to end up in a release?

It depends on multiple factors. I believe I can create the PR (pull request with the changed code) until tomorrow and it could be reviewed in 1-2 days and in another 1-2 days it will be merged into the babylon.js code and will be available in the Playground.

However just right after I create a PR, the systrem automaically generates a link to a temporary PG where you can test the new code immediately.

Ok! No rush whatsoever, just curious.

1 Like

All you have to do is to set directions as a single Vector3 which is the direction which the lines should face to and set the directionsAutoMode to:

        ribbonOptions: {
            directions: BABYLON.Vector3.UpReadOnly,
            directionsAutoMode: BABYLON.GreasedLineRibbonAutoDirectionMode.AUTO_DIRECTIONS_FACE_TO

and you don’t have to set directions for each line to different values separately.


@phill2mj please mark this answer as Solution

1 Like

Awesome! that should save me a good bit of fuss :slight_smile:

1 Like

You’re the man :man_superhero: That’s even beyond what you can do from a regular ribbon. Another nice adding to this beautiful toy/tool :child: :smiley:

1 Like


The PR is still waiting to be merged:

done :slight_smile:

1 Like