consider player entity? handling roomscale, camera, controllers, teleport...

[machenmusik]

donmccurdy [3:54 PM] Ok, so, if you're on roomscale devices definitely avoid kinematic-body if not, I think i would do something like this: https://github.com/donmccurdy/aframe-extras/blob/master/examples/walls/index.html rather than putting height on the camera (edited)

[3:55]
since physics needs to know about that height

giordy [3:55 PM] i’m using it for mobile

[3:56]
for roomscale i’m using the teleport-controls

donmccurdy [3:56 PM] Ok cool

giordy [3:56 PM] but I can’t have both in the same scene as teleport-controls want a separate camera object

donmccurdy [3:57 PM] Kk, haven't had the chance to try teleport-controls myself yet

giordy [3:57 PM] i spent all day today trying to get it work with the physics engine but it gave me all sort of problems

[3:57]
but then again my js skills are quite limited

[3:59]
if you wanna take a look at what i’ve done you can find my scene at http://www.pippistarace.it/aframe/ (without controls)

donmccurdy [3:59 PM] Yeah, i don't have any expectation that kinematic-body can work with roomscale.. it's just hard to do, and the experience would be so bad that it's really not worth it.

giordy [4:00 PM] or http://www.pippistarace.it/aframe/indexrift.html (with controls but no physics)

leupsi [4:00 PM] Please have a look at the modified version of the Playground example. The barrier to limit the world works fine, only problem is the camera is bouncing back when colliding. And it doesn't work when wasd-controls are used, no idea why that. I think it's quite useful when playing the scene on a cardboard, so the user does not lost himself in white. http://leupsi.com/interaction/aframe/barrier/

giordy [4:01 PM] yeah i figured as much…I need to find a way to toggle between the two on the same scene, i suppose I need to dynamically delete or change a bunch of entities

[4:03]
@leupsi it looks fine on safari, what do you mean it’s bouncing back?

donmccurdy [4:03 PM] @leupsi i don't see the bouncing either.. to some extent that's controlled by restitution: physics="restitution: 0.3" for example.

[4:04]
wasd-controls won't work with physics though. There are specific accomodations in universal-controls for physics to be possible.

leupsi [4:05 PM] Okay thank's for the clarification @donmccurdy

[4:06]
So flying is not possible with physics enabled?

donmccurdy [4:09 PM] I don't know. I would try adding universal-controls="fly: true" also. But I haven't been doing much with kinematic-body lately, focusing more on roomscale.

giordy [4:09 PM] try to set gravity to 0 and add jump-ability="maxJumps: 3; distance: 10;"

[4:10]
:stuck_out_tongue: like neo in the matrix

leupsi [4:12 PM] Preparing for the next moon mission? :stuck_out_tongue:

donmccurdy [4:24 PM] haha well it's realistic at least :laughing:

leupsi [4:32 PM] @donmccurdy universal-controls="fly: true" works but it's super sensitive and w and s are inverted on the axis, so they move up and down. Anyways is it possible to set the sensivity of "fly"?

donmccurdy [5:06 PM] Settings are here: https://github.com/donmccurdy/aframe-extras/blob/master/src/controls/universal-controls.js GitHub donmccurdy/aframe-extras aframe-extras - :confetti_ball: Add-ons and helpers for A-Frame VR.

[5:07]
It's not inverting axis like a flight simulator or anything, you'll need to write custom code if that's what you're going for

mchen [8:04 PM]

but I can’t have both in the same scene as teleport-controls want a separate camera object

say more?

...

----- Yesterday January 9th, 2017 ----- giordy [3:06 AM] @mchen the only way I got the kinetic-body to work is with the following code

<a-entity id=player camera kinematic-body universal-controls position=" 0 1.764 0">
           <a-entity id=cursor cursor="fuse: true; fuseTimeout: 0" raycaster="far: 8;" scale="0.01 0.01 0.01" position="0 0 -1" geometry="primitive: ring" material="color: #2E3A87 ; shader: flat"></a-entity>
       </a-entity>

[3:08]
@mchen but to have the teleport-controls to follow the “player” entity it needs to be like this

<a-entity id=player position="-26 0 -16">
           <a-camera>
           </a-camera>
           <a-entity auto-detect-controllers="singlehand:right" teleport-controls="playerEntity:#player;collisionEntity:#floor;button: trigger;startEvent: down;endEvent:up"></a-entity>
       </a-entity>

(edited)

[3:09]
notice that in the second example the camera is separate from the “player” entity

[3:14]
this was the only way to get it to work properly, if I add the teleport controls to the first example then all hell breaks lose. (i.e. controllers Y position becomes higher than the camera, when I try to teleport the ray rotates both with the controller AND the camera)

[3:14]
i think it’s because teleport-controls doesn’t like being a child of the camera, but the issue might also be with the generic tracked-controllers since the position is also wrong (edited)

chrisnovello [5:17 AM] joined #issues

mchen [8:33 AM] i don't get where you were trying to have controllers in the first example...

giordy [9:17 AM] @mchen when I get home I will publish a new html with what I am talking about

sean-lerner [9:18 AM] joined #issues. Also, @itsravenous joined, @jeff.gayle joined, @kabbi joined.

giordy [3:05 PM] @mchen here are the different scenarios that I tried:

giordy [3:08 PM] added this HTML snippet

 <a-entity id=player camera="userHeight:1.6" universal-controls kinematic-body position="-26 0 -16">
            <a-entity id=cursor cursor="fuse: true; fuseTimeout: 0" raycaster="far: 8;" scale="0.01 0.01 0.01" position="0 0 -1" geometry="primitive: ring" material="color: #2E3A87; shader: flat"></a-entity>
            <a-entity auto-detect-controllers="singlehand:right" teleport-controls="playerEntity:#player;collisionEntity:#floor;button: trigger;startEvent: down;endEvent:up"></a-entity>
        </a-entity>

giordy [3:09 PM] (you can try it at this url: http://www.pippistarace.it/aframe/teleportnphysics-test2.html) (edited)

[3:10]
with this the physics collisions work, but the controllers are placed too high and rotate both with the physical controller and the headset.

giordy [3:10 PM] added this HTML snippet

        <a-entity id=player position="-26 0 -16">
            <a-camera universal-controls kinematic-body>
                <a-entity id=cursor cursor="fuse: true; fuseTimeout: 0" raycaster="far: 8;" scale="0.01 0.01 0.01" position="0 0 -1" geometry="primitive: ring" material="color: #2E3A87; shader: flat"></a-entity>
​
            </a-camera>

Add Comment Click to expand inline 8 lines

mchen [3:10 PM] right, because the controllers are children of the camera and thus headlocked, which you don't want.

giordy [3:11 PM] with the second example (that you can try at http://www.pippistarace.it/aframe/teleportnphysics-test2.html) the controllers and teleport work fine, but the physics don't work (i am able to go through walls) (edited)

[3:14]
i think i'm going to have 2 versions of the gallery anyways, one for the full HMDs and the other one for mobile/browsers

[3:15]
this is what I was talking about when I was saying that I can't have the kinematic-body and the teleport-controls in the same scene

tltmedia [3:16 PM] I keep falling through the floor :stuck_out_tongue:

mchen [3:37 PM] shouldn't the kinematic body be on the player not the camera in the second example?

giordy [3:48 PM] i tried both, it doesn't make a difference

[3:50]
and if I don't set gravity to 0 it falls through the floor. i even tried to set the y position at something higher than 0 (ex. 1.6 like i have it in the first example) but it still doesn't work

...

mchen [10:37 PM] @giordy the reason why the player falls through the floor when you put the kinematic-body on it is actually quite simple. you have your floor-box aboze zero. so since the player y is zero, as soon as you make it the kinematic body, it is already below the top surface of the floor and starts falling. move your floor down so the top edge is at zero, and that problem goes away...

[10:38]
what I wonder is whether at y=0 the player is able to move under the walls, so maybe cheat the player up a tiny bit?

mchen [10:44 PM] no, i see what the other problem is. the way you have test2 set up, you are actually moving the camera, not the player. so if the player is the kinematic body, it's sitting in a place with no collisions, and you're moving the camera through walls while the player that you're checking is in the same spot.

[10:45]
... and it is quite possible/likely that several of the movement controls you are using will not like being on the player instead of the camera, which is why for the arcade I stopped using wasd-controls for example

mchen [10:52 PM] @donmccurdy given a player construct, is there a way to make universal-controls move the player not the camera (which is currently being moved anyway via direct vr hmd changes) ? (edited)

[10:53]
by player construct, I mean something like

<a-entity id="player" kinematic-body universal-controls>
<a-camera></a-camera>
<!-- hand controls would also be children of player, peer of camera -->
</a-entity>

(edited)

donmccurdy [11:00 PM] @mchen that example looks like it should work, it just moves whatever entity it's attached to.

[11:01]
Eh, well except that the hand controls are going to be positioned in absolute coordinates

[11:01]
so any motion or rotation of the camera is messing with that.

michael.andrew [11:35 PM] Probably better to just move the world around the player so the hand control positions stay correct. I’m having similar issues at the moment with something I’m working on.

----- Today January 10th, 2017 ----- danodejos [2:24 AM] joined #issues

mchen [2:27 AM] @donmccurdy ... yeah, that appears to be causing @giordy issues

donmccurdy [2:31 AM] Ok, I don't have an easy solution to that. Hand controls are not designed to be nested inside a moving entity, whether it's universal-controls or look-controls. (edited)

[2:32]
I should probably also reiterate, kinematic-body is fundamentally incompatible with roomscale VR, so there are a lot of things likely to go wrong here.

mchen [2:33 AM] right. proper structure IMO is player entity as parent of both camera and controllers (and any other tracked objects in that roomscale space, I suppose)

donmccurdy [2:34 AM] What does the player entity do, in that case?

[2:34]
or provide?

mchen [2:34 AM] prevents you from having to move all three independently...

[2:35]
in theory you can teleport the roomscale space around, instead of moving the entire world

donmccurdy [2:35 AM] So, like teleportation would move the player, but walking in roomscale would just move the camera?

[2:35]
Ok yeah. That seems right to me.

mchen [2:35 AM] camera does what camera does, yeah.

[2:36]
when you say kinematic-body is incompatible with roomscale, i've only seen your physics system use dynamic and static bodies...?

donmccurdy [2:37 AM] To adjust the example above, then:

<a-entity id="player">
  <a-entity camera universal-controls></a-entity>
  <!-- hand controls would also be children of player, peer of camera -->
</a-entity>

^Is what I'd suggest. I think that should work equally well with <a-camera/> in place of the inner entity. Teleport controls wouldn't know about the player wrapper, but if we decide that's the right structure we could consider setting that up.

[2:38]
Yeah, for exactly that reason I've omitted the kinematic-body component from aframe-physics-system. It's just in aframe-extras, with an "experimental" label on it.

mchen [2:39 AM] doesn't work right if you do that, universal controls artificially moves the camera without the controllers and screws up the roomspace

[2:39]
IMO, we may just want to attach the controls to the player and move that...

donmccurdy [2:40 AM] Hm? That's what we just said though, universal-controls moves the camera the same way that look-controls does.

[2:40]
are we talking about roomscale here?

mchen [2:40 AM] yes

[2:41]
orientation adjustment doesn't mess up controller position, but when you start using wasd-controls or something to actually do translation, that gets weird

donmccurdy [2:41 AM] Ok, gotcha, I thought we were talking about tracked HMD movement / walking. When you walk in roomscale, universal-controls needs to move the camera.

mchen [2:42 AM] if you are wearing the HMD / camera, it's cool.

[2:42]
ohhh right, you have universal-controls doing hmd-controls in the refactor.

[2:42]
but the artificial stuff shouldn't muck up the roomscale relationships.

[2:43]
which may mean another refactor...

donmccurdy [2:43 AM] Yeah, lots of possible inputs to universal controls. Could be a gamepad, there's even some teleportation support built in.

[2:44]
I'm nervous about having universal-controls try to move different entities depending on the input device, that's hard to plan around...

[2:44]
Another option would be to refactor hand-controls to just assume they're relative to the camera

[2:45]
so you can always do:

<a-camera universal-controls>
  <!-- hand controls here -->
</a-camera>

[2:45]
that's the approach I took with leap motion, and it worked nicely.

[2:45]
(but it's also much easier with leap motion ...)

[2:46]
Let's move discussion to a github issue, getting late here, and it would be worth having a record of this.

mchen [2:46 AM] k

donmccurdy [2:47 AM] original goal of universal-controls was to support locomotion from different input devices ideally goal of some "player" abstraction would be to support locomotion AND tracked controls from various sources.

[2:48]
fine with me if that requires rewriting stuff

[machenmusik]

somewhat related: Updated A-Frame Arcade http://chenz.org/aframe-arcade/ to use physics for handling movement and collisions... nontrivial to make teleport, roomscale w/controllers, and traditional arrow keys / mouse drag/ scroll all work. if folks get a chance to try it and let me know if there are things that don't work well, I'd love the feedback (DM me) that uses a fork of @fernandojsg aframe-teleport-controls that has been taught how to (1) move player entity, not camera and controllers (2) move physics bodies as well as non-physics entities and has its own equivalent of arrow key wasd-controls as well as multi-tap/click, mouse scroll / drag, D-Pad / stick movement...

[donmccurdy]

There's a lot here, so a couple starting points:

1. Let's exclude kinematic-body from discussion. It will never support roomscale VR, and that's primarily what we're talking about with tracked controllers.
2. In the leap-hand component I took this approach:

// A
<a-entity camera look-controls position="0 1.5 0">
  <a-entity leap-hand="hand: left"></a-entity>
  <a-entity leap-hand="hand: right"></a-entity>
</a-entity>

OTOH, tracked-controls assumes the controller is attached directly to the scene. I'm not sure how teleport-controls is able to associate the three.

// B
<a-entity camera look-controls></a-entity>
<a-entity teleport-controls tracked-controls="hand: left"></a-entity>
<a-entity teleport-controls tracked-controls="hand: right"></a-entity>

Another option, not currently implemented anywhere, would be this:

// C
<a-player>
  <a-entity camera look-controls></a-entity>
  <a-entity teleport-controls tracked-controls="hand: left"></a-entity>
  <a-entity teleport-controls tracked-controls="hand: right"></a-entity>
</a-player>

What are the tradeoffs of (A), (B), and (C)? Is there value in establishing a recommended structure, and do we know enough about what that should be yet? I haven't seen an A-Frame demo with co-presence in roomscale VR yet, will we need a player abstraction to support that?

[machenmusik]

http://chenz.org/aframe-arcade/ does something very similar to (C) actually, although the teleport-controls string looks a little different to specify the player entity that should be moved (IMO that is actually better than having a hidden need for tracked-controls and moving anything it finds with that component, active or not).

[machenmusik]

(A) breaks tracked controllers badly at the moment. (B) gets very ugly w.r.t. locomotion IMO especially if rotation is included

[machenmusik]

Let's exclude kinematic-body from discussion

http://chenz.org/aframe-arcade/ is now using aframe-physics-system and dynamic-body / static-body for movement and collisions as of this morning.

[fernandojsg]

FWIW I was doing some modifications in my latest test with hand controls and teleportation, and I've found the best way to go is to use the same camera rig that is typically used in engines like unity, the C described by @donmccurdy :

<a-entity id="camerarig">
  <a-entity camera look-controls></a-entity>
  <a-entity teleport-controls tracked-controls="hand: left"></a-entity>
  <a-entity teleport-controls tracked-controls="hand: right"></a-entity>
</a-entity>

So you could move the camerarig instead of manually update the position of the camera and the controllers as I'm doing right now with the teleport-controls (I'll update the examples to follow this approach too). The only concern is that before you had the correct position & orientation values for camera and controllers within the entity, and now you should apply the transform from the camerarig, but it shouldn't be a big deal.

[machenmusik]

@fernandojsg right, that is what i am doing as well, with some mods to your teleport controls... (1) allow other objects to block the teleport arcs (2) move player entity if specified (3) move physics body not object3d if present... chenzlabs/aframe-teleport-controls

found a physics combination that works ok with teleport for chenz.org/aframe-arcade (player as dynamic body) although i would rather have standard gravity and a few nonexistent types of constraints instead

[giordyb]

I'm using a similar approach in my project, my player object looks like this:

 <a-entity id=player position="-26 0 -16">
            <a-camera>
            </a-camera>
            <a-entity id=controllerleft oculus-touch-controls="hand:left" mixin="controller"></a-entity>
            <a-entity id=controllerright oculus-touch-controls="hand:right" mixin="controller" teleport-controls="playerEntity:#player;collisionEntity:#floor;button: grip;startEvent: down;endEvent:up"></a-entity>
 </a-entity>

Unfortunately this approach breaks whatever component uses the controller's position because in this case it becomes relative to the parent object instead of the scene.

As you can see I'm using both teleport-controls (the ones forked by @machenmusik, which allows me to have the player start at a different location other than 0 0 0) and super-hands components.

To get it to work correctly with this configuration (i.e. controllers attached to another entity instead of the scene) I had to modify both the @donmccurdy 's sphere-collider (already merged) and @wmurphyrd (still need to do the pull request) by changing all references to the controller's position attribute to controller.object3D.getWorldPosition().

It's a bit of a hack but it works for me. I'm sure you guys can find a much better solution though, I'm a newbie here...

[machenmusik]

yeah there was/is a habit where everything is assumed to be a direct descendant of scene (without saying so)

almost wonder if it would be better to have current usage of position be called localPosition... but that would likely break everything

[wmurphyrd]

Seems like this is going to be an ongoing point of confusion for creators. While digging into the THREE.js API works, it's not in line with the spirit of A-Frame.

One option would be flag parameter in getAttribute to specify relative v. absolute. Probably not ideal, though, since it would have inconsistent effects depending on the attribute (I think only position, rotation, and scale would benefit from this)

On Tue, Jan 24, 2017, 9:56 AM machenmusik notifications@github.com wrote:

yeah there was/is a habit where everything is assumed to be a direct descendant of scene (without saying so)

almost wonder if it would be better to have current usage of position be called localPosition... but that would likely break everything

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aframevr/aframe/issues/2265#issuecomment-274845024, or mute the thread https://github.com/notifications/unsubscribe-auth/AJkeqzx3OEN3SN1FyJzBWkHZuEf8azeuks5rVh8tgaJpZM4LfhrW .

[machenmusik]

I don't think modifying getAttribute would match (sounds like getComputedAttribute, which I presume went away for a reason) - maybe just standard API for these like AFRAME.utils.___ (which can actually be implemented via THREE, and replaced with alternatives if someone wanted to use A-Frame over a different backend)

[wmurphyrd]

I had an idea the other day for another solution that more is consistent with the API: new default components world-position, world-rotation, & world-scale.

• Use the same getAttribute and setAttribute API, handling the appropriate transformations and updates
• Essentially invisible to creators unless they need the interface, but also easier to discover when they do need it than a utils method
• For entities that have no object3d, can failover to traversing the DOM hierarchy to determine the absolute position/rotation/scale

[fernandojsg]

In unity it's commonly used transform.position/scale/rotation that refers to world instead of local (transform.localPosition/Rotation/Scale), but when you edit the transform on the inspector windows, you're editing the locals not the globals. I believe we can't just assume a switch between globals or locals for all the cases but to expose both as unity does and leave that responsability to the component.

My proposal would be to have: .getAttribute('globalPosition/Rotation/Scale') and it will be just a read-only component that will returns the computed global values, (we could show them also in the inspector as non-editable values too).

These values will be computed just when required, as we don't want to keep decomposing the world matrix on every tick if we're not going to use them. With this components like the teleport will need to query globalPosition of the controllers instead of the current position or accessing by code to the worldposition with threejs.

[machenmusik]

taking the teleport case, it's not enough to have get-only e.g. to propagate camera change to controllers. that would only work if one had a player / camerarig entity that owned both, and assumes only one level of hierarchy.

Why not allow setting using global coordinates, which would be done by setting local to the appropriate computed global-to-local delta?

[fernandojsg]

@machenmusik I don't understand what you mean with propagating camera changing to controllers. You'll have something like:

<a-camerarig>
  <a-entity camera></a-entity>
  <a-entity teleport-controls></a-entity>
  <a-entity teleport-controls></a-entity>
</a-camerarig>

And when you want to apply teleport you move the whole camerarig so you'll be moving the camera and the controllers at once.

[machenmusik]

yes, but if you want to move it to global coordinates, not being able to set using global coordinates will be a problem.

[fernandojsg]

Umm I still don't understand, the camerarig will be a direct child of a-scene so every time you move it, it will be in global coordinates, and the object inside it (camera and controllers) you don't want to move them outside of the rig globally so they're just moving locally as expected. That's the approach I followed for the camera controls implementation I've used here https://twitter.com/fernandojsg/status/836371728976719872 and it's based on how unity's cameraRig works and I can't think right now in any use case where I want to set the global position of any object within the rig instead of moving the rig itself, probably for some edge case but I believe for most common uses it could works. Could you give me some example you're facing right now?

[machenmusik]

I'm not sure we should assume that the player/camerarig is a direct descendant of scene, in the same way we shouldn't assume that camera and controller entities are a direct descendant of scene. I agree that the most common case is that way right now, but I can see a outer world-offset entity, with a player entity inside that which contains camera and controllers...

[machenmusik]

thinking about this a little more, position and scale are pretty easy, but rotation may not be. Maybe read-only globals plus utils functions to set relative to a given entity?

[ngokevin]

camera rig works