ArcRotateCamera - Change .alpha Rotate Axis

[Rolento]

I am using BABYLON.ArcRotateCamera to visualise and move through my 3D scene. However, I am trying to change the way in which the .alpha rotation works.  

My understanding of ArcRotateCamera:

By default the .aplha is used to rotate the camera around the "Y" axis and .beta rotates the camera around "X" axis.

What I want ArcRotateCamera to do:

I want to change the .alpha rotation such that it rotates around the "Z" axis instead of the default "Y" axis.  

Does anyone know how I can do ths?

FYI - I have experimented with creating custom camera inputs (which is great for manipulating mouse buttons/wheel actions) but I can see no way obvious of achieving the above, hence there is probably another approach that is needed.

Thanks...

[Wingnut]

Hi again, Rolento!  I see you got yourself a little forum error... and some message "echo".  Interesting.  (Wingy whacks on the forum software with a Nerf baseball bat, and grins)

Okay, I'm about the LAST person you would want... working this issue.  I dislike BJS camera inputs system... beyond your wildest imaginations.  Actually, it is probably fine, but it could sure use another layer of friendliness atop.

First, know that I have NO IDEA what I am doing.  There are people around here that are MUCH better at this, than I.  But, you've waited 23 hours, PLUS all the work you went through earlier... fighting with camera inputs.  You deserve a break, and what little info I can give.  So here it is, briefly, and no promises that I am saying anything correct.  I am not an expert, and not even close to one.

To get started, I wanted to bring a JS version of Babylon.js/src/Cameras/Inputs/babylon.arcrotatecamera.input.pointers.ts... into the playground.  I did a playground search for pertinent keyword... http://doc.babylonjs.com/playground?q=ArcRotateCameraPointersInput and got 50 results.  I used the 18KHF6#5 PG, and as you can see, it has the code we want to "hack"... already put into the playground (at the top).  KEEP in mind, it might not be default framework version! (see the console.log(test) in there?)

So, THAT version of ArcRotateCameraPointersInput COULD BE OLD and COULD ALREADY BE CUSTOMIZED. 

That said, let's go hacking... with the feeble-minded Wingnut... who is like a baby with a chainsaw.  Count-on pursuing in wrong directions (wild goose chases).  And, count-on Wingnut taking the LONG WAY and/or REAL OLD SCHOOL way... to do something that COULD be simple.

Here we go.  http://www.babylonjs-playground.com/#18KHF6#7  There it is... z-rotation on an arc cam... when pointer drag left-right.  Holy crap, batman.  Don't bother trying the mousewheel... it's still kind of broken.  Might be able to fix it somewhat... by make camgiz... super-tiny.  I think the mousewheel takes the camera into the camgiz "box" and the camera can't see out of it (from its inside).

The camera gizmo is generally needed... because arcCams don't like spinning on z axis (without view matrix wrenchings).  But when arc cam is parented to camera gizmo, we can force him around... such as lines 79-80.  Here, I scale-down the offsetX value and feed it to camera gizmo rot z.

The rest of the hacking is in lines 170-190.  When parenting a camera to a gizmo, we need to null-out any camera transforms (positions/rotations) before parenting to camera gizmo.  So, line 170 has initial settings that sort of "square-up" the camera with the camera gizmo box.  We want to avoid using camera setTarget, and instead... if using ANYTHING... we want to use a camera gizmo lookAt(sometarget). The camera gizmo is now... "alpha boss"   He has decided to route offsetX... to camera.rotation.z... using force. 

And that's it.  That's all I have accomplished... but not bad for 2 hours and only one cup of coffee, so far.   

I hope some of this can help you.  I hope I didn't show you "dangerous" things or send you on any goose chases.   Perhaps, you have already been this far down this trail.   Camera inputs pretty much suck, huh?  We have built ourselves a device-to-camera wiring system that is unscalable, and completely not ready for the 25000 new input devices that will be invented in the next 10 years.  This system... is an alligator yet to be wrestled, in my opinion.  I had big hopes for the universal camera.  I thought... alright... and it uses universalInputs?  Nooo.  It still used attachAnEventCollision like current camera inputs.

And I think SOME people are forgetting that device inputs are just as likely to be wired to actionManagers... as they are cameras.  We haven't even BEGUN to address actionManager inputs and inputManagers.  It's all going to turn ugly.    What we really need is a central inputs actionManager.  It can route inputs to lights, mesh, cameras, properties, just a dream come true.  Last time I proposed this, it didn't meet with applause from BJS HQ.    That's very normal... for my big fat (implausible) dreams/aspirations. hehe.

Still, I would love to see a real nice "patch panel" type of thing.  Wire anything to anything... and it's user friendly.  *sigh*.  Maybe someday.

[Rolento]

Hi Wingnut

I love your disclaimer - but whatever help you can provide will always be well received by me, so shoot away!

I just finished reading your post and at first glance it looks like it provides what I am looking for (so a big thanks to you once again!).  I have not got into the nuts and bolts of what you have done (im going to do that this evening) but fingers crossed there is no black magic and I can manipulate the code as needed. 

Actually - the one area I would like to learn more about is "camera.camgiz".  I have no idea how you know about this, when I search the BabylonJS documentation I find no references to it, so this does feel like were dabbling with the dark arts!   If you know of a page that explains camgiz that would be great, otherwise I guess you have to delve into the code?

 

Quote

 

Still, I would love to see a real nice "patch panel" type of thing.  Wire anything to > anything... and it's user friendly.  *sigh*.  Maybe someday.

 

The core BGS team in fairness have done a great job with camera and inputs, but I have to agree with your above request. An intuitive easy to use configurable system enabling events/inputs to be linked to objects of varying types would be spot on!  Fingers and toes crossed.

If I make any useful tweaks to your code I will repost what I have done hoping it might help others.

IF anyone has any other pointers please shout...

[Wingnut]

Oh, thanks for the kind words, Rolento... and yeah... camera.camgiz is just something I made happen.  It's called "overloading", I think.  In line 179, I know there is an object called 'camera' that exists, and I just created an object called camgiz... in the previous line.  SO... I just crammed that new object into a NEW "property" or "pocket"... on the camera object.  Its not documented because... I just forced it to exist with line 179.  Its like injecting gizmo under the camera's skin... and saying "Here, carry this 'widget' along with you, wherever you go, from now-on" 

Now you're making custom versions of ArcRotateCameraPointersInput.  I think... you get full control, now... once you learn to drive that input code.

Up in line 80, where the little modification to the input code happens...  camera.gizmo gets used (repeatedly).  _this.camera.camgiz.rotation.  The engine uses the code in our playground, now (instead of its old version).   The engine uses something stored in our new "pocket". 

It's not at all "normal" so it won't be documented.  It's a demented mad-scientist activity.  Intervening.  Hijacking BJS framework code, and banging on it with a hammer, and seeing what happens.    FUN!

Duct-taping and hot-wiring stuff together, and always with the possibility of explosions and other FRR (far-reaching ramifications)  (such as... suddenly, in the next version of BJS, our "hack" no longer works correctly and needs re-hacking) 

[Rolento]

Hi Wingnut

Ha, that makes much more sense now   Thanks for explaining... 

I added your code to my project, and... it works a treat! The zoom seems to work for me too, so im a happy chap.  The only thing that does not work is the inertia effect - so I applied an algorithm that I found here (http://www.babylonjs-playground.com/#10VHTS#12) - sorry, I dont know who created this PG (thanks anyway!).

Here is the modified version of your code:

http://www.babylonjs-playground.com/#18KHF6#9

This code is a little mangled now, i.e. the main function is manipulating the camera making it tightly coupled, but it does the job.  If you know of a better way of applying inertia please let me know.  Once again thanks!

 

[Wingnut]

Cool!  Ya know... you're really not far away from converting to universalCamera... with only one attached input...  RolentoCameraPointersInput.    Your own camera, invented by you.  Wow! 

Yeah, I think there is an easier way to activate inertia.  It's within that input code somewhere.  camera.inertialPanningX and camera.inertialAlphaOffset... something there.  (not sure).

But yeah, you got this camera working well.  Good job.  RolentoCam.    It has hardly ANY modifications to the inputs code, now.  hmm.  It's a shame that it needs to be carried along, in your project.  It's not TOO fat... but... you know... we hate ALL unnecessary code fat.    Somebody will have a secret idea... soon.

[Rolento]

Hi Wingnut

LOL - RolentoCam, well my knowledge of BJS camera's is somewhat limited at the moment, so the RolentoCam could be unpredictable if you were to use it!  

That said, I have ran into a glitch - basically when I use the code ( http://www.babylonjs-playground.com/#18KHF6#9) in the PG everything works fine.  However, when I added the code to one of my local projects (I thought it was working) but its not.  Basically for some reason the addEventListerner() functions are not working - e.g.

...

canvas = document.getElementById("renderCanvas");

...

canvas.addEventListener('pointerdown', function (e) { ... }

In the above example for some reason the pointerdown event is not being caught.  I double checked that the canvas was named correctly in the HTML code and it is - i.e.

    <canvas id="renderCanvas"></canvas>

So, im baffled as to why this is not working.  Something silly no doubt, if you can think of anything obvious let me know.  I will try debugging this more tomorrow.

[aWeirdo]

@Rolento

Hi,

the mostlikely reason is missing pointer event support

try this, it might help, it might not  

 

// Check pointer support
var pPrefix = (!window.PointerEvent && !navigator.pointerEnabled ? "mouse" : "pointer");

//Add event listener;
renderCanvas.addEventListener(pPrefix + "down", pointerDownFunc);


//.. function to call on pointerdown
function pointerDownFunc(evt){
  //do something .. evt is the pointer event.
}

//The reason i use a seperate function is that this way i can remove the eventlistener again if/when it's no longer needed, from outside the function itself. E.g;
renderCanvas.removeEventListener(pPrefix + "down", pointerDownFunc);

 

[Nabroski]

for loop grab everything rotate it - 1 single line of code 
optional second line: add a callback / remove callback

[Rolento]

@aWeirdo

The alternative solution you provided works perfectly for me (Internet Explorer & Firefox). 

http://www.babylonjs-playground.com/#18KHF6#10

However, a friend of mine using a MAC (Safari) discovered that the system crashes (well the 3D objects vanish from the scene) when he moves the mouse on to the canvas region.  Unfortunately I dont have a MAC so I cant debug this - does anyone else see this problem?

 

[Visam]

1 hour ago, Rolento said:

@aWeirdo

The alternative solution you provided works perfectly for me (Internet Explorer & Firefox). 

http://www.babylonjs-playground.com/#18KHF6#10

However, a friend of mine using a MAC (Safari) discovered that the system crashes (well the 3D objects vanish from the scene) when he moves the mouse on to the canvas region.  Unfortunately I dont have a MAC so I cant debug this - does anyone else see this problem?

 

I have the same problem. I can set camera position to see a scene from different sides. But rotation..... looks exactly as in your example... Hopefully somebody will help us.

[GameMonetize]

Sorry I did not read everything in detail (in a meeting right now) but if you want to rotate the camera around Z, you can change camera.upVector (like here: http://www.babylonjs-playground.com/#1A64GI#1)

 

[Visam]

On 17/01/2017 at 8:20 PM, Deltakosh said:

Sorry I did not read everything in detail (in a meeting right now) but if you want to rotate the camera around Z, you can change camera.upVector (like here: http://www.babylonjs-playground.com/#1A64GI#1)

 

Hi

http://www.babylonjs-playground.com/#2EE9UD#7

I have several questions regarding these 3 lines:

    camera.setPosition(new BABYLON.Vector3(10, 0, 0));
    camera.setPosition(new BABYLON.Vector3(0, 10, 0));
    camera.setPosition(new BABYLON.Vector3(0, 0, 10));

If I uncomment line 9 or 11, I can see the scene. But if I uncomment line 10, the scene is disappeared. Why?

But if the line 10 will work, how can I set vertical rotation around axe X or Z?

 

[Nabroski]

 

 

http://www.babylonjs-playground.com/#2EE9UD#9
http://babylonjsguide.github.io/advanced/Euler_Angles.html

for fun http://www.babylonjs-playground.com/#2EE9UD#8

[Visam]

13 minutes ago, Nabroski said:

 

 

http://www.babylonjs-playground.com/#2EE9UD#9
http://babylonjsguide.github.io/advanced/Euler_Angles.html

for fun http://www.babylonjs-playground.com/#2EE9UD#8

Thank you!

http://www.babylonjs-playground.com/#2EE9UD#9

how can I set a vertical rotation around Z (blue) instead of Y (green) for the whole scene?

[aWeirdo]

@iTekVR ArcRotateCamera uses Alpha, Beta & radius; http://www.babylonjs-playground.com/#2EE9UD#10

 

[Visam]

8 minutes ago, aWeirdo said:

@iTekVR ArcRotateCamera uses Alpha, Beta & radius; http://www.babylonjs-playground.com/#2EE9UD#10

 

Yes, of course. But you misunderstood the question. I will try to explain it little more.

http://www.babylonjs-playground.com/#2EE9UD#12

1. If you moving the mouse horizontally, you can see the scene rotation around axe Y (green).

2. Comment line 9 and uncomment line 10. if you moving the mouse horizontally, you can see the scene rotation around axe Y (green) again. But I would like to see the scene rotation around axe X (blue).

 

 

 

[aWeirdo]

@iTekVR 
 

Yes, all you're doing is changing the position & angle of the camera, it isn't actually changing the axis it rotates around.

Wouldn't it be easier to do something like this;  http://www.babylonjs-playground.com/#2EE9UD#13

[Nabroski]

 

http://www.babylonjs-playground.com/#2EE9UD#14

[Visam]

3 minutes ago, Nabroski said:

 

http://www.babylonjs-playground.com/#2EE9UD#14

does not work well.... plane blinking...

[Visam]

7 minutes ago, aWeirdo said:

@iTekVR 
 

Yes, all you're doing is changing the position & angle of the camera, it isn't actually changing the axis it rotates around.

Wouldn't it be easier to do something like this;  http://www.babylonjs-playground.com/#2EE9UD#13

you are changing meshes coordinates. not good for engineers.

[Nabroski]

http://www.babylonjs-playground.com/#2EE9UD#15

[Nabroski]

Oh, yeah  value -=value

 

its now slower

http://www.babylonjs-playground.com/#2EE9UD#16

[Nabroski]

@iTekVR their is no easy way to came to a comfortable result you have to dive deep into the engine
http://webglfundamentals.org/webgl/lessons/webgl-3d-camera.html

good luck  share a playground, when you got something usefull

[im out of here]

[Visam]

On 20/01/2017 at 9:34 PM, Nabroski said:

@iTekVR their is no easy way to came to a comfortable result you have to dive deep into the engine
http://webglfundamentals.org/webgl/lessons/webgl-3d-camera.html

good luck  share a playground, when you got something usefull

[im out of here]

may be @Deltakosh help us?