We do alot of rich media advertising. One limit I have found in your engine is that you can only have one instance in the DOM at a time or else the namespacing bleeds. Normally you get around this by serving in its own frame, but in certain cases serving in a frame isnt an option.
The reason I think being able to run multiple instances in a single DOM would be powerful is because you could build bridges between 3D motiffs instead of having to create a full 3D scene. For example, one of our designs uses a flip card with 3D planes and lighting that has infinite flippable assets to show. It would be amazing to be able to have several of this in the page at once like any other HTML element but because of the namespacing bleed, it does not work out.
It could also be very useful for building in-page interfaces with 3D elements without needing to consider the geometries between the monitor and the 3D scene since you could build each piece separately and use various communication interfaces in the DOM to trigger their state changes.
I think there are many many many more possibilities and generally speaking, it expands the math which means people will invent new uses along that additional ‘axis’. So, please consider this evolutionary step toward Playcanvas becoming the end-all-be-all-in-one 3D solution for html5.
We’ve tried to design the engine with multiple apps on one page in mind. However, there is a balance between providing an API which is nice for 99% of use-cases (one app on a page), for example, it would be annoying to pass the app object into every Entity you create new pc.Entity(app) so we provide a default behavior that doesn’t require that.
In addition, we don’t have many real-world cases of people seeking this behavior. If you have a good test-case for running multiple apps in a single page I’m happy to take a look and see where the engine is failing for this case.
Sorry it took me so long to get you a lab we could collaborate with. I did as best I could to create a reasonable scale model of the kind of implementation we would be trying and simplified the DOM as much as possible to provide a clean example. Your comments suggest to me that possible my problem is that im trying to use each scene as a standalone encapsulated thing when i should be thinking about is as an instance within your engine singleton.
In the index page, I have 2 divs setup with script tags pointing to 2 different PC scene bundles. They are the same ‘creative’ in the sense that each scene is a fork, but each is published as its own scene and web bundle installed on our server. Each of those bundles is being referred to via the start.js script.
We use a Rich Media platform to build our ads so using as few components as possible to boot and orient the display is ideal. We are unable to use the usual Iframing method because on mobile WebGL is often disabled for frames. Otherwise we could easily just use 2 iframes and use the postMessage API to do any proxy communications between the parent and the frames.
Let me know if you have any questions about this implementation and/or why we are trying to make things work this way. As mentioned, for Rich Media advertising, 3D has some unique challenges.