Aframe: Cannot programatically set <a-camera> rotation in v0.8.0

Created on 16 Mar 2018  Â·  17Comments  Â·  Source: aframevr/aframe

Description:

For some reason, using setAttribute will no longer allow me to programmatically rotate the camera via a component's init.

Please view the glitch above, view the non-working example, then uncomment the 0.7.1 CDN version to see it work.

I've scoured the API, but can't see any updates to method signatures or the like for this version.

Most helpful comment

It _is_ in the docs for master; I guess it just never made its way over to 0.8.*.

https://aframe.io/docs/master/primitives/a-camera.html#manually-positioning-the-camera

All 17 comments

This is hard to manage dynamically for no particular benefit that I can see.

Particularly if you're setting camera positions based on HMDs connected, mobile or desktop because now initial rotation needs to be managed on a parent entity, but initial position needs to be managed on the camera (else I get offset problems). It's also difficult to manage inside the Inspector if you want to make quick adjustments.

Also breaks some contrib modules I'm using (camera fence, travel-node). Is there any other way around it? Trying to avoid long churn on upgrading an existing experience.

It fixes some long-standing bugs in which the camera's position would be "in the floor", or at 2x height, or drop into the floor after exiting VR etc., for various devices. Quite a lot of alternatives were looked at... see https://github.com/aframevr/aframe/pull/3327.

We're aware it breaks some existing components, e.g. I'm in the process of updating aframe-extras to support the new VR API. But, I think the change is necessary. Could you look through the comments on 3327, especially https://github.com/aframevr/aframe/pull/3327#issuecomment-360019236, and see if this is workable for your case? The move toward having a camera "rig" and not just a raw entity is IMO positive, so I'd like to see if we can get contrib modules and documentation updated to match.

I understand the reasons now, however, this doesn't really help with my particular situation unless I'm missing something in those comments.

For instance, to restore basic camera fencing capability, I now need to figure out some way to merge the 'camera rig' angle with the room angle so it makes sense for the user. Unfortunate as I don't particularly have time to wait for contribs to be updated.

image

Can I suggest documenting this change so others don't proceed down the v0.8.x route without understanding the breaking changes for existing projects?

https://github.com/aframevr/aframe/pull/3451 provides (some) documentation, are there other updates you’d suggest?

I've added this to an 0.8.X milestone in the hope we can improve documentation and update some examples.

Another note, I've overhauled the controls in aframe-extras for 0.8.0 and documented them here: https://github.com/donmccurdy/aframe-extras/tree/master/src/controls

^tl;dr universal-controls is now movement-controls and should be attached to a camera rig. The examples are probably similar to what other components should do as well.

The look-at component / billboarding is also broken by this change. Anything that requires access to or polling the camera rotation. Is there a way to easily calculate the difference in angle between the parent entity and the camera object?

@mokargas do you mean using look-at to reorient the camera? Bit confused sorry. For wasd-controls and aframe-extras we'll need a way to get absolute rotation of the camera, haven't spent much time on that but cameraEl.object3D.getWorldQuaternion() seems like the place to start.

@donmccurdy Yeah, I'm talking about effectively billboarding, where an entity orients to face the camera. I know that's a common enough feature used in VR experiences.

It's broken in 0.8 with this change, but I think I've solved it with some quaternion math (which I'm a novice in).

e.g: in the tick function of the element I need to face the camera, I did this:

let q = new THREE.Quaternion().multiplyQuaternions(self.camera.object3D.quaternion, self.cameraRig.object3D.quaternion)
return this.el.object3D.quaternion.copy( q )

Probably a bit of a stretch to ask non-devs to discover if they are starting on v0.8 and install an updated look-at contrib or other contrib that requires camera rotation, but I'm not sure how to handle that.

Probably a bit of a stretch to ask non-devs to discover if they are starting on v0.8 and install an updated look-at contrib or other contrib that requires camera rotation, but I'm not sure how to handle that.

Worth noting that this change is not strictly breaking billboarding, it was always true that cameraEl.getAttribute('rotation') returned only local rotation, and the camera might have been transformed by a parent. We've just begun _recommending_ use of a camera rig, which surfaces issues in components like look-at that didn't convert to world coordinate space.

But the main thing is to report bugs on the third-party components when they no longer work with current A-Frame. We try to avoid breaking backward compatibility but sometimes it is necessary.

I've proposed some new docs in https://github.com/aframevr/aframe/pull/3498, but feel free to suggest more clarifications!

And what is the solution now?? Using THREE.Quaternion (instead of position or rotation) is not!!
Otherwise describe please in the docu that position change of the camera is forbidden and the usage of a wrapper instead (or whatever).

You’ll need to use a wrapper entity — the camera entity itself should not be rotated directly. For example:

<a-entity id=“rig”>
  <a-entity camera look-controls position=“0 1.6 0” />
</a-entity>

Some examples with aframe extras:
https://github.com/donmccurdy/aframe-extras/tree/master/src/controls

I thought we’d documented this somewhere, but it’s notably not there on the camera docs so I agree it should be added...

It _is_ in the docs for master; I guess it just never made its way over to 0.8.*.

https://aframe.io/docs/master/primitives/a-camera.html#manually-positioning-the-camera

@donmccurdy
I think it'd be much more logical to let programmers adjust a camera rotation without nesting for the sake of simplicity. This is still extremely unclear based on the documentation

I don't think this is likely to change. Sharing management of the camera with the VR session is not easy. Further clarifications to the docs would of course be welcome.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jonikorpi picture jonikorpi  Â·  4Comments

jgbarah picture jgbarah  Â·  4Comments

RangerMauve picture RangerMauve  Â·  4Comments

rich311 picture rich311  Â·  3Comments

huhsame picture huhsame  Â·  3Comments