Rendering different viewports to multiple canvases using the same TurbulenzEngine instance

[Zacqary Adam Xeper]

My master plan to get Fast Company to use the Turbulenz engine is taking shape. While the end goal is to get them to let me make games (like, wouldn't a magazine making Molleindustria-style games-as-journalism be super innovative disruptive buzzword, you guys?), right now I have another project for which some WebGL graphics could be a good fit. Turbulenz makes this much easier than diving into the low-level rendering code myself, so I'm wondering if I can hack it to do this.

Is there any way to get the same instance of the Turbulenz engine to render to more than one canvas? The alternative is, I assume, calling the engine for each individual graphic embedded in the DOM, which seems like it could be a huge performance issue.

[Ian Ballantyne]

Hey Zac, good to hear from you!

Do you mean to render the same content to two different contexts or do you mean run two different Turbulenz Engine instances on the same page?

You can certainly render to a different canvas context, but it would require some changes to your templates to provide a different default context.

Provided the engines aren't all running simultaneously (possible you pause rendering when the mouse is not active on the canvas) then loading multiple instances is not such a problem. 

I'm assuming you mean the wall-of-TVs-style setup?

[Zacqary Adam Xeper]

Yeah, I guess a wall of TVs is a good analogy. What I'm imagining is a web app with some components being rendered in WebGL (e.g. a 3D globe element to display a map), so there would end up being multiple <canvas> elements in arbitrary positions in the DOM. Since they're not necessarily all next to each other, they'd have to be separate elements.

I looked over the Turbulenz docs again and it looks to me like the one canvas per engine architecture is pretty deeply hard-coded in there. My ideal would be to have the same engine have several different render targets and then render them to different canvas elements, but I guess that's not what it's built for?

I can experiment with pausing, or at least framerate limiting, to see how it works out. That globe example I'm thinking of would probably need to update in real time in response to data, so I don't know if the mouse hover is a good way of doing that, but maybe it could pause rendering if the data isn't actively changing at the moment.

Is rendering the only bottleneck I'd have to worry about with having multiple instances of the engine running at once? I was thinking perhaps having a "master" engine that could load textures into the global namespace so that the other engines could pull from that and didn't have the overhead of their own texture loaders. Although I forget if texture loading is inherently tied to a GraphicsDevice or not.