Multiple a-scenes with a page
zitterbewegung opened this issue · 28 comments
Hi, I would like to have multiple a-scenes within a page so that I can have multiple 3d models mixed in with other html.
What about embedding iframes for the time being?
Fullscreening (entering VR) with iframes work with Firefox but not with Chrome
This should be possible. Check out https://github.com/aframevr/aframe/blob/master/docs/components/canvas.md
This is probably the reason we'll need to abandon A-Frame for our project. It stinks, but we can't use the iframe solution.
This is probably the reason we'll need to abandon A-Frame for our project. It stinks, but we can't use the iframe solution.
Actually, this is supported now. Sorry, this issue didn't get closed with a mention of the proper pull request that enabled this to work.
@dmarcos worked on this for A-Frame v0.3.0 (also documented in the release notes). Here's an example of a mock Wikipedia entry, demonstrating the ability to embed one scene (but could be multiple) in an existing 2D page alongside content.
Maybe it is just a-videosphere, in that case?
@cvan multiple scenes on a page do not work yet. It is complex to do. And the issue is still
I frames don't quite work entering fullscreen yet
I frames don't quite work entering fullscreen yet
even with <iframe allowfullscreen>? what's the issue? is there an issue on file in this repo?
I'm actually not sure. I neglected the allowfullscreen. I remember it didn't work in CodePen. Need to check.
@cvan what's the specific secret sauce for getting multiple a-scenes to work on a page? I've tried "embedded" but both of my scenes will not render (they each render if I include only one at a time). I am using v0.4.0.
Multiple scenes on the same page are not still supported directly. You could embed multiple scenes within iframes. @hawaiikaos
@dmarcos Thanks for the clarification :-)
I'm closing in favor of I-Frames. three.js doesn't support multiple scenes with their own contexts either.
I'm closing in favor of I-Frames. three.js doesn't support multiple scenes with their own contexts either.
is the existing "embedded scenes" not a use case that A-Frame intends to support? @dmarcos' Wikipedia example, for example, does not use <iframe>s; isn't that a valid use case A-Frame would want to support (especially considering how likely it would be for there to be two scenes on a web page)?
The embedded use case is my most common, and iframes are not a viable workaround (anyone who has worked with a client's CMS probably knows why). I don't think I'm the only one with these kinds of requirements.
A-Frame is so useful and well-designed, I would hate for this issue to be a sticking point that hampers its adoption.
@cvan The issue is about multiple scenes, not one embedded scene.
@brianblakely Sorry, it is not easily possible with three.js to have multiple embedded scenes with separate contexts. Even if so, it would require major refactor and energy to make it possible. A-Frame is focused on immersive WebVR meaning we'll be consuming one scene at a time in a headset and traversing between them in a headset. This is not going to be a sticking point in the long term at all.
@cvan The issue is about multiple scenes, not one embedded scene.
correct, see my comment above:
(especially considering how likely it would be for there to be two scenes on a web page)
my point about the Wikipedia use case, is that there likely would be more than only one scene on a given Wikipedia page (just like there are multiple images, charts, tables, etc. on Wikipedia pages).
Even if so, it would require major refactor and energy to make it possible.
I trust your assessment here. my fear is that we ought to not close issues because of today's constraints and efforts of the current core A-Frame developers. if we were to vote on this, I'd vote for this to remain an issue - not necessarily fix it any time remotely soon.
A-Frame is focused on immersive WebVR meaning we'll be consuming one scene at a time in a headset and traversing between them in a headset. This is not going to be a sticking point in the long term at all.
this is a very large assumption actually - that all A-Frame scenes will be constructed as separate documents as scenes. (the recent influx of JS frameworks for supporting single-page, reactive apps I think is proof that we didn't always correctly predict future Web tech trends and evolved user expectations.)
also, we know how WebVR experiences are being delivered for consumption by users in Chrome for Google Daydream (and beginning to with Oculus Carmel). multi-tasking, preloading, shared messaging of scene/entity contexts, universal inputs - all that becomes incredibly complicated when an A-Frame scene is isolated to a single document (resulting in such workarounds as <iframe>s + postMessage).
à la DrawVR's "Escape Room" game, users can carefully construct SPA-like experiences by separating levels/worlds in separate entities whose visibility are toggled appropriately.
then there is the case of unnecessarily duplicated code (and inability to easily share state). even if you have the best-in-class server-side caching and a Service Worker, the perf penalty is certainly not negligible by loading three separate documents in <iframe>s for three different A-Frame scenes vs. one document for the same three scenes. you can reuse all the code that was fetched, parsed, and executed - those seconds, and even milliseconds, break immersion.
is there harm in keeping an issue open? I wouldn't want to see A-Frame issues getting closed without having a full community discussion.
SPAs can swap entities in and out as you say, you can use the very same JS frameworks to implement the SPA logic; you don't need multiple scenes for that. Separate WebGL contexts can not share resources and are just as non-performant. Introducing multiple scene support will add more layers to maintain in the codebase. I also don't imagine Wikipedia ever embedding A-Frame scenes given the weight; a VR-specific parallel site would be more realistic.
Yes, there is harm because it draws focus and energy from more important issues (as seen from the amount of time discussing here). I'm happy to address feedback as I do interfacing with the community every day, but a full community discussion on every single issue would burn everyone out.
Understand we're in a position where we're faced with 200+ open issues, many of which would not be worth spending time reviewing, maintaining, testing. I ask not to try to paint closing issues and triaging as a Bad Guy move.
I agree with @ngokevin keeping issues opened is not free. You have to manage the expectations around those bugs as long as they stay open and makes the direction and priorities of a project confusing. I would love to support multiple scenes. That was my longer term goal after the Wikipedia embedded scene. Affer analyzing perf and other implications like for instance the behavior of the inspector I decided that the effort was not worth it given the focus of our roadmap on VR immersive experiences.
I realise this is long-closed, but wanted to add some thoughts now that Three.js does seem to support rendering multiple instances on a single page (at least it happily does it in my test page).
We're currently evaluating what framework to use for some 3D visualizations to augment our existing 2D visualizations, which were written using D3. At first glance A-Frame looked ideal; we can quickly set up the basic scene in HTML, then use our existing D3 knowledge to quickly build up the complexity, easily attaching interaction handlers to objects, etc. And then I realised the show stopper: We can't have multiple A-Frame instances on a page. We display multiple visualisations at the same time to the user, so it's a deal breaker.
I appreciate A-Frame has a VR focus so it isn't your priority, but you guys have a really powerful general purpose 3D framework which gives a useful abstraction on top of Three.js and can be combined with the power of D3. It's a great combination outside of VR which isn't covered by any other framework to my knowledge. So supporting this has my vote.
I'm working on ways to create portals to other scenes where the portal texture is a grab of the camera from another scene. It seems that supporting separate scenes as containers or pocket worlds would be the easiest way to set this up. I get that making this work for VR is problematic, but if you think of the scene as a static yet 3d space which can be output as a texture to a plane like the game Portal, it seems like something useful.
Three.js seems to support multiple scenes https://threejs.org/examples/webgl_multiple_scenes_comparison.html
https://threejs.org/examples/#webgl_multiple_views
https://threejs.org/examples/webgl_multiple_elements.html
var scenes = [], renderer;
I get that each of these uses some different trick to pull off the multiple viewports, but I'm wondering what the best practice is if not multiple scenes for portals? I understand that setting up an equirectangular image on a link is one way to go but using the portal shader and spherical images is not as seamless when jumping to a 3d scene as using a camera ouput from within that scene.
In addition Iframes have issues when adjusting the renderer size (mobile apps). I've noticed scaling issues where the renderer works as expected the first time, but scales uncontrollably the next time it is loaded on a page. This seems to be a three.js thing but I've seen it in aframe as well.
Here's a discussion of the issue...
mrdoob/three.js#9195
So My question is. What would be the proper way to implement a portal (3d camera based) like the portals in the game Portal, but portals to a new scene not the same scene? Shader code would be one way but it is not easily understood by the average aframe user and would be very specific to each use case. targeting the camera and world to show on the portal.
Some sort of camera to camera connection where one camera drives the other based on its position relative to the portal seems ideal. This is problematic in the current situation where we are limited to one scene per page. This seems like a use case that will become more common in the future. I understand the limitations and workarounds based on the current issues list, but I'm wondering if this is a huge hole in aframe's ability to develop multi-scene applications.
@colinfizgig it sounds like you're trying to create A-Frame's link component If you can tell me how your use case is different I should be able to outline how to map THREE's approach onto A-Frame, not sure what your use case is yet though that's different from link.
If you want the peek attribute of link to extend to another scene (rather than just a 360° asset) you'll need to render the other scene's canvases offscreen, which is going to throttle your scene a bunch, worth a shot though—hope that helps!
I'd just like to second @jamesthurley's sentiments above.
It's on the roadmap to move to custom elements without a polyfill: #567
My assumption would be that ultimately an <a-scene> would be properly encapsulated? This is standard practice for web components. If so, that would imply that multiple scenes per page will become possible?
@edsilv Custom elements v1 doesn’t make encapsulation easier. Not for WebGL applications at least. A web context is still single threaded. It’s possible to add multiple scenes to a single page encapsulated in iframes. No plans to support multiple a-scenes on a single context because of performance implications and complexity of managing shared resources.
@dmarcos seems like this is not really an A-Frame issue as such, more of a general limitation of webgl. Thanks!
Yeah. You will run into similar problems with THREE or any other WebGL library. Multiple scenes is complicated and hard to guarantee good performance.
No meu caso gostaria de usar a webcam como um modelo de background! Reparei que quando ativo o VR a webcam para uma realidade aumentada identificando através de uma imagem para exibição o fundo fica preto no modo vr! Gostaria que o mesmo ficasse com a imagem capturada da webcam assim conseguiria seguir com o projeto..