aframe
aframe copied to clipboard
User camera not honored anymore and default one injected anyways
<a-scene>
<a-entity camera></a-entity>
</a-scene>
With the above a default camera is injected incorrectly
I cannot reproduce. https://glitch.com/~sweltering-mackerel
I cannot reproduce this anymore.
I just had this issue after updating to aframe 0.9.0. I had the camera nested in a rig and on a sphere component.
<a-scene>
<a-entity position="0 10 0">
<a-sphere camera look-controls>
</a-sphere>
</a-entity>
</a-scene>
A default camera was injected. I found a work-around by switching to a a-camera component
<a-scene>
<a-entity position="0 10 0">
<a-camera geometry="primitive:sphere" look-controls>
</a-camera>
</a-entity>
</a-scene>
The default camera was no longer injected.
The setupInitialCamera function of the camera system is called when the scene element has no other children than the a-canvas and a-loader-title. Therefore the sceneEl.querySelectorAll('a-camera, [camera]') returns an empty list.
Could this issue be re-opened?
There must be more to this bug. I tried the below on master and v0.9.0 from the dist folder running the below out of examples. I made the assumption that contents of the element would not have been present yet, but everything is indeed present in the DOM and the a-sphere is returned as expected. Wondering if browser version/capabilities has anything to do with the issue?
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>3D Model (glTF)</title>
<meta name="description" content="3D Model (glTF) — A-Frame">
<script src="../dist/aframe-v0.9.0.js"></script>
</head>
<body>
<a-scene>
<a-entity position="0 10 0">
<a-sphere camera look-controls>
</a-sphere>
</a-entity>
</a-scene>
</body>
</html>
I'm seeing it on com.oculus.browser (OculusBrowser/5.7.6.141460824 SamsungBrowser/4.0 Chrome/66.0.3359.203), but also on Chrome 72. I try to reproduce in glitch.
@DigiTec you were right. It has to do with there being a template present. Please find a minimal repro here https://glitch.com/~neon-canopy
I narrowed it down further. Just the presence of a script tag before the entity with camera is enough. But you'd use that inside the assets element to define a template.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>3D Model (glTF)</title>
<meta name="description" content="3D Model (glTF) — A-Frame">
<script src="../dist/aframe-v0.9.0.js"></script>
</head>
<body>
<a-scene>
<script></script>
<a-camera></a-camera>
</a-scene>
</body>
</html>
What about if you don’t use primitives at all? Only a-entitys tags
<a-entity camera></a-entity> makes no difference. https://glitch.com/~neon-canopy
Yeah I reproduced this as well on my own project which also uses the template component. A workaround is to move the camera element up higher on the page (above assets for example)
Yeah I reproduced this as well on my own project which also uses the template component. A workaround is to move the camera element up higher on the page (above assets for example)
This is the best answer so far...and the same problem still exists in the latest version which is 1.0.4
@mzpq01 steps to reproduce?
Yeah, seems like <a-entity camera></a-entity> or <a-camera></a-camera> are working for me to prevent the default camera from getting injected.
It’s sort of an interesting behavior when i’m trying to register/track and add my own camera component though.
P.S. Thanks for everything dmarcos!
For posterity, I was having this problem. I then realized my camera component was outside of my a-scene after shuffling components around trying to appease render order and transparency. Hopefully, this will save someone some time!
I'm also having the same issue. Clean fresh install of aframe (1.2.0):
import 'aframe'
import 'aframe-inspector'
function App() {
return (
<a-scene>
<a-entity camera look-controls wasd-controls="acceleration:20" position="0 1.6 0"></a-entity>
</a-scene>
)
}
export default App
When inspecting I see 2 cameras. I noticed that something was wrong because acceleration was still the 65 default:

Maybe helps, but using react + aframe I get the issue. HTML only application I don't.
Hi @mascardoso, I'm having a similar issue. Did you manage to solve it somehow?
Hi @zelitomas I ended up doing plain JS + HTML. That worked just fine. For some reason which I'm unsure yet, AFRAME + REACT were giving this exact issue. Cheers
Yeah I reproduced this as well on my own project which also uses the template component. A workaround is to move the camera element up higher on the page (above assets for example)
This workaround still seems to do the trick
I've been hitting this issue (A-Frame 1.2.0), and came up with this workaround during init of my app:
const sceneEl = document.querySelector('a-scene')
if (sceneEl.camera.el.id !== 'player') {
console.log("Deleting unwanted A-Frame default camera")
const wrongCameraEntity = this.el.sceneEl.camera.el;
const cameraEntity = document.getElementById('player');
cameraEntity.setAttribute('camera', 'active', true);
wrongCameraEntity.parentEl.removeChild(wrongCameraEntity);
}
Cause is probably the same as @kfarr above - <template> tags before the user-defined camera in the HTML file.
If I'd found the discussion here earlier, maybe I'd have just re-arranged the HTML. Either way, my workaround seems to be holding up OK so far.
Also worth noting that in my case, this was occurring intermittently. Seems to reliably occur on hard refresh (Ctrl-F5), and on the 2nd page load of a Playwright automated script. Otherwise, mostly didn't happen (but maybe occasionally it still did).
I have the same issue with A-Frame 1.3.0 in combination with react. Sometimes the default camera is injected, sometimes not. This only happens in Chrome (MacOS, Debian, and Android). I've never had the issue with Firefox. My camera rig was the last child of the scene. Moving <a-entity camera></a-entity> to the top of the scene helped.
React might be introducing additional asynchrony. I don't know much about react but if you can reproduce with vanilla A-Frame happy to look into it. Sorry for the inconvenience.
Oh I didn't see this issue existed when I created the PR #5124 to fix this exact issue. Also see #5136 now.