Skybox position should always be inherited from camera position

[ngokevin]

Issue by jcarpenter Tuesday Aug 25, 2015 at 22:29 GMT Originally opened as https://github.com/aframevr/aframe-core/issues/8

---

Moving the camera in the VR world should have no effect on the look of the skybox. Skybox distance should always appear to be infinity.

[ngokevin]

Comment by nickdesaulniers Friday Aug 28, 2015 at 21:36 GMT

---

Is the skybox not anchored at the origin?

[ngokevin]

Comment by jcarpenter Saturday Aug 29, 2015 at 01:16 GMT

---

I'm not sure I understand the question. We always drop Skybox at 0,0,0 (the default for all objects). The problem occurs when the user begins to walk through the scene. Although the issue is much less pronounced now that the default walking speed is roughly 1 meter / second, and the default sky sizes are approx 10,000 meters.

[ngokevin]

Comment by dmarcos Monday Sep 14, 2015 at 17:39 GMT

---

You just have to do the skybox a child of the camera

[ngokevin]

Comment by jcarpenter Monday Sep 14, 2015 at 18:01 GMT

---

That would work, but it's really gross from a markup / scene graph standpoint, and not consistent with either our mental models of reality, or any of the prior art in 3D / game engines (Unity, Cinema 4D, etc). We need a smarter skybox / skysphere component.

[ngokevin]

Comment by dmarcos Monday Sep 14, 2015 at 18:25 GMT

---

It's not gross. It's clear and unambiguous. You see the code and can understand how things interact with one another. There's nothing hidden. The way to make objects follow other objects it's by using the hierarchy. Unity, Cinema4D are UI tools not markup so prior art doesn't apply

[ngokevin]

Comment by jcarpenter Tuesday Sep 15, 2015 at 01:47 GMT

---

What happens if we switch cameras? What happens if the skybox size is not large enough and it clips objects in the scene as the camera moves around? What happens when we try to teach novices, with a straight face, that a Skybox is a child of the camera?

It's non-intuitive. Transform inheritance is a not a straight jacket to be followed blindly. We can implement this in a way that is automatic and intuitive from a mental model standpoint, and consistent with every other content creation app out there.

[ngokevin]

Comment by jcarpenter Tuesday Sep 15, 2015 at 01:48 GMT

---

Related: https://gettingreal.37signals.com/ch09_Context_Over_Consistency.php

[ngokevin]

Comment by sirkitree Thursday Dec 17, 2015 at 19:27 GMT

---

I agree that making it a child of the camera is not intuitive - but honestly I'm not sure having a 'camera' is intuitive to begin with (at least when your devs are coming from the web world).

Currently you don't have to define the camera with aframe though and it's defined with the a-sky component. If I walk forward for a long time I don't see any problems with distortion or anything and it seems that I could walk forward indefinitely.

So perhaps this is no longer a problem?

[ngokevin]

Comment by jcarpenter Tuesday Dec 22, 2015 at 08:26 GMT

---

The issue is currently obscured, but still present. The default WASD controls move the camera at 1m / second. The default <a-sky> radius is 5000 meters. If you add an image to the sky and walk around, you can perceive a subtle shift in perspective relative to the background. If users tweak the WASD controls to increase speed, or if they animate the camera via <a-animation>, this issue will inevitably rear it's head again. Increasing sky size will remain as a simple blunt-force solution, but that has performance impact (higher near/far spread to ensure sky is always within range of the camera far value).

Not a high priority, versus other outstanding items, but I'd love a better solution for this.

[ngokevin]

Comment by ngokevin Tuesday Dec 22, 2015 at 08:39 GMT

---

Could probably be solved with a component that defines the behavior of an entity following another entity.

[ngokevin]

https://github.com/aframevr/aframe/issues/379 dupe